SoftwareSecurity2014/Group 4/Verdict

LEVEL 1B - Source Code Scan (Partial Automated Verification)

Nr	Verification Requirement	Verdict	Comment
V5.1	Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.	Pass	The possibility of buffer overflow happened in PHP is when there is a bug in the apache itself. Some buffer overflow vulnerability was found in the CGI version of PHP 5.4. While for the Mibew code itself, there is no buffer overflow existing.
V5.2	Verify that a positive validation pattern is defined and applied to all input.	Fail	The white list input validation was done using these functions preg_match() and preg_match_all(). However, not all input was validate using white-listing. Most of them was done using black-listing or sanitizing.

LEVEL 2B - Code Review (Partial Manual Verification)

Nr	Verification Requirement	Verdict	Comment
V5.3	Verify that all input validation failures result in input rejection or input sanitization	Pass	Mibew uses input sanitization methods or directly rejects the operation when there is a possibility of invalid data input. (Erik:Are you really that confident all inputs are validated? In most applications it is hard to be sure...) The blacklisting validation was done using several functions such as safe_htmlspecialchars(), prepare_html_message(), and sanitize_string(). (Group 4: Yes, we are sure. In mibew, the input form is put under the "View" folder. In the manual check, we divide all the php code so that each of us got 10 php files per person to be checked. We also checked the php code that we consider as highly related with the Input Form, which is the php files in the "Operator" folder. We consider these files as highly related because all of the form in mibew was redirected into a php files under "Operator" folder. We can see this form the "action" command inside the <form >. Based on our research, all of the <input > value was sanitized using safe_htmlspecialchars(), prepare_html_message(), and sanitize_string() )
V5.4	Verify that a character set, such as UTF-8, is specified for all sources of input	Pass	The setting variable for encoding to UTF-8 was defined in the file config.php. This variable was called from getoutputenc() function which embedded in the function getparam(). This function was called to validate and encode the user input.
V5.5	Verify that all input validation is performed on the server side	Fail	Some input validation was performed in the client-side, which is using javascript. Mibew does the htmlescape validation in the javascript. There are three javascript files that perform some validation, which is brws.js, chat.js, common.js. (Erik: Client-side input validation is only a security risk if the validation is not repeated at the client side. I think this V5.5 is a bit unclear in that respect. Eg it is fine to do some validation client side, eg to give quick feedback to the user, as long as the security-critical validation ALSO happens client side. (Group 4: I think you mean server side here?) Was that the case here?)
V5.6	Verify that a single input validation control is used by the application for each type of data that is accepted	Pass	Each user input in the form structure is captured by specific functions which have input validation checks such as sanitization.
V5.7	Verify that all input validation failures are logged	Fail	There are no logs related to the input validation failure, either files nor database's tables. Another thing that worth to mention is that all the SQL errors are returned back with 'mysql_error()' directly on the screen, which might leak information regarding the database. (Erik:and it probably does :-) Note that there is in fact another set of security requirements, V8.*, specifically about handling errors )