Madison Gurkha Security AdvisoryAdvisory: TYPO3 circumvent RemoveXSS.php cross site scripting using BASE64 encoding1. DETAILS----------Product: Typo3 CMSVendor URL: typo3.orgType: Cross-site Scripting[CWE-79]Date found: 2016-03-09Date published: 2016-05-192. AFFECTED VERSIONS--------------------Typo3 6.2.19 and belowTypo3 7.6.4 and belowand other older versions may be affected too.Until the removal of the RemoveXSS.php function, versions will be affected.3. VULNERABILITY DETAILS------------------------The filter (RemoveXSS.php) to prevent XSS attacks when using the TYPO3framework can be circumvented.The filter is based on a blacklist method which specifies the actionsthat are not allowed. It is not recommended to implement security basedon blacklisting methods. Proper input validation and output escaping (inthe proper context) should be a sufficient measure against XSS attacks.According to the filter it is allowed to add special characters like"/><. These characters make it possible to create a reflected XSS attackin a HTML5 type response.Inserting the following BASE64 encoded string results in a reflected XSSvulnerability:"/>href="data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+">Click!This vulnerability is discovered while testing the LTS versions 7.6.4and 6.2.19.Note that only applications that use this function will be affected.4. SECURITY RISK----------------An attacker is able to prepare a URL which, when requested by the victim,causes JavaScript under control of the attacker to be executed in the contextof the browser of the victim. For example an attacker can steal (session) cookiesor attack the browser and its components.5. SOLUTION-----------Do not use the RemoveXSS.php functionality.Instead of creating a blacklist use whitelisting to prevent XSS.Also whenever user input is included in (X)HTML documents,meta-characters need to be escaped (depending on the context).In HTML elements, this means that the characters <, >, and & need to beescaped, by replacing them by the strings <, > and & respectively.In values of attributes, depending on the type of quotes used,the character ? or " needs to be replaced by ' (in XHTML ' may be used)or " respectively.There is no harm in always escaping both.In JavaScript string literals the characters ? or " (depending on thetype of quotes used) need to be replaced by respectively \? or \".There is no harm in always escaping both.Also, the characters \, line feed, carriage return, line separator andparagraph separator need to be replaced by respectively \\, \n, \r, \u2028 and \u2029.Validate user input, making sure that only suitable characters areaccepted based on whitelisting.6. REPORT TIMELINE------------------2016-04-19: Vulnerability discovered2016-04-21: Vendor notified2016-04-26: Vendor acknowledges the vulnerability2016-05-18: Vendor permission for disclosure7. REFERENCES / CREDITS-----------------------This vulnerability was discovered and researched by Mandy van Oosterhout fromMadison Gurkha.Madison Gurkha--------------Madison Gurkha supports organizations with high quality services to efficiently identify,mitigate and prevent IT security risks.For more information visit http://ift.tt/1OBfHEV.[ reply ]from SecurityFocus Vulnerabilities http://ift.tt/1U1nm0J
Madison Gurkha Security Advisory
Advisory: TYPO3 circumvent RemoveXSS.php cross site scripting using BASE64 encoding
1. DETAILS
----------
Product: Typo3 CMS
Vendor URL: typo3.org
Type: Cross-site Scripting[CWE-79]
Date found: 2016-03-09
Date published: 2016-05-19
2. AFFECTED VERSIONS
--------------------
Typo3 6.2.19 and below
Typo3 7.6.4 and below
and other older versions may be affected too.
Until the removal of the RemoveXSS.php function, versions will be affected.
3. VULNERABILITY DETAILS
------------------------
The filter (RemoveXSS.php) to prevent XSS attacks when using the TYPO3
framework can be circumvented.
The filter is based on a blacklist method which specifies the actions
that are not allowed. It is not recommended to implement security based
on blacklisting methods. Proper input validation and output escaping (in
the proper context) should be a sufficient measure against XSS attacks.
According to the filter it is allowed to add special characters like
"/><. These characters make it possible to create a reflected XSS attack
in a HTML5 type response.
Inserting the following BASE64 encoded string results in a reflected XSS
vulnerability:
"/>
href="data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9z
Y3JpcHQ+">Click!
This vulnerability is discovered while testing the LTS versions 7.6.4
and 6.2.19.
Note that only applications that use this function will be affected.
4. SECURITY RISK
----------------
An attacker is able to prepare a URL which, when requested by the victim,
causes JavaScript under control of the attacker to be executed in the context
of the browser of the victim. For example an attacker can steal (session) cookies
or attack the browser and its components.
5. SOLUTION
-----------
Do not use the RemoveXSS.php functionality.
Instead of creating a blacklist use whitelisting to prevent XSS.
Also whenever user input is included in (X)HTML documents,
meta-characters need to be escaped (depending on the context).
In HTML elements, this means that the characters <, >, and & need to be
escaped, by replacing them by the strings <, > and & respectively.
In values of attributes, depending on the type of quotes used,
the character ? or " needs to be replaced by ' (in XHTML ' may be used)
or " respectively.
There is no harm in always escaping both.
In JavaScript string literals the characters ? or " (depending on the
type of quotes used) need to be replaced by respectively \? or \".
There is no harm in always escaping both.
Also, the characters \, line feed, carriage return, line separator and
paragraph separator need to be replaced by respectively \\, \n, \r, \u2028 and \u2029.
Validate user input, making sure that only suitable characters are
accepted based on whitelisting.
6. REPORT TIMELINE
------------------
2016-04-19: Vulnerability discovered
2016-04-21: Vendor notified
2016-04-26: Vendor acknowledges the vulnerability
2016-05-18: Vendor permission for disclosure
7. REFERENCES / CREDITS
-----------------------
This vulnerability was discovered and researched by Mandy van Oosterhout from
Madison Gurkha.
Madison Gurkha
--------------
Madison Gurkha supports organizations with high quality services to efficiently identify,
mitigate and prevent IT security risks.
For more information visit http://ift.tt/1OBfHEV.
[ reply ]