24
edits
Security/ReviewProcess: Difference between revisions
→Security Review Processes
| Line 2: | Line 2: | ||
= Security Review Processes = | = Security Review Processes = | ||
==Web Application Review Process== | |||
Web applications vary dramatically in design and functionality making it difficult to create a single use-case checklist for security reviews. However, most applications undergo the following checks during the security review process. | |||
===General Web Application Review Process=== | |||
Many of these questions are taken from the secure coding guidelines page: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines | |||
====Access Information==== | |||
* How is the application accessed? | |||
* Is the application internal or publicly available? | |||
* If it is internal, what mechanism prevents non-members from accessing it? | |||
* Are there links to user-only resources displayed to non-users? | |||
* Are login pages secured with SSL over HTTPS? | |||
* If HTTPS is used, is Strict Transport Security set? | |||
====Infrastructure and Backends==== | |||
* What languages do the applications use? | |||
* What database language is used if applicable? | |||
* Are the running versions up to date? | |||
* What server is it running on? | |||
====Accounts and Passwords==== | |||
* If the mechanism to prevent general access is a password, how is the signup process handled? | |||
* How is account information stored? | |||
* Are passwords properly stored within databases if applicable? | |||
* Is a password policy in place? | |||
* Are accounts locked-out after a number of invalid logins? | |||
* Are passwords 8 characters or greater? | |||
* Do passwords use both numbers and letters (and possibly symbols)? | |||
* Is there a blacklist of common passwords? | |||
* Do passwords expire after X days and require a reset? | |||
* Are invalid logins logged? | |||
* Is there a lockout after X invalid attempts? | |||
* Is the error message for lockout generic (does not include if user/pass is valid)? | |||
* How are password resets handled (i.e. email, security question, etc.)? | |||
* Do emails sent after signup/reset contain a session link? (should not) | |||
* Do email verification codes expire after one use or 8 hours? | |||
* Is password reuse limited/prevented? | |||
====Session Management==== | |||
* How long are session cookies stored? | |||
* Are session tokens 128-bit or greater? | |||
* Is session ID token creation handled by the server (or cryptographically if locally)? | |||
* Do authenticated sessions timeout after 15 minutes? | |||
* Is the Secure Flag enabled for all set cookies? | |||
* Is the HTTP-Only flag used to disable malicious script access to the session ID? | |||
* Are new session ids created on login? | |||
* On logout, are session ids invalidated? | |||
====Third-Party Resources==== | |||
* Are third-party resources used (i.e. JavaScript libraries, images, CSS, etc.)? | |||
* Can those resources be trusted / are they from reputable sources? | |||
* Is there a chance the resource could be compromised? | |||
* Is it possible to host the resources locally to mitigate risks? | |||
* Is a third-party responsible for storage of user data? | |||
* Does the application connect with services like Facebook, Twitter, etc? | |||
====Data Handling==== | |||
* What kind of data is transferred between the user and the application? | |||
* Is this data generated by the user or generated automatically? | |||
* Can the data be trusted? | |||
* How is the data sent to the application (i.e. JSON format, plain-text, GET/POST, etc.)? | |||
* How is the data handled by the server/application? | |||
* Can the data be manipulated in transit? | |||
* What happens if the data is altered? | |||
* What is done with the data once it is received (i.e. stored in a database, displayed to users)? | |||
* Is any data storage done via cookies? If so, what kind of data is stored via this method? | |||
====Uploaded Data==== | |||
* Can the user upload data to the application? | |||
* Are extensions, file size, file type (not only based on extension), etc. checked? | |||
* Are files renamed upon upload? | |||
* Is the correct content-type used? | |||
====Data Sensitivity==== | |||
* What kind of data is being stored and/or manipulated by the application? | |||
* Does this data need to be encrypted in transit? In storage? | |||
* What is the impact if this data is lost/stolen? | |||
* Is secure/sensitive data sent over SSL? | |||
====Application Administration==== | |||
* Is there an administration console? | |||
* Can it be accessed publicly? | |||
* How is it secured if so? | |||
* Are correct methods used to prevent admin actions from being performed outside of the admin console (i.e. using CSRF tokens)? | |||
* Are there any configuration pages that should not be made public? | |||
====Security Coding Flaws==== | |||
* Have all user inputs been sanitized? | |||
* Is a maximum size for data (input or uploads) defined? | |||
* Do all URL variables pass through sanitization? | |||
* Is data from databases escaped properly? | |||
* Are CSRF tokens used to prevent POSTs from outside websites? | |||
* If a database is used, are protections against SQL injection in place? | |||
* Is validation done on the server side (not just client-side)? | |||
* Is output encoded in addition to sanitization of input? | |||
* Does the user ever send data to the OS level? | |||
* Are x-frame options sent to “deny” or “sameorigin”? | |||
* Is debug mode disabled? | |||
===Additional Resources=== | |||
Coming soon | |||
==WordPress Plugin Review Process== | |||
Before being installed, all WordPress plugins must be reviewed by the security team. These reviews are simpler than full site reviews and ensure that the plugin being installed does not compromise the security of the blog/site. | |||
===Common Attack Vectors=== | |||
The most common WordPress security issues present in plugins are cross-site scripting vulnerabilities (both persistent and reflected). Other vulnerabilities to check for include privilege escalation, remote code execution, logic errors, and SQL injection. | |||
===Review Process Overview=== | |||
A majority of the plugin review process involves manual inspection of the plugin and review of the plugin's code. The following steps outline a basic process followed when reviewing plugins. | |||
* A test installation of WordPress is used (see Turnkey WordPress: http://www.turnkeylinux.org/wordpress) | |||
** The WordPress version must match that of the blog on which the plugin will be installed. | |||
* If the plugin is being installed on a high profile blog, a staging installation may already be available. It is best to test here to replicate the production environment as best as possible. | |||
* The plugin to be tested is downloaded from WordPress using the most recent version available. | |||
* Security testing is performed (see next section for detailed testing information). | |||
* If any issues are detected, the developer is contacted and asked to release a fix. | |||
* A blocking bug is created pertaining to the fix. If the developer does not respond within a reasonable time frame, our developers may fix the issue on a local installation. | |||
===Detailed Testing Procedures=== | |||
* Determine the functionality of the plugin. Most plugins add a set of features to the admin page, but some are much more complex. | |||
** Do the features allow non-admin users to add data or enter input on the site? | |||
** Is that data treated as unsafe (i.e. not used directly in SQL statements or reflected back to other users or admins)? | |||
** Does the plugin alter the login process, add additional users, or grant additional rights to non-admins? | |||
* View the settings page for the plugin and test the inputs for cross-site scripting and SQL injection vulnerabilities. | |||
** Note that some plugins enable the use of unfiltered HTML within the admin page. This behavior is allowed unless the plugin also exposes this functionality to non-admins. | |||
** Ensure that unfiltered HTML is being used in expected places. For example, unfiltered HTML may be allowed when editing posts, but some input boxes can be XSS'ed with "/><script>alert(1);</script>. This breaks out of the settings input box and allows unfiltered code execution on the settings page. | |||
* View the methods used to save settings. Some plugins use POST (desirable) and others use GET. | |||
** Where GET is used, especially check all settings for potential XSS as an admin can be sent a link containing the XSS and it will be executed immediately (or following login). | |||
** If POST is used, check for potential CSRF issues. A nonce should be used to protect the admin page from CSRF. | |||
* View the code of the plugin itself (this can be done in WordPress by clicking Plugins > Editor and selecting the plugin). | |||
** Check for all input accepted by the plugin ($_GET, $_REQUEST, $_POST). | |||
** Fuzz all inputs for potential XSS and SQL injection vulnerabilities. | |||
Do the varied nature of plugins, it is impossible to have a "one stop" checklist. Each plugin must be manually checked and the testing procedures altered depending on the functionality. The above process is a general guideline and does not apply to every plugin. | |||
= Security Review Documentation = | = Security Review Documentation = | ||