SoftwareSecurity2014/Group 13/Verdict

Uit Werkplaats
Ga naar: navigatie, zoeken

Verdict

V6.1 Fail

Verify that all untrusted data that are output to HTML (including HTML elements, HTML attributes, javascript data values, CSS blocks,and URI attributes) are properly escaped for the applicable context.

We found that php's htmlspecialchars function is used to HTML-encode everything, except for one variable:

The following code snippets are from db-update.php, and show an XSS attack possibility.

$old_charset = isset($_REQUEST['req_old_charset']) ? str_replace('ISO8859', 'ISO -8859', strtoupper($_REQUEST['req_old_charset'])) : 'ISO -8859-1';
<input type="text" name="req_old_charset" size="12" maxlength="20" value="<?php echo $old_charset ?>" />

In short, the GET parameter req_old_charset is echoed in uppercase, and executing /db update.php?req old charset=*code* can result in unwanted behavior: Screenshot xss.png

V6.2 Pass

Verify that all output encoding/escaping controls are implemented on the server side.

There is hardly any JavaScript. Thus most escaping is done by the server. Also this requirement is not really clear, since if the client escapes the data for the server, and the server accepts it blindly. Isn't that an input validation problem instead? (Erik: This requirement is indeed a bit confusing - I think it should sya: there are no output encoding/escaping controls on the client side that the server relies on. It is fine to have some client side validation (eg for quick feedback to the user when they make typos), as long as any security-critical validation is ALSO done server side.)

V6.3 Not sure Fail?

Verify that output encoding/escaping controls encode all characters not known to be safe for the intended interpreter.

In post.php, we see the function strip_bad_multibyte_chars to replace 4-byte characters with question marks, because older MySQL versions can't handle those characters. This seems quite hacky, but more importantly, this 'check' is only performed for the message body of a post, whereas, for instance, the topic title is just passed on to the database without escaping of any kind.

V6.4 Fail

Verify that all untrusted data that is output to SQL interpreters use parameterized interfaces, prepared statements, or are escaped properly.

FluxBB does not use prepared statements, which is enough to fail this point. It does use the php functions mysql_escape_string and mysql_real_escape_string, but these have both been deprecated for quite some time. Although we did not find an actual problem, we would discourage the dynamical creation of SQL code, as shown here:

$db->query('UPDATE '.$db->prefix.'posts SET message=\''.$db->escape($message).'\', hide_smilies='.$hide_smilies.$edited_sql.' WHERE id='.$id);
$edited_sql = (!isset($_POST['silent']) || !$is_admmod) ? ', edited='.time().', edited_by=\'' .$db->escape($pun_user['username']).'\'' : '';

V6.5 Pass

Verify that all untrusted data that are output to XML use parameterized interfaces or are escaped properly.

FluxBB does not use XML output and thus it passes correctly outputting all XML.

V6.6 Pass

Verify that all untrusted data that are used in LDAP queries are escaped properly.

FluxBB does not use LDAP and thus it passes this requirement.

V6.7 Not checked

Verify that all untrusted data that are included in operating system command parameters are escaped properly.

V6.8 None?

Verify that all untrusted data that are output to any interpreters not specifically listed above are escaped properly.

We did not find other output then HTML and SQL.