This post was originally published here by aliaksei kulik.
Cross Site Scripting (XSS) is one of the most common application security vulnerabilities and it affects many web applications. XSS attacks occur when an attacker uses a web application to send malicious code (generally in the form of a browser side script) to a different end-user. Flaws allowing these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user, and the output is generated without validating or encoding it. The CloudPassage Halo log-based intrusion detection system (LIDS) is a Halo security module that allows you to monitor server log files for events of interest, and receives alerts when such events occur. The module is available to Halo users on both Linux and Windows platforms.
Recently, we released a LIDS template that detects these XSS attacks. While developing the template I focused my work on the guidance provided by the Open Web Application Security Project (OWASP), along with my own extensive research.
Altogether there are about 137 rules in the template as shown below:
The policy can be run with Apache logs or on mod_security logs by enabling mod_security. And the rules detect the following broad categories of XSS attack techniques:
- Cookie Injections (Cross Site Scripting Cookie injection)
- XRS (Cross Site Referer Scripting)
- XAS (Cross Site Agent Scripting)
- DOM (Use Anchor Stealth (DOM based))
- DCP (Data Control Protocol injections)
- Included (HTTP Response Splitting Induced code)
- Anchor (Use Anchor Stealth payloader (DOM shadows!))
- OnMouse (Use onMouseMove )
- Iframes (inject code Use “iframe” source tag to inject code}
This LIDS template policy can detect an attack as “Bypass attacks” and a variations of “Obfuscation code.” Some obfuscation types are covered below:
- StringFromCherCode
- Hexadecimal with/without semicolons
- Octal
- Unescape
- Decimal
- Dword
For example:
Method String.FromCharCode()
If no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to create any XSS vector, meaning you need:
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>
Hexadecimal HTML character references without trailing semicolons. This is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol – which is not true with hex HTML characters).
<IMG SRC=jascript:alert('XS')>
Octal encoding. Again padding is allowed, although you must keep it above four total characters per class – as in class A, class B, etc…:
<A HREF=”http://150 164 164 160 72 57 57 61 63 56 65 67 56 63 60 56 63 61 57/”>XSS</A>
Unescape encoding.
</script><script>alert(‘XSS’);</script>
Decimal encoding.
<IMG SRC=jvascript:alert('XSS')>
DWORD encoding.
<A HREF=”http://http://13.57.30.31//”>XSS</A>
The template rules not only cover the techniques mentioned above but also a host of other techniques. I have prepared a detailed documentation for each rule, which describes its working and gives examples. This document is available at this link.
Conclusion:
A key advantage of CloudPassage log-based intrusion detection is its light impact. Because only specific, high-value events are logged into Halo, you avoid the massive gathering, storage, and analysis of voluminous events from hundreds to thousands of log files. With log-based intrusion detection and the new XSS template, you can continually monitor the security of all of your web applications and be certain that you will be notified whenever specific XSS events of critical importance occur anywhere in your server infrastructure.
