SoftwareSecurity2012/Group 2/Verdict

Verdict on security requirements

In the previous section the Application Security Verification Standard (ASVS) is introduced. From the 14 categories of security requirements this standard provides, we analyse requirements in the categories Input validation(V5), Output Encoding/Escaping(V6), Error Handling and Logging (V8).

Results

In the tables below, a verdict for each requirement in each category is shown. These verdicts are based on manual code inspection (see section manual inspection) and automated inspection by Yasca en RIPS.

V5 - Input Validation Verification Requirements

Verification requirement		Verdict	Motivation
V5.1	Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.	Pass	It is not possible to get buffer overflows in PHP unless there is a bug in the running PHP version or you make use of external tools which can get buffer overflows. A bug in PHP would be unrelated to FluxBB and there are no external tools used which can created the possibility of a buffer overflow.
V5.2	Verify that a positive validation pattern is defined and applied to all input.	Fail	Due to bad coding style we think there is no positive validation pattern applied. Even though it might all work perfectly fine now, whenever you have bad code standards the chance of bugs is higher with each version you release.
V5.3	Verify that all input validation failures result in input rejection or input sanitization.	Pass	The only input validation rejection possible for making a forum post is if the field is required or not. The data is escaped using mysql_escape_string (if the php version is lower than 5.30) or mysql_real_escape_string (if php 5.30 or higher), which has vulnerabilities but can not be exploited in fluxbb.
V5.4	Verify that a character set, such as UTF-8, is specified for all sources of input.	Fail	UTF-8 is used, which comes back in multiple parts of the code, but is never enforced, which might lead to problems.
V5.5	Verify that all input validation is performed on the server side.	Pass	Even with javascript disabled (which was used for client side checks) input validation was done. However, the only input validation that was performed is if the field was required or not.
V5.6	Verify that a single input validation control is used by the application for each type of data that is accepted.	Pass	We only check for one type, which is only text data.
V5.7	Verify that all input validation failures are logged.	Fail	Nothing for the input validation is logged, as there is no logging functionality specifically for fluxbb
V5.8	Verify that all input data is canonicalized for all downstream decoders or interpreters prior to validation.	N/A	Not at level 1 or 2
V5.9	Verify that all input validation controls are not affected by any malicious code.	N/A	Not at level 1 or 2

V6 - Output Encoding/Escaping Verification Requirements

Verification requirement		Verdict	Motivation
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.	Fail	The custom BBCode plugin causes the following output escaping error (A bit more explanation on how the plugin allows this would be good, it's a bit cryptic to me).
V6.2	Verify that all output encoding/escaping controls are implemented on the server side.	Pass	The only client side scripting does input requirement checks, so this is all done server side.
V6.3	Verify that output encoding /escaping controls encode all characters not known to be safe for the intended interpreter.	Pass	We believe this is the case.
V6.4	Verify that all untrusted data that is output to SQL interpreters use parameterized interfaces, prepared statements, or are escaped properly.	Pass	It would have been better to see parameterized interfaces and prepared statements, but everything in FluxBB is done using concatenation and escaping.
V6.5	Verify that all untrusted data that are output to XML use parameterized interfaces or are escaped properly.	N/A	There is no XML output in FluxBB
V6.6	Verify that all untrusted data that are used in LDAP queries are escaped properly.	N/A	There are no LDAP queries in FluxBB
V6.7	Verify that all untrusted data that are included in operating system command parameters are escaped properly.	N/A	Not at level 1 or 2
V6.8	Verify that all untrusted data that are output to any interpreters not specifically listed above are escaped properly.	N/A	Not at level 1 or 2

V8 - Error Handling and Logging Verification Requirements

Verification requirement		Verdict	Motivation
V8.1	Verify that that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id and personal information.	Pass	There is one function that creates pages for error/message output, where no sensitive data is leaked.
V8.2	Verify that all server side errors are handled on the server.	Pass	Whenever there is an error, it is handled on the server using the error page function or die.
V8.3	Verify that all logging controls are implemented on the server.	N/A	There are no logging controls in FluxBB.
V8.4	Verify that error handling logic in security controls denies access by default.	N/A	Not within scope of the FluxBB custom BBCode plugin.
V8.5	Verify security logging controls provide the ability to log both success and failure events that are identified as security-relevant.	N/A
V8.6	Verify that each log event includes: a time stamp from a reliable source, severity level of the event, an indication that this is a security relevant event (if mixed with other logs), the identity of the user that caused the event (if there is a user associated with the event), the source IP address of the request associated with the event, whether the event succeeded or failed, and a description of the event.	N/A
V8.7	Verify that all events that include untrusted data will not execute as code in the intended log viewing software.	N/A
V8.8	Verify that security logs are protected from unauthorized access and modification.	N/A
V8.9	Verify that there is a single logging implementation that is used by the application.	Fail	There are no logging implementations in or used by the application.
V8.10	Verify that that the application does not log application-specific sensitive data that could assist an attacker, including user's session ids and personal or sensitive information.	Pass	Is nothing is logged this does not happen.
V8.11	Verify that a log analysis tool is available which allows the analyst to search for log events based on combinations of search criteria across all fields in the log record format supported by this system.	N/A
V8.12	Verify that all code implementing or using error handling and logging controls is not affected by any malicious code.	N/A	Not at level 1 or 2

Analysis

The results of the manual code inspection and the automated analyis of the source code show that four out of nine of the Input Validation Requirements pass our inspection. Two of the requirements cannot be analysed because they are not available on level 1 or 2 of the security levels in the ASV standard (Saying that they are `not available' is a bit strange; i'd say they are `out of scope' or `do not apply' ). Three requirements are not met by Flux BB and the Custom BBCode modification. The input validation failures are not logged. There is no logging functionality for FluxBB. The code is not validated(What `code' do you mean here?). This means that although no errors occur in the current version of the code, errors might occur in future versions. For the input, UTF-8 is used. They do not enforce this character set, which might cause errors.

For the eight Output Encoding/Escaping Verification Requirements, four are available on level 1 and 2. Of these four, only the first requirement does not pass the test: the untrusted data that are output to HTML are not always properly escaped. We even found an error about output escaping (see results table).

For the twelve Error Handling and Logging Verification Requirements, eight are not available on the first or second verification level. Of the four security requirements, one of the requirements does not pass: The requirement that does not pass is about logging. The forum application does not use or implement any logging functionality.