SoftwareSecurity2013/Group 4/Verdict
Inhoud
- 1 Applies to our verification requirement
- 1.1 V6.2 Verify that all output encoding/escaping controls are implemented on the server side.
- 1.2 V6.3 Verify that output encoding /escaping controls encode all characters not known to be safe for the intended interpreter.
- 1.3 V6.4 Verify that all untrusted data that is output to SQL interpreters use parameterized interfaces, prepared statements, or are escaped properly.
- 2 Does not apply to our verification requirement
Applies to our verification requirement
V6.2 Verify that all output encoding/escaping controls are implemented on the server side.
Every output encoding/escaping that is done, is done on the server side and not on the client side, so FluxBB passes this requirement.
V6.3 Verify that output encoding /escaping controls encode all characters not known to be safe for the intended interpreter.
If the encoding/escaping is done, then all characters not known to be safe for the intended interpreter are encoded/escaped. For our database abstraction layer (mysql_innodb) the escape function is not completely correct:
function escape($str) { if (is_array($str)) return ; else if (function_exists('mysql_real_escape_string')) return mysql_real_escape_string($str, $this->link_id); else return mysql_escape_string($str); }
If the function mysql_real_escape_string does not exist, this code is not safe, because mysql_escape_string doesn't control the character encoding for the database. Multibyte characters could be handled as singlebyte characters which could result in an unsafe database.
Because the database software is already very old if the mysql_real_escape_string does not exist, it's not only a problem with this requirement if it fails. That's why FluxBB almost passed this requirement.
V6.4 Verify that all untrusted data that is output to SQL interpreters use parameterized interfaces, prepared statements, or are escaped properly.
FluxBB does not use a parameterized interface nor prepared statements. Escaping is properly when it's used, but because escaping is not done everywhere, this requirement is failed.
function table_exists($table_name, $no_prefix = false) { $result = $this->query('SHOW TABLES LIKE \.($no_prefix ? : $this->prefix).$this->escape($table_name).'\); return $this->num_rows($result) > 0; }
function field_exists($table_name, $field_name, $no_prefix = false) { $result = $this->query('SHOW COLUMNS FROM '.($no_prefix ? : $this->prefix).$table_name.' LIKE \.$this->escape($field_name).'\); return $this->num_rows($result) > 0; }
In this example you see that $table_name is escaped in the function $table_exists but isn't escaped in the function $field_exists. Although escaping is done almost anywhere, one place where it isn't done could break things down completely.
Does not apply to our verification requirement
The following requirements did not apply to our scope. Our assignment was to verify the output escaping and encoding of the SQL output. Therefore, HTML, XML, LDAP, system commands and any other data outputted to an interpreter other than SQL data is not a part of our scope.
V6.1 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.
V6.5 Verify that all untrusted data that are output to XML use parameterized interfaces or are escaped properly.
V6.6 Verify that all untrusted data that are used in LDAP queries are escaped properly.
V6.7 Verify that all untrusted data that are included in operating system command parameters are escaped properly.
V6.8 Verify that all untrusted data that are output to any interpreters not specifically listed above are escaped properly.