SoftwareSecurity2013/Group 42/Verdict

Verdict on the security requirements

• (V5.1) Runtime environment is not susceptible to buffer overflows
  • Obviously, since PHP does not allow for pointer manipulation by the programmer and bounds checking is done on the language level, any application written in PHP cannot be vulnerable to buffer overflows. With the notable exception of internal php functions and extensions written in C/C++. However this is not relevant for the code we're assessing.

Verdict: pass.

• (V5.2) Positive validation pattern is defined and applied to all inputs
  • All command executions are handled by wfShellExec, which among other things correctly sanitizes the input to passthru.
  • All strings appended to a query are first passed through DatabaseBase::strencode before feeding them to DataBase::doQuery. (Erik:Note that in the ASVS classification this is (confusingly, admittedly) classified as an output validation issue, namely validating output to the SQL backend)
  • All (some exceptions do apply) strings echo'ed to the output are first passed through htmlspecialchars. We found no place where ENT_QUOTES was required and not used.

Verdict: partial-fail. We found an XSS vulnerability in an extension to mediawiki that is shipped by default. All the other code seems to sufficiently sanitize the output. We argue it is not a complete fail since mediawiki takes appropriate precautions to minimize the attack implications by flagging session cookies HttpOnly. (Erik:Note that this security requirement is asking if a positive approach (ie whitelisting rather than blaclisting) is used for input validation, something that you do not really answer.)

• (V5.3) All input validation failures result in input rejection or input sanitization
  • The same answer applies from the requirement above: all input is properly sanitized except for one XSS vulnerability we found. Additionally, we found that the sanitation functions used do properly sanitize the input.

Verdict: partial-fail.

• (V5.4) A character set is specified for all sources of input.
  • Everything seems to be configured to use UTF-8. We were unable to find a single script that does not specify UTF-8 as the character set to use.

Verdict: pass.

• (V5.5) All input validation is performed on the server side
  • As far as our knowledge goes, no client-side input validation exists within mediawiki. It is not really relevant since all inputs are also validated server-side.

Verdict: pass.

• (V5.6) A single input validation control is used by the application for each type of data that is accepted
  • In case of sanitizing output in order to prevent XSS the internal PHP function is used, which can be considered a single input validation control.

In the other cases an input validation control is given by mediawiki. (Erik:How many of these input validation controls are there, and what are they? Eg I can image there is one for email adresses, for usernames, etc.etc. It would have been nice to read in your report somewhere which forms of input validation there are.)However it is possible for a programmer to access lower level functions directly without calling input validation functions. We did not find any occasion where an input validation control is bypassed, creating a security vulnerability, using automated tools.

Verdict: pass.

• (V5.7) All input validation failures are logged
  • Input is always sanitized, never rejected. Therefore input validation failures never occur.

Verdict: pass.