SoftwareSecurity2013/Group 12/Code Scanning

Automated verification of requirements 1B

For the 1B verification there were only four requirements that had to be checked: V3.6, V11.1, V11.2 and V11.3. In the table below the findings of the tools are stated and after that we make some remarks about how useful these findings are.

Verification	Description	Tool	Warning	Level	Amount of warnings
V3.6	Verify that the session id is never disclosed other than in cookie headers; particularly in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies	Fortify	-	-	-
V11.1	Verify that redirects do not include unvalidated data	Fortify	Open redirects	Critical	35
V11.2	Verify that the application accepts only a defined set of HTTP request methods, such as GET and POST	Fortify	-	-	-
V11.3	Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8).	Fortify	-	-	-

Findings on the warnings

V3.6

Requirement V3.6 does not make much sense in the case of fluxBB, since it does not make use of sessions (and thus strictly speaking there is no sessionID). All the information needed to steal a user “session” relies on the cookie. Fortify does not give any warnings about this and we think this is correct because it is not applicable to fluxBB, but further (manual) inspection of the code is needed.

V11.1

Fortify is able to trigger warnings related to unvalidated data used on redirect function which could lead to different kind of attacks such as phishing and XSS. The tool classifies the warnings according the type of attack and it is easy to search and look through the vulnerable piece of code. RIPS does not trigger explicit warnings related to redirect functions, however a manual verification is possible in order to figure out if there is vulnerable piece of code despite the fact that the interpretation would not be given by the tool itself, but a correlation process with other warnings is needed.

Fortify can check for unvalidated data in redirects, for example when the filter is set up to ‘Any attribute contains redirect’. 8 lines produce warnings, of which 3 are critical, 3 are high and 2 are low.

The critical lines are:

<meta http-equiv="refresh" content="<?php echo $pun_config['o_redirect_delay'] ?>;URL=<?php echo $destination_url ?>" />

<?php echo $message.'

<a href="'.$destination_url.'">'.$lang_common['Click redirect'].'</a>' ?>

header('Location: '.str_replace('&', '&', $destination_url));

Upon manual inspection it seems that these 8 warnings are all false positives. FluxBB uses its own validator, and it is defined as

$destination_url = preg_replace('%([\r\n])|(\%0[ad])|(;\s*data\s*:)%i', , $destination_url);

Upon manual inspection, there appears to be 241 uses of redirects in the code. Fortunately, the validator is hardcoded in the function of redirect(), so every call to that function satisfies the requirement.

V11.2

Fortify and RIPS were not able to give any warnings related to requirement V11.2. A manual verification is needed to verify all methods that are used and to check if they only use a defined set of request methods.

V11.3

Fortify and RIPS were not able to give any warnings related safe character sets, so further manual inspection is definitely needed to verify this requirement