Enumerating Vulnerability
9 November 2010
The simplest self contained definition of a software vulnerability is: any situation in which the software violates the stated security policy should be classified as a vulnerability. Using this definition it is easy to classify flaws in such a way as to avoid relying on published definitions of classes of vulnerability (such as XSS, XSRF, authentication bypass, insufficient anti-automation) as well as to avoid semantic debate about the term “vulnerability.” The challenge that faces open source security researchers is that there is rarely any stated security policy for systems under review. Most researchers unconsciously apply their own policy to systems in question and enumerate their flaws based on this personally held framework.
Some security policy guidelines are obvious and fairly universal. Tenets such as “no user shall employ the system to harm another user, their data, or computing assets” are widespread to most system policies. Whole classes of vulnerabilities fall into this realm such as cross site scripting or authentication bypass. By focusing on the policy violation rather than the class of vulnerability the researcher is able to demonstrate clear harm in an easily conveyed manner. The policy becomes the harbinger of the security issue rather than the researcher.
Some policy points may come under debate, especially in an implicit security policy, such as those surrounding most open source systems. “No user shall be able to mix display instructions in content created beyond the bounds of stated functionality,” is a complex guideline that could be used to protect users from injecting arbitrary javascript into content. This type of rule might come under debate if certain users feel they require the ability to create markup freely, and others might feel that such tight definitions of acceptable functionality are burdensome and unnecessary. Other policies, such as “no credentials should be stored in clear text anywhere in the system,” might be attacked as unnecessary. Users could argue that plain text passwords stored in a database are safe so long as the database security is maintained. Even more contentious might be a policy that “no user details shall be revealed to unauthorized users.” Some users might feel that author names or logins should be part of the public data set available to anonymous users despite the power of such data to aid in brute force or targeted spear phishing attacks.
The fact that most open source systems have no stated security policy muddies any debate about vulnerability. Without a security policy some vulnerability remediation devolves to an argument about legitimate functionality with researchers having to invoke edge scenarios as proof of danger. Without the policy, vulnerability reporters are faced with the daunting task of deriving anecdotal evidence of harm.
Organizations can find it extremely worthwhile to devise a security policy for their applications. Below is a sample Drupal (or any CMS) security policy that can be used when performing software security analysis. It should cover almost all vulnerability classes, and provides a clear point of delineation that allows researchers to find flaws demonstrative of program nonadherence to policy.
- No user of a Drupal application user shall be able to write arbitrary PHP code.
- No user shall be able to write arbitrary HTML code. All HTML for display should be limited to a restricted, and minimal, set of tags deemed absolutely necessary for page display.
- Only approved file types shall be allowed for upload and display via a Drupal site.
- JavaScript should be present only in template code, never in nodes or stored in the database.
- No plain text passwords should be stored in the database.
- Every Drupal site should respect access restrictions set by users in every feature and request.
- No Drupal user shall be able to execute arbitrary SQL queries against the database or alter queries.
- No Drupal user shall be able to execute arbitrary commands as the Apache web user.
- No Drupal user shall be able to view contents on the web server beyond files, images and HTML designed to be delivered from documents in the web directory and associated database.
- No Drupal site shall access any MySQL database other than those specifically designated for site functionality.
- All PHP code should be compiled by the web server into HTML before being presented to any end user.
- All error messages should be informative and non technical. No server configuration details should be conveyed in error messages presented to end users.
- All Drupal sites will have the PHP module removed from the installation.
- All sites shall use centrally installed modules in the /sites/all/modules directory unless otherwise agreed upon with the sysadmin staff.
- No Drupal site should allow for arbitrary redirection from any page. That is, no parameter passed to any Drupal page should result in a redirection to any external site.
- No Drupal site should allow anonymous users to create accounts without administrator approval.
- No Drupal site user should share their credentials with any other user. That is, no collaborative accounts shall be utilized.
- No Drupal site should allow anonymous users to create, edit or delete any content, including comments or forum posts, without prior administrator approval. Content may be created by anonymous users so long as it is created in an 'unpublished' state and the content may only be published by an administrator or assigned delegate.
- No Drupal site should e-mail user passwords for any reason.
- All form post processing or URL based command execution presented in a Drupal site should be protected using a one time token to prevent against cross site request forgeries.
- All Drupal sites must utilize the Password Strength, Login Security and Syslog modules.
- Any violation of this policy shall be considered a vulnerability. Sites discovered to contain vulnerabilities will have said vulnerabilities remediated with all reasonable speed. Sites that cannot have vulnerabilities remediated in a timely fashion should be disabled pending a fix for the vulnerability.