SoftwareSecurity2013/Group 1/Verdict

Verdict on the security requirements

• (V5.1) Runtime environment not susceptible to buffer overflows
  • Not checked because, in general, PHP is not susceptible to buffer overflows because it is an interpreted language. It's dependent on the (combination of) OS, Apache, PHP, MySQL and/or other software versions used. Just in case we could get some new points of interest, we used Nessus, but it gave no indication of any vulnerabilities for this specific run.

Verdict: pass. We decided this was not relevant for FluxBB.

• (V5.2) Whitelist input validation on all inputs
  • SQL injections are mitigated by the $db->escape() function. (whitelist filter)
  • XSS attacks are mitigated by the pun_htmlspecialchars() function. (whitelist filter)
    • Input on admin pages is not always validated.
    • Input gets checked when it is displayed, not when it is stored in the database.

Verdict: partial-fail. FluxBB does not comply to this security requirement because not all input is checked, namely the admin pages. For the other parts of the system (the database, the core and public pages) the verdict is that FluxBB passes. We reached this verdict with stack traces generated by the RIPS tool and manual code inspections.

• (V5.3) All input validation failures lead to input rejection or sanitization
  • The functions which check for malicious input sanitize the input immediately.

Verdict: pass. We reached this verdict by analyzing the functionality of the sanitation functions.

• (V5.4) UTF-8 character set is used for all sources of input
  • All the UTF-8 character files got checked manually.

Verdict: pass. We determined every input is treated as UTF-8 because of the implementation of the sanitize functions.

• (V5.5) All input validation is performed on the server side
  • FluxBB contains no client side validation.

Verdict: pass. We manually checked all javascript files and determined no input is handled by javascript.

• (V5.6) All input validation is done in a central input validation
  • No central point for everything, but for SQL there is a central function and for XSS there is another central function.

Verdict: pass. Although there is not one central input validation, the design choice made by FluxBB is sufficient for the different kind of vulnerabilities. (Erik:I agree with your interpreatation here; i think V5.6 should be read as "one central input validation for each type of input", as input validation for say SQL and XSS is very different)

• (V5.7) Validation failures are logged
  • If an error occurs, nothing is logged.

Verdict: fail. FluxBB does not have a error logging system.