Software Security/Group 2/Verdict

Introduction

In this section the findings of the code scanners are cross-examined with the OWASP verification requirements.The focus for this group is Output Encoding/Escaping where it concerns SQL. As such we will be looking at the corresponding items from the OWASP Application Security Verification Standard (ASVS).

Associated security verification levels

This sections will briefly summarize the levels taken into consideration given the scope and focus of our group.

Level 1 - Automated Verification

This level deals with tool assisted verification supported by manual inspection. Level1 is constituted of two sub-levels dealing with both static and dynamic code verification. Of which we will only be looking at level 1b: static code verification.

Level 2 - Manual Verification

As with level 1, the use of automated tools is assumed. Unlike level 1, these tools should merely be used to point the verifier to locations in the code which need special attention. The tools are now also required to use a white-list approach. From this level we will be looking at both code Review as Security Test

On the verification requirements

V6.1

Verify that all untrusted data that are output to HTML (including HTML elements, HTML attributes, javascript data values, CSS blocks,
and URI attributes) are properly escaped for the applicable context.

This verification requirement, is beyond our scope, since this is about output to HTML (which is the subject of Group 1). According to the verdicts of this group, the requirements fails.

V6.2

Verify that all output encoding/escaping controls are implemented on the server side. 

V6.3

Verify that output encoding/escaping controls encode all characters not known to be safe for the intended interpreter.

This requirement fails because a blacklist is used instead of a whitelist. So in fact it is done the other way around. The escape all characters that are known to be unsafe.

V6.4

Verify that all untrusted data that is output to SQL interpreters use parameterized interfaces, prepared statements, or are escaped properly. 

V6.5

Verify that all untrusted data that are output to XML use parameterized interfaces or are escaped properly.

For this requirement to pass we have to check if all code data from the database that is used in XML documents is escaped properly. The don't know if this is true for the code. None of the code scanners we used gave us an easy way to find this out.

Checking the results by hand, in the CodeSecure results we did not find any issues relating to XML. This is also the case for SWAAT. However Fortify delivers many results but we could not find any result that is concerned about XML.

We also searched the code for the term 'xml'. We did not find any results. So according to our research there is no XML in the phpBB source code.

V6.6

Verify that all untrusted data that are used in LDAP queries are escaped properly.

We did not find any LDAP queries in the phpBB code. So it does not make sense to give a verdict on this requirement.

V6.7

Verify that all untrusted data that are included in operating system command parameters are escaped properly.

There are several ways to do operating system commands in PHP, for example with the buildin php functions system, exec and passthru. (see also php documentation http://php.net/manual/en/book.exec.php)

We have searched the code for these commands, but we did not find any of these php functions in the code. Therefore we consider this requirement as not applicable.

V6.8

Verify that all untrusted data that are output to any interpreters not specifically listed above are escaped properly. 

This requirement fails. A problem is that resource injection is possible with data from the database. Data is directly used in the php fopen function not escaped properly. Two examples are resource injection 1 and resource injection 2. Also dangerous file inclusion is possible because data from the database is not properly escaped, see file inclusion 1, file inclusion 2, file inclusion 3, file inclusion 4.

There is also data requested from the database that is used without being checked as a destination email address for an email. Two examples are email 1 and email 2.

Other V6 verification requirements

Because of the limitation to do only verification on levels 1b and 2b, we do not consider the following verification requirements, Since these are only applicable on level 3 (both) and level 4 (V6.10).

V6.9

Verify that for each type of output encoding/escaping performed by the application, there is a single security control for that type of output
for the intended destination.

V6.10

Verify that all code implementing or using output validation controls is not affected by any malicious code.

Listing of applicable verification requirements

In the following table the level 1b and level 2b verification requirements are shown for V6. This table will eventually summarize our findings.

Number	Verification Requirement	Pass, Fail, N/A	Reason
V6.1	Verify that all untrusted data that are output to HTML (including HTML elements, HTML attributes, javascript data values, CSS blocks, and URI attributes) are properly escaped for the applicable context.	N/A	This is HTML output, we focus on SQL output. This is interesting for group 1.
V6.2	Verify that all output encoding/escaping controls are implemented on the server side.	FAIL	There are unchecked post variables that will play a part in the markup of insert and update statements. These are then once again just checked for quotes, in stead of thoroughly verified against a whitelist.
V6.3	Verify that output encoding /escaping controls encode all characters not known to be safe for the intended interpreter.	FAIL	Escaping works the other way within the phpbb source code. Often only single quotes are escaped. A blacklist is used instead of a whitelist so only characters that are know to be unsafe are escaped.
V6.4	Verify that all untrusted data that is output to SQL interpreters use parameterized interfaces, prepared statements, or are escaped properly.	FAIL	We have found no evidence of stored procedures, and escaping of statements is minimal. No whitelist, but rather a blacklist approach where the bare minimum (like single quotes) is scanned for.
V6.5	Verify that all untrusted data that are output to XML use parameterized interfaces or are escaped properly.	N/A	In results of CodeSecure/SWAAT/Fortify we did not find any issues relating to XML. Grabbing on the word xml gave us no results. ??Erik: shouldn't this be a pass then?
V6.6	Verify that all untrusted data that are used in LDAP queries are escaped properly.	N/A	There are no LDAP queries in the code. ??Erik: shouldn't this be a pass then?
V6.7	Verify that all untrusted data that are included in operating system command parameters are escaped properly.	N/A	There are no operating system commands in the code ??Erik: shouldn't this be a pass then?
V6.8	Verify that all untrusted data that are output to any interpreters not specifically listed above are escaped properly.	FAIL	The code contains the following vulnerabilities caused by unescaped data from database: Resource injection, Dangerous file inclusion and CRLF Injection