SoftwareSecurity2012/Group 2/Requirements

Security requirements

The Open Web Application Security Project (OWASP) provides the Application Security Verification Standard (ASVS), a standard that provides a basis in testing for security related issues in applications and the tools they depend on. Within this standard, high level security requirements are being designed for various area's. For each area there are various verification levels defined. The requirements for each area that are listed by OWASP are listed in the table below, each with a short explanation. (Source:OWASP ASVS).

Verification requirement		Explanation
V1	Security Architecture	The security requirements in relation to the architecture of the system are about consistency between the documentation of the system and the implementation of the system and about the accuracy of the system.
V2	Authentication	The authentication requirements defined in ASVS are about where the authentication is performed, how the user credentials are entered and handled by the system, how and where authentication takes place and how this procedure is implemented.
V3	Session Management	The session management requirements define how to properly to manage sessions with regard to HTTP requests, responses, sessions, cookies, headers, and logging.
V4	Access Control	The access control requirements define how an application should design and implement access control on different levels for URLs, business functions, data, services, and files.
V5	Input Validation	The requirements about input validation define how input can be safely entered and validated and on which place in the system this should take place.
V6	Output Encoding/Escaping	The safety requirements with regard to output encoding are about making sure that all output of the system is encoded and escaped in for example SQL, XML or LDAP code.
V7	Cryptography	The cryptography security requirements are about the security of the crypograpic modules in the application.
V8	Error Handling and Logging	Error handeling and logging requirements define where the error handling and logging should take place in an application, and about the accuracy of the logging of the errors.
V9	Data Protection	The data protection security requirements define how to handle sensitive information in an application, including critical personal information. The requirements define where the information should be stored, and define what features like auto-completion not to use with this sensitive data.
V10	Communication Security	The communication security requirements suggest about the use of (secure) protocols in communication between servers and clients.
V11	HTTP Security	HTTP security requirements include requirements about the use of HTTP requests, responses, sessions, cookies, headers, and logging
V12	Security Configuration	The security configuration requirements can be used to verify how the security-relevant configuration is stored and secured.
V13	Malicious Code Search	The malicious code requirement defines that new code needs to be verified to make sure it does not include malicious code in either the application itself, or in any libraries or configuration files or other dependent code.
V14	Internal Security	The internal security requirements are about protecting the application against implementation flaws, like for example errors made by developers while using any of the security control interfaces.

Within this research, not all security area's identified in ASVS are being investigated. From the 14 available area's, we choose to investigate the vulnerabilities in the BBcode module in three areas.

The areas we investigate are Input validation(V5), Output Encoding/Escaping(V6), Error Handling and Logging (V8). The choice for these areas is motivated by the kind of modification for the FluxBB forum we focus on in this research. BBCode is a markup language which can be used make use of HTML, without having to type the HTML code each time. This means that an administrator can create new tags, consisting of a tag name and the HTML code that its output consists of. This poses a risk when system administrators using this tool do not know exactly what they are doing. When a new BBCode command is created, new risks can be introduced by the way the command is constructed. This means that a user might input risky code into a new tag, bypassing the input validation of the forum software or the input validation of php. Also, a new BBCode command might introduce risks in the area of output encoding/escaping. If the input in the tag is not properly escaped, or escapes a command that appears earlier on the website, it might cause security risks. New text that is inserted into a BBCode might cause errors. If it does cause errors, it should also handle these errors.