SoftwareSecurity2012/Group 11/Code Scanning

OWASP Application Security Verification Standard

OWASP Application Security Verification Standar (ASVS) distinguishes levels, techniques and sets of verification requirements. There are 4 different levels:

• Level 1 - Automated Verification
• Level 2 - Manual Verification
• Level 3 - Design Verification
• Level 4 - Internal Verification

The level 1 is consisted of:

• Level 1A - Dynamic Scan (Partial Automated Verification)
• Level 1B - Source Code Scan (Partial Automated Verification)

The level 2 is consisted of:

• Level 2A - Penetration Test (Partial Automated Verification)
• Level 2B - Code Review (Partial Manual Verification)

In our project we will focus on levels 1B and 2B

The categories of verification requirements are the following:

• V1. Security Architecture
• V2. Authentication
• V3. Session Management
• V4. Access Control
• V5. Input Validation
• V6. Output Encoding/Escaping
• V7. Cryptography
• V8. Error Handling & Logging
• V9. Data Protection
• V10. Communication Security
• V11. HTTP Security
• V12. Security Configuration
• V13. Malicious Code Search
• V14. Internal Security

---

In our project, we will focus on requirements V4 (Access Control) and V9 (Data Protection):

- The Access Control verification requirements defines how an application can safely enforce access control. In most applications, access control must be performed in multiple different locations accross the various application layers. These requirements define verification requirements for access control for URLs, business functions, data, services, and files.

- The Data Protection verification requirements define a set of requirements that can be used to verify the protection of sensitive data (e.g. credit card number, passport number, personally identifiable information).

When we work with the level 1B, the actual requirements we had to check according to the OWASP are:

• V4.1: verify that users can only access protected functions for which they possess specific authorization
• V9.1: verify that all forms containing sensitive information have disabled client side caching, including autocomplete features

For the level 2B, some other requirements are added based on the OWASP:

• V4.2: verify that users can only access URLs for which they possess specific authorization
• V4.3: verify that users can only access data files for which they possess specific authorization
• V4.4: verify that direct object references are protected, such that only authorized objects are accessible to each user
• V4.6: verify that users can only access services for which they possess specific authorization
• V4.7: verify that users can only access data for which they possess specific authorization
• V4.8: verify that access controls fail securely
• V4.9: verify that the same access control rules implied by the presentation layer are enforced on the server side
• V4.10: verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized
• V4.11: verify that all access controls are enforced on the server side
• V4.12: verify that there is a centralized mechanism (including libraries that call external authorization services) for protecting access to each type of protected resource
• V4.13: verify that limitations on input and access imposed by the business on the application (such as daily transaction limits or sequencing of tasks) cannot be bypassed
• V4.14: verify that all access control decisions can be logged and all failed decisions are logged
• V9.2: verify that the list of sensitive data processed by this application is identified, and that there is an explicit policy for how access to this data must be controlled, and when this data must be encrypted (both at rest and in transit). Verify that this policy is properly enforced
• V9.3: verify that all sensitive data is sent to the server in the HTTP message body (i.e., URL parameters are never used to send sensitive data)
• V9.4: verify that all cached or temporary copies of sensitive data sent to the client are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data (e.g., the proper nocache and no-store Cache-Control headers are set)
• V9.5: verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data

Our work can be splitted in two phases. In the first one, after applying the tools (a description of the experience with these software is provided at Code Scanning Reflection), we tried to find a relationship between the errors pointed by the tools (usually presented in a certain classification) and our requirements: "Data Protection" and "Access Control" issues (according to the concepts shown by OWASP). The result of this phase can be viewed on several tables available along this page. In the second phase, a manual review was useful to detect false positives generated by the tools (associated to the level 1B) and looking for vulnerabilities related to level 2B. In this phase, we maintained the attention over the specific topics explored by OWASP (listed above).

Analysis of Fortify's SCA results according to our requirements

We have to analyze the results that Fortify produces and find out which of them fit to our requirements. Our requirements are V4 and V9 according to the OWASP Application Security Verification Standard 2009. As a reminder, in V4 requirement we have to verify that user can only access authorized functions and in V9 we have to verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.

Critical security vulnerabilities

We first try to analyze the critical security vulnerabilities that Fortify produce. In this category we have 254 different vulnerabilities in 10 different categories. In the category Password Management: Password in HTML Form we can see that there are two cases that the program populates password fields in an HTML form. Sometimes, sensitive information stored in password fields and this information may be cached by proxies or browsers. We can reach to the conclusion that these kinds of security vulnerabilities are included in the V9: Data Protection requirements since we should not have client side caching enabled and sensitive information like passwords should not be cached by proxies or browsers. Moreover, in the category Cross-site Scripting: Reflected, we can see that there are cases that unvalidated data are sent to a web browser, which can result in the browser executing malicious code. The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user’s machine under the guise of the vulnerable site. So, we can see that again the client side caching is enabled and private data like cookies are sent to the attacker. This also violates the V9: Data Protection requirement. In addition, in the category Cross-Site Scripting: Persistent, the same thing happens. Cookies can be transmitted to the attacker and this can result in the violation of V9: Data Protection requirements. Finally, we can say that SQL injection can provide access to information in the database and changing the data, which usually requires some privileges. This way, we indicate violations on V4 and V9.

Some of these vulnerabilities are false positives. For example, in the category Password Management: Password in HTML form the tool warns us that populating password fields in an HTML form could result in a system compromise. Although, we can see that this password is randomized in the previous line. So, it is a false positive. There are more cases like this with Forttify.

<?php $smtp_pass = !empty($pun_config['o_smtp_pass']) ? random_key(pun_strlen($pun_config['o_smtp_pass']), true) : ''; ?>
            <input type="password" name="form[smtp_pass1]" size="25" maxlength="50" value="<?php echo $smtp_pass ?>" />
            <input type="password" name="form[smtp_pass2]" size="25" maxlength="50" value="<?php echo $smtp_pass ?>" />

These results can be shown in the following table:

Category	V4: Access Control	V9: Data Protection	Irrelevant to our requirements
Cross-Site Scripting: Persistent		X
Cross-Site Scripting: Reflected		X
Dangerous File Inclusion			X
Dangerous Function			X
Open Redirect			X
Password Management: Hardcoded Password			X
Password Management: Password in HTML Form		X
Privacy Violation			X
SQL Injection	X	X
System Information Leak			X

High Security Vulnerabilities

In high security vulnerabilities we have 13 different categories of vulnerabilities that Fortify produces. In the case of Cross-Site Scripting: Persistent, the situation is the same as before and these kinds of vulnerabilities can lead to violation of V9: Data Protection vulnerabilities. In the category of Access Control: Database we can observe that without proper access control, some methods can execute a SQL statement that contains an attacker-controlled primary key, thereby allowing the attacker to access unauthorized records. Usually, the code does not check to ensure that the user has permission to access the requested invoice, and as a result it will display any invoice, even if it does not belong to the current user. We can reach to the conclusion that these security vulnerabilities are likely to violate the V4: Access Control requirements as users can access functions for which they do not possess authorization. Furthermore, in the category Privacy Violation: Autocomplete we can observe that there are some forms that use autocompletion, which allows some browsers to retain sensitive information in their history. With autocompletion enabled, some browsers retain user input across sessions, which could allow someone using the computer after the initial user to see information previously submitted. In this case, clearly the client side caching is enabled and especially the autocomplete feature. According to V9: Data Protection verification requirement, the autocomplete feature must be disabled. In the case of SQL injection, we can assert that it allows access to information in the database and makes possible to change the data, which usually requires some special privileges. So, we understood that it represents violations on V4 and V9. These results are shown in the next table:

Category	V4: Access Control	V9: Data Protection	Irrelevant to our requirements
Access Control: Database	X
Code Correctness: Regular Expression Denial of Service			X
Command Injection		X
Cross-Site Scripting: Persistent		X
Dangerous File Inclusion			X
Header Manipulation			X
Header Manipulation: Cookies			X
Insecure Randomness			X
Open Redirect			X
Password Management: Hardcoded Password			X
Path Manipulation			X
Privacy Violation: Autocomplete		X
SQL Injection	X	X

Medium Security Vulnerabilities

In medium security vulnerabilities we only have two different categories and the category Cross-Site Scripting: Poor Validation can result in transmitting private data like cookies to the attacker as the other Cross-Site Scripting vulnerabilities that examined before. So, it is a violation of Data Protection requirements.

Category	V4: Access Control	V9: Data Protection	Irrelevant to our requirements
Cross-Site Scripting: Poor Validation		X
Often Misused: File Upload			X

Low Security Vulnerabilities

In low security vulnerabilities we have 14 different categories. From the previous sections that we examined, Cross-Site Scripting: Poor Validation is the same as before and violates the V9 requirements. In the category Cookie Security: HTTPOnly not set, we can see that the program creates a cookie but fails to set the HttpOnly flag to true. Microsoft Internet Explorer support thr HttpOnly cookie property that prevents client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. When HttpOnly is not enabled, attackers can more easily access user cookies. We can reach to the conclusion that this security vulnerability leads to violation of Data Protection since client-side caching is enabled. Moreover, in the category, Cookie Security: Persistent Cookie, sensitive data are stored in a cookie. Storing sensitive data in a persistent cookie can lead to a breach of confidentiality or account compromise. Most web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts. If private information is stored in a persistent cookie, attackers have a larger time window in which to steal this data – especially since persistent cookies are often set to expire in distant future. This security vulnerability can lead to violation of the V9 requirement since client-side caching is again enabled. Furthermore, in many cases a hidden form is used in the code. Programmers often trust the contents of hidden fields, expecting that users will not be able to view them or manipulate their contents. Attackers will examine the values written to hidden fields and alter them or replace the contents with attack data. If hidden fields carry sensitive information, this information will be cached the same way the rest of the page is cached. This can lead to sensitive information being tucked away in the browser cache without the user’s knowledge. In this category, we observe that both Access Control and Data Protection requirements are violated. Attackers have the ability to access functions for which they do not possess authentication and client-side caching is enabled and sensitive information may be in the user’s browser without his knowledge. In Password Management category, a password is stored in plaintext and this fact can result in a system compromise. If an attacker has access to this information, he can use it to break into the system. This is a violation of Access Control requirements since the attacker is able to access functions for which he does not possess authorization. These results can be summarized in the next table:

Category	V4: Access Control	V9: Data Protection	Irrelevant to our requirements
Command Injection			X
Cookie Security: HTTPOnly not Set		X
Cookie Security: Persistent Cookie		X
Cross-Site Request Forgery			X
Cross-Site Scripting: Poor Validation		X
Header Manipulation			X
Header Manipulation: Cookies			X
Hidden Field	X	X
Open Redirect			X
Password Management	X
Password Management: Password in Comment			X
Resource Injection			X
System Information Leak			X
Weak Cryptographic Hash			X

Analysis of RATS's results according to our requirements

RATS were not able to discover much vulnerability. The majority of the provided warnings were irrelevant according to the requirements that we focus on. Actually, the only results that may violate our requirements are the ones that include the is_readable function. The is_readable function tells whether a file exists or not and if it is readable. 2/60 warnings were reported and they may be relevant to Access Control since the file permission can change from the time this command is checking the conditions and the use of the results of that check. This is called Time Of Check to Time Of Use (TOCTOU) and RATS supplied a total of 5/60 warnings like this. During this timing, the attacker has the possibility to break into the system. Besides this, RATS found no other vulnerability related to our requirements.

Edited: (Erik: Be careful with your terminology: RATS only provides warnings about things that may be security vulnerabilities; they may well be false positives.)

Edited: (Erik: How many of these were there?)

Edited: (Erik: How many of these TOCTOU warnings did RATS produce?)

Analysis of RIPS's results according to our requirements

Verbosity levels

As mentioned on the Code Scanning Reflection page, RIPS allows 5 verbosity levels for the scans:

1. user tainted only
2. file/DB tainted
3. show secured
4. untainted
5. debug mode

Results classification

Then, the different results showed could be classified according to several categories:

• All
• All server-side
  • Code Execution
  • Command Execution
  • Header Injection
  • File Disclosure
  • File Inclusion
  • File Manipulation
  • LDAP Injection
  • SQL Injection
  • XPath Injection
  • other
• All client-side
  • Cross-Site Scripting
  • HTTP Response Splitting
  • Unserialize / POP

Results

First of all, in order to see what RIPS could do, we made a first scan with the higher verbosity level 4 (the level 5 only shows all the PVF calls) and show all the results.

First scan results, verbosity level 4

We can see that an amount of 3 565 errors are reported which is huge and not efficient at all. Indeed, RIPS doesn’t handle oriented-object code and therefore, it supplies lots of false positives errors. Luckily, fluxBB is not based on OOP (it will be from the v2.0) but many of those reported errors are fakes anyway. Effectively, after reading a lot of documents about RIPS, this tool is well known for being easy to use and providing a lot of information about its results but also for its false positives. The best way to figure out if a warning is relevant or not is to go through the code itself and try to find whether it is a real bug or not. This practice has inter alia also been executed for the other tools and turns the most efficient method. Thereby, when we look for example at the XXS errors (the ones that are more numerous), this is obviously the case here. We see that 2 443 of them say: “Userinput reaches a sensitive sink”. However, when we look through the code, some of those errors are generated because an exit function is called when some data are not coherent in the database (as this error message from fluxBB says: "Unable to fetch guest information. Your database must contain both a guest user and a guest user group."). It is obviously not a bug because this case is possible only by directly editing the data in the database itself.

Edited: (Erik: What did you do to figure out if there were many false positives? Did you also do this for the other tools?)

We could classify to results as following:

Category	V4: Access Control	V9: Data Protection	Irrelevant to our requirements
Code Execution	X
Commande Execution			X
Header Injection			X
File Disclosure		X
File Inclusion			X
File Manipulation		X
SQL Injection	X	X
Cross-Site Scripting		X
HTTP Response Splitting			X
Possible Flow Control	X

Therefore, in a way to focus more on our requirements, we decided to chose a verbosity level producing less false positives and to categorize the results. Indeed, in order to check the first requirement V4.1, we decided to focus on the cross-site scripting vulnerabilities. Then, because fluxBB is an internet discussion board system, the database obviously has an important role and that is why we used the verbosity level 2.

V4.1: XSS vulnerabilities and verbosity level 2

However, if you look through those results, we could for example notice this one:

Example of XSS vulnerability

RIPS throws an error here because FluxBB wants to display (with echo()) a string told by the user. But if we look closer through the code, we see that a function preg_replace() is replacing the caracteres that could cause a vulnerability is the string is displayed as received. Obviously RIPS can't know what caracteres are harmful and which ones are replaced and by what. It's therefore a false positive.

Then, in order to check to second requirement V9.1, we mostly focused on the SQL injection knowing that the database is obviously the target for data stealing.

V9.1: SQL injection and verbosity level 2

To conclude, those results less outnumber will be easier to figure out and to correct. Effectively, the number of warnings and therefore of false positives decreased using the verbosity level 2. You can find our impressions about RIPS in the section Code Scanning Reflection.

Analysis of Yasca's results according to our requirements

Hereby, we are going to discuss about the results which were produced by Yasca when the code analysis tool has performed a scan over the FluxBB. It is important to mention that the execution was done in association with the PHPLint plugin (available in http://www.scovetta.com/yasca.html).

Yasca was able to report 206 findings, which were classified according to the type and severity as shown in the following table:

Amount	Type	Severity
13	SQL Injection	Critical
1	Cross-Site Scripting	Critical
1	Code Quality: Functions	Critical
3	Authentication: Weak Credentials	Critical
2	Authentication: Simple/Guessable Password Used	Critical
1	Unreleased Resource	High
1	Bug: Memory Allocation	High
4	Bug: Incorrect Null Check	High
1	Authorization: "Debug" Parameter Found	High
1	Weak Cryptography	Warning
35	Potentially Sensitive Data Under Web Root	Warning
4	Potentially Dangerous Technology: AJAX	Warning
2	Insecure Object Call	Warning
1	Authentication: Password Stored in Cleartext	Warning
4	Unknown, Non-Standard, or Obsolete Library Used	Low
1	Cross-Site Scripting	Low
35	Performance: Post Increment or Simple Variable	Informational
28	Performance: Function Within Loop Declaration	Informational
51	Best Practice: Short Open Tag	Informational
17	Best Practice: Always Quote Array Keys	Informational

The distribution of the findings may be visualized easily by means the following chart:

Classification of security vulnerabilities according to their severity

Since we are focused on requirements V4 (Access Control) and V9 (Data Protection), specifically on the topics related to the phase 1B of OWASP Application Security Verification Standard, we can establish the relationship between these topics and the found vulnerabilities as shown in following table:

Type	Severity	V4 (Access Control)	V9 (Data Protection)	Irrelevant	Reason
SQL Injection	Critical	X	X		A SQL Injection helps to access or delete easily data. Usually this task requires some special privileges. Also, it can help you to log with certain rights in order to give access to specific functions.
Cross-Site Scripting	Critical		X		Cross-site scripting attacks use the webb application to send malicious code, generally in the form of a browser side script, which may change the destiny of private data.
Code Quality: Functions	Critical			X
Authentication: Weak Credentials	Critical	X			The vulnerability is more related to the authentication requirements, but we have preferred to talk about this because the attacker can use it to acces unauthorized functions.
Authentication: Simple/Guessable Password Used	Critical	X			The vulnerability is more related to the authentication requirements, but we have preferred to talk about this because the attacker can use it to acces unauthorized functions.
Unreleased Resource	High			X
Bug: Memory Allocation	High			X
Bug: Incorrect Null Check	High			X
Authorization: "Debug" Parameter Found	High		X		The user may have access to debug information, which can provide private data about the system.
Weak Cryptography	Warning			X
Potentially Sensitive Data Under Web Root	Warning	X	X		The vulnerabilities are related to the existence of sensitive information which may be easily accessed.
Potentially Dangerous Technology: AJAX	Warning			X
Insecure Object Call	Warning			X
Authentication: Password Stored in Cleartext	Warning	X	X		If an attacker has access to password information which is in plaintext, he can use it to break into the system.
Unknown, Non-Standard, or Obsolete Library Used	Low			X
Cross-Site Scripting	Low		X		Yasca has reported this vulnerability with two different classifications.
Performance: Post Increment or Simple Variable	Informational			X
Performance: Function Within Loop Declaration	Informational			X
Best Practice: Short Open Tag	Informational			X
Best Practice: Always Quote Array Keys	Informational			X