SoftwareSecurity2014/Group 7/Verdict

V5.1 Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.

The application is programmed in PHP which is a higher level language. We therefore assume that buffer overflows are protected against or at least handled by the interpreter. There are no external programs required to run the code (for example executables). [1]

Hence Typo3 passes this requirement.

V5.2 Verify that a positive validation pattern is defined and applied to all input.

We note from the Fortify results that input validation was not applied on SQL queries, Server/Environment variables. There is a function called GP() defined, which parses the get and post variables when they are used. The list below only includes direct references to the get and post variables not to the ones parsed by the GP function.

The GP function does not do any validation pattern checking.

There are 53 occurrences of $_POST, of which 1 have a validation pattern checking.

Hence Typo3 failed this requirement

Furthermore we skipped the 11 occurrences of the use of post variables as input in the Exbase and Fluid framework tests. They are used to test the SQL connections etc. and are not relevant for the operation of the Typo3 web application.

The findings of the manual review:

./alt_doc.php, ./alt_shortcut.php

The occurrences of post data being used here is whether or not to save the document that is being edited. There is no validation whether these variables match a given pattern just the mere existence of them. However, the values set in the post variables are not used anywhere. Their mere existence signals whether the system will save this document or not.

./classes/class.typo3ajax.php

The post data is used to convert between character sets. No validation pattern is applied.

./init.php (line 338)

This call checks whether $_POST['GLOBALS'] is set. This check is needed because this might override the GLOBALS array of the script. If it is set via the post-variable, the script dies with an error 'You cannot set the GLOBALS-array from outside the script.'.

Furthermore it stores the stuff stored in $_POST and in $_GET into $HTTP_POST_VARS and $HTTP_GET_VARS. We could not find any occurrence of these variables being used again later on.

./sysext/adodb/adodb/adodb-perf.inc.php

This file has the following code:

if (isset($_POST['do'])) $do = $_POST['do'];

This line of code might lead to input validation vulnerabilities since there is no checking involved at all. However, later on in the script specific actions are taken (like show SQL-stats and such) based on the value of the $do variable. Technically this counts as pattern validation since the value of the parameter is checked and if it fails nothing is executed and an empty page is returned.

./sysext/cms/tslib/class.tslib_fe.php

The post data is used by this file to convert between character classes. There is no validation pattern checking performed.

./sysext/cms/tslib/content/class.tslib_content_form.php

On line 798:

if ($location == 'HTTP_POST_VARS' && isset($_POST['locationData'])) {

$locationData = t3lib_div::_POST('locationData');

}

This variable $locationData is later on escaped using htmlspecialchars and displayed as a hidden field in a form. It is used to track the post the user was viewing when this function was called. The htmlspecialchars() function converts special characters to displayable html code [2]. This does not count as verification pattern checking since the data can still be anything.

./sysext/cms/tslib/index_ts.php

The function t3lib_div::addSlashesOnArray is called upon the GET and POST parameters. Furthermore a check is performed if the data tries to set the GLOBAL array and the script dies if that is the case. This does not count for validation pattern checking since the variables are not compared to anything.

./sysext/install/mod/class.tx_install.php

This file is part of the installation script for Typo3. The only place where post data is being used is for the default username and password you want to install Typo3 with. The only validation done there is whether the two passwords entered (one should be a repetition of the other) match. This is done via a comparison of both MD5 hashes. Technically this is not the checking of a validation pattern.

./sysext/openid/class.tx_openid_return.php

This file is part of the openid framework. The use of post data in this file is used to get the login status of the user. No checking is done where this data comes from and if it's valid. It is passed on to backend.php.

V5.3 Verify that all input validation failures result in input rejection or input sanitization.

We could find only one piece of code where input was validated and not directly sanitized through functions such as stripslashes and preg_match. That piece of code is below, and it does result in input rejection.

Hence Typo3 passes this requirement.

typo3/sysext/install/mod/class.tx_install.php:2145-2152

if (!$this->formProtection->validateToken((string) $_POST['formToken'], 'installToolPassword', 'change'))

Input is validated by the function validateToken, which generates an error message and returns false. If false, the $doit flag is set to FALSE and later in the code the critical part is not executed. Effectively, the input is thus rejected.

V5.4 Verify that a character set, such as UTF-8, is specified for all sources of input.

First we note that when running the application on PHP version 6, this issue is no longer of any relevance [3]. Furthermore, there is no specific character set definitions for inputs throughout Typo3, which makes them default to the default input character set. In PHP v5 and v6 this defaults to UTF-8 [4].

The only two exceptions to this is the file ./contrib/json/json.php. This file converts input (may not be by the user) into json formatted output. It includes a function to convert all UTF-16 to UTF-8 and vice-versa. This function is only executed when the internal php mb_convert_encoding is not present (aka you are running a very old php installation).

And the file ./classes/class.typo3ajax.php converts character sets to a requested character set. This is used to display foreign languages via the AJAX front end.

Hence Typo3 fails this requirement, but as long as the PHP installation is set up securely it should not lead to any issues.

V5.5 Verify that all input validation is performed on the server side.

Not all input validation is performed on the server side, as there is also input validation done on the client side.

Therefore Typo3 fails this requirement (Erik:But given, as you say below, these server side checks are for user convenience and not for security, it is really fair to call this a fail? I'd say the ASVS is a bit sloppy in not clearly saying that server side checks are ok, as long as all security-relevant checks are ALSO done server side.)

./t3lib/jsfunc.validateform.js

This function validates form entries on the client side. However, this is more of a user convenience than a security measure. For example it checks whether an email address matches a defined regular expression and whether there are no fields in the form that are 'empty' (think of radio buttons that are not ticked). This function is called by ./typo3/sysext/cms/tslib/content/class.tslib_content_form.php which would imply it is used on forms throughout Typo3.

V5.6 Verify that a single input validation control is used by the application for each type of data that is accepted

The following input validation functions are called for the different types of data:

Input Validation Functions

Data type	Type of Validation
GET and POST	In most places, instead of using $_GET and $_POST variables directly, a custom function GP($var) is used. The GP($var) function first applies stripslashes() to the $_GET or $POST variable before returning it. Although we have previously argued that stripslashes was insufficient to combat injection attacks, nevertheless, using a single validation choke-point was a good coding practice. The input validation function can be subsequently upgraded with minimal hassle and error.
Forms	Depending on the fields of the form, two functions are utilised. The first is the PHP function call htmlspecialchars() which converts special characters to HTML entities. Although not part of this requirement, we note that it is also used extensively in output validation for presenting html links and SQL queries. The second validation is cleanFormName($name) which is more strict and applied to fields such as username. This function uses preg_replace to only allow the alphabets(a-z) and numbers (0-9).
Local URLs	Redirected URLs are sanitised by the custom function sanitizeLocalUrl($url). This function calls removeXSS(), another custom function which iteratively removes blacklisted characters and javascript keywords before applying a whitelist of acceptable characters. The sanitised URL is then checked if it is a valid URL on the local host and otherwise, an empty string is returned.
Search Queries	The function removeXSS() is called on the query string (See above for description of removeXSS().
File Names	During file upload, the file name is checked by the custom function cleanFileName(). This function calls preg_replace which replaces blacklisted characters (Erik: Note that this blacklisting is also more evidence of V5.2 being broken) with an underscore and converts special characters to ASCII depending on the character set.
Contents	Creating or changing contents is the main function of a CMS. Here, there are many different data types, each with a different validation check e.g. stripslashes is applied on the 'fieldname', removeXSS is applied on the 'label' etc.

(Erik: You take a rather coarse view of what 'data types' are. One could also take a more fine-grained view, and consider different fields to be of different type depending on their use/intended meaning. Eg, the two validation functions you mention under Forms, one for HTML and another for user names, suggest that not all fields have the same 'data type'. Of course, the ASVS is rather vague on what data types are meant to be.)

Although there are some notable exceptions e.g. no validation for SQL, the input validation strategy when present, is in general, well organised.

In the 'forms' and 'contents' data type, the different nature of the data fields call for a different input validation method. However, this makes it extremely tedious to verify and we need to scan through large amounts of code. The developers could have overcome this problem by creating a single input validation function which takes two input variables: the input to be validated and the data field type, which is exactly the security requirement.

Typo3 passes this requirement for most data types. Typo 3 fails this requirement for forms and contents

V5.7 Verify that all input validation failures are logged

Only when the checking of local URL fails, is the error sent to syslog. In all the other cases described above, input validation returns either the sanitised input or a null string, without logging.

Hence, Typo3 fails this requirement