OverviewExecutive SummaryAn Overview of Gravity FormsThe Gravity Forms Leadership TeamThe Gravity Forms Release CycleVersion Numbering and Security ReleasesVersion Backwards CompatibilityGravity Forms and Security2013 OWASP Top 10A1 – InjectionA2 – Broken Authentication and Session ManagementA3 – Cross Site Scripting (XSS)A4 – Insecure Direct Object ReferenceA5 – Security MisconfigurationA6 – Sensitive Data ExposureA7 – Missing Function Level Access ControlA8 – Cross Site Request Forgery (CSRF)A9 – Using Components with Known VulnerabilitiesA10 – Unvalidated Redirects and ForwardsFurther Security Risks and ConcernsXXE (XML eXternal Entity) processing attacksSSRF (Server Side Request Forgery) AttacksAppendixCore WordPress APIsDatabase APIHTTP APIPermissions and current user API
Learn more about Gravity Forms software security in this free white paper which is forked from the original security white paper for WordPress.
Overview
This document is an analysis and explanation of the Gravity Forms software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating Gravity Forms as a form design and management system or web application framework should use this document in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.
The information in this document is up-to-date for the latest stable release of the software, Gravity Forms 1.9.4 at time of publication, but should be considered relevant also to the most recent versions of the software as backwards compatibility is a strong focus for the Gravity Forms development team. Specific security measures and changes will be noted as they have been added to the core software in specific releases. It is strongly encouraged to always be running the latest stable version of Gravity Forms to ensure the most secure experience possible.
Executive Summary
Gravity Forms is a dynamic open-source form management system which is used to power websites and web applications. It currently powers more than 1.5 million websites on the Internet. The usability and extensibility make it a popular and secure choice for websites of all sizes.
Since its inception in 2007, Gravity Forms has undergone continual hardening so its software can address and mitigate common security threats, including the Top 10 list identified by The Open Web Application Security Project (OWASP) as common security vulnerabilities, which are discussed in this document.
The Gravity Forms Development Team, in collaboration with the Gravity Forms Leadership Team, works to identify and resolve security issues in the software available for purchase at gravityforms.com, as well as recommending and documenting security best practices for third-party add-on and theme authors.
Site developers and administrators should pay particular attention to the correct use of the WordPress and Gravity Forms APIs and underlying server configuration which have been the source of common vulnerabilities, as well as ensuring all users employ strong passwords to access Gravity Forms.
An Overview of Gravity Forms
Gravity Forms is a commercial open source form management system (FMS). It is licensed under the General Public License (GPLv2 or later).
The Gravity Forms Leadership Team
Gravity Forms is developed by Rocketgenius Inc., run by a leadership team, and led by its co-founders Carl Hancock, Kevin Flahaut and Alex Cancado. The team governs all aspects of the project, including development, gravityforms.com, and community initiatives.
The Leadership Team has final authority on technical decisions, and lead architecture discussions and implementation efforts.
The Gravity Forms Release Cycle
Each Gravity Forms release cycle is led by one or more of the Gravity Forms developers. A release cycle usually lasts around 1 month from the initial scoping meeting to launch of the version.
A release cycle follows the following pattern:
Phase 1: Planning and securing team leads. This is done via chat using HipChat and Trello. The release lead discusses features for the next release of Gravity Forms. Gravity Forms developers get involved with that discussion. The release lead will identify tasks for each of the developers.
Phase 2: Development work begins. Regular chats are scheduled to ensure the development keeps moving forward.
Phase 3: Beta. Betas are released, and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are carried out from this phase on. Third-party add-on and theme authors are encouraged to test their code against the upcoming changes.
Phase 4: Launch. Gravity Forms version is launched and made available on the Gravity Forms downloads page. Soon after it is made available to installations for automatic and background updates.
Version Numbering and Security Releases
A major Gravity Forms version is dictated by the first two sequences. For example, 3.5 is a major release, as is 1.6, 1.7, or 2.0. There isn』t a 「Gravity Forms 3」 or 「Gravity Forms 4」 and each major release is referred to by its numbering, e.g., 「Gravity Forms 1.9.」
Major releases may add new user features and developer APIs. Though typically in the software world, a 「major」 version means you can break backwards compatibility, Gravity Forms strives to never break backwards compatibility. Backwards compatibility is one of the project』s most important philosophies, with the aim of making updates much easier on users and developers alike.
A minor Gravity Forms version is dictated by the third sequence. Version 1.9.3 is a minor release, as is 1.9.3.1. A minor release is reserved for fixing security vulnerabilities and addressing critical bugs only. Since new versions of Gravity Forms are released so frequently — the aim is every 1 month for a major release, and minor releases happen as needed — there is only a need for major and minor releases.
Version Backwards Compatibility
The Gravity Forms team has a strong commitment to backwards compatibility. This commitment means that whenever possible add-ons, themes, plugins, and custom code continues to function when Gravity Forms is updated, encouraging site owners to keep their Gravity Forms version updated to the latest secure release.
Gravity Forms and Security
The Gravity Forms Development Team often collaborates with security specialists to address issues in common dependencies, such as resolving the issues file upload field in versions up to 1.8.19
The Gravity Forms Leadership Team believes in Responsible Disclosure by alerting the development team immediately of any potential vulnerabilities. Potential security vulnerabilities can be signaled to the development team directly via the email address: [email protected]. The Development Team communicates amongst itself via a private email list, and HipChat and works on a walled-off, private repository for tracking, testing, and fixing bugs and security problems.
Each security report is acknowledged upon receipt, and the team works to verify the vulnerability and determine its severity. If confirmed, the development team then plans for a patch to fix the problem which can be committed to an upcoming release of the Gravity Forms software or it can be pushed as an immediate security release, depending on the severity of the issue.
For every release, an announcement is published by the Gravity Forms Leadership Team to the Gravity Forms blog listing the changes. Details of the vulnerability will be made available to trusted parties on request. Credit for the responsible disclosure of a vulnerability is given in the announcement to encourage and reinforce continued responsible reporting in the future.
Administrators of the Gravity Forms software see a notification on their site dashboard to upgrade when a new release is available. If administrators have automatic background updates enabled, Gravity Forms will be updated automatically.
Starting with version 1.9, Gravity Forms introduced automated background updates for all minor releases, such as 1.9.3 and 1.9.4. The Gravity Forms development team can identify, fix, and push out automated security enhancements for Gravity Forms without the site owner needing to do anything on their end, and the security update will install automatically. This is enabled by default on all new installations from version 1.9.2 onward.
Individual site owners can opt to remove automatic background updates through a simple change in the Gravity Forms settings or WordPress configuration file, but keeping the functionality is strongly recommended by the development team, as well as running the latest stable release of Gravity Forms.
2013 OWASP Top 10
The Open Web Application Security Project (OWASP) is an online community dedicated to web application security. The OWASP Top 10 list focuses on identifying the most serious application security risks for a broad array of organizations. The Top 10 items are selected and prioritized in combination with consensus estimates of exploitability, detectability, and impact estimates.
The following sections discuss the APIs, resources, and policies that Gravity Forms uses to strengthen the core software and 3rd party plugins and themes against these potential risks.
A1 – Injection
There is a set of functions and APIs available in WordPress which Gravity Forms developers use in making sure unauthorized code cannot be injected, and help them validate and sanitize data. Best practices and documentation are available on how to use these APIs to protect, validate, or sanitize input and output data in HTML, URLs, HTTP headers, and when interacting with the database and filesystem. Administrators and Form Editors can also further restrict the types of file which can be uploaded via filters and settings.
A2 – Broken Authentication and Session Management
WordPress core software manages user accounts and authentication and details such as the user ID, name, and password are managed on the server-side, as well as the authentication cookies. Passwords are protected in the database using standard salting and stretching techniques. Existing sessions are destroyed upon logout for versions of WordPress after 4.0.
Gravity Forms utilizes WordPress authentication for session management alongside a simple implementation of OAuth 1 with HMAC-SHA1 signatures which is used by external clients for session-less connections to the Gravity Forms API.
A3 – Cross Site Scripting (XSS)
WordPress provides a range of functions which help Gravity Forms developers ensure that user-supplied data is safe. Trusted users, that is Administrators on a single WordPress installation, and site administrators in WordPress Multisite and users with the permission to edit forms, can publish unfiltered HTML or JavaScript as they need to, such as inside a form confirmation or field label. Untrusted users and user-submitted content is filtered by default to remove dangerous entities by escaping output and stripping tags as appropriate depending on the context.
A4 – Insecure Direct Object Reference
Gravity Forms often provides direct object reference, such as unique numeric identifiers of forms or entries. While these identifiers disclose direct system information, Gravity Forms』 rich permissions and access control system prevent unauthorized requests.
A5 – Security Misconfiguration
The majority of the WordPress and Gravity Forms security configuration operations are limited to a single authorized administrator. Default settings for Gravity Forms are continually evaluated at the development team level, and the Gravity Forms development team provides documentation and best practices to tighten security for server configuration for running Gravity Forms on a WordPress site.
A6 – Sensitive Data Exposure
WordPress user account passwords are salted and hashed based on the Portable PHP Password Hashing Framework. WordPress』 permission system is used to control access to private information such as entry details. Gravity Forms provides functions to help developers enforce authorization and also encourages the use of these functions throughout the documentation including examples of best practices.
A7 – Missing Function Level Access Control
Gravity Forms checks for proper authorization and permissions for any function level access requests prior to the action being executed. Access or visualization of administrative URLs, menus, and pages without proper authentication is tightly integrated with the authentication system to prevent access from unauthorized users.
A8 – Cross Site Request Forgery (CSRF)
WordPress uses cryptographic tokens, called nonces, to validate intent of action requests from authorized users to protect against potential CSRF threats. WordPress provides an API for the generation of these tokens to create and verify unique and temporary tokens, and the token is limited to a specific user, a specific action, a specific object, and a specific time period, which can be added to forms and URLs as needed. Additionally, all nonces are invalidated upon logout.
Gravity Forms utilizes this WordPress API to protect against potential CSRF threats.
A9 – Using Components with Known Vulnerabilities
The Gravity Forms development team closely monitors the few included libraries and frameworks Gravity Forms integrates with for core functionality.
If necessary, the development team may decide to fork or replace critical external components.
A10 – Unvalidated Redirects and Forwards
WordPress』 internal access control and authentication system will protect against attempts to direct users to unwanted destinations or automatic redirects. This functionality is also made available to plugin developers via an API, wp_safe_redirect().
Gravity Forms utilizes wp_safe_redirect().
Further Security Risks and Concerns
XXE (XML eXternal Entity) processing attacks
When processing XML, WordPress and Gravity Forms disable the loading of custom XML entities to prevent both External Entity and Entity Expansion attacks. Beyond PHP』s core functionality, Gravity Forms does not provide additional secure XML processing APIs for add-on authors.
SSRF (Server Side Request Forgery) Attacks
HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
Gravity Forms uses the WordPress HTTP API for all HTTP requests.
Appendix
Core WordPress APIs
The WordPress Core Application Programming Interface (API) is comprised of several individual APIs, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
Database API
The Database API, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
Gravity Forms always utilizes the Database API to access the database layer.
HTTP API
The HTTP API, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
Gravity Forms utilizes the HTTP API for all HTTP requests.
Permissions and current user API
The permissions and current user API is a set of functions which helps verify the current user』s permissions and authority to perform any task or operation being requested, and can protect further against unauthorized users accessing or performing functions beyond their permitted capabilities.
Gravity Forms utilizes the permissions and user API to protect against unauthorized access.