Wireless Security. Let's make security K.O.R.E.A

3. Regular Expressions for Cross Site Scripting (CSS)
When launching a cross-site scripting attack, or testing a Website's vulnerability to it, the attacker may first
issue a simple HTML formatting tag such as <b> for bold, <i> for italic or <u> for underline.
Alternatively, he may try a trivial script tag such as <script>alert("OK")</script>. This is
likely because most of the printed and online literature on CSS use this script as an example for determining if a site
is vulnerable to CSS. These attempts can be trivially detected. However, the advanced attacker may attempt to camouflage
the entire string by entering its Hex equivalents. So the <script> tag would appear as %3C%73%63%72%69%70%74%3E.
On the other hand, the attacker may actually use a Web Application Proxy like Achilles and reverse the browser's
automatic conversion of special characters such as < to %3C and > to %3E. So the attack URL will contain the
angled brackets instead of their hex equivalents as would otherwise normally occur.

The following regular expression checks for attacks that may contain HTML opening tags and closing tags <> with
any text inside. It will catch attempts to use <b> or <u> or <script>. The regex is case-insensitive.
We also need to check for the presence of angled brackets, as well as their hex equivalents, or (%3C|<). To detect
the hex conversion of the entire string, we must check for the presence of numbers as well as the % sign in the user
input, in other words, the use of [a-z0-9%]. This may sometimes result in false-positives, but most of the time will
detect the actual attack.
3.1 Regex for simple CSS attack
/((\%3C)|<)((\%2F)|/)*[a-z0-9\%]+((\%3E)|>)/ix

Explanation:
((\%3C)|<) - check for opening angle bracket or hex equivalent
((\%2F)|/)* - the forward slash for a closing tag or its hex equivalent
[a-z0-9\%]+ - check for alphanumeric string inside the tag, or hex representation of these
((\%3E)|>) - check for closing angle bracket or hex equivalent

Snort signature:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII Cross-site scripting attempt";
flow:to_server,established; pcre:"/((\%3C)|<)((\%2F)|/)*[a-z0-9\%]+((\%3E)|>)/i";
classtype:Web-application-attack; sid:9000; rev:5;)

Cross-site scripting can also be accomplished by using the <img src=> technique. The existing default snort
signature can be easily evaded. The one supplied in section 3.2 will be much tougher to evade.
3.2 Regex for "<img src" CSS attack
/((\%3C)|<)((\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|(\%47))[^
]+((\%3E)|>)/I

Explanation:
(\%3C)|<) opening angled bracket or hex equivalent
(\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|(\%47) the letters 'img' in varying combinations of ASCII, or upper
or lower case hex equivalents
[^
]+ any character other than a new line following the <img
(\%3E)|>) closing angled bracket or hex equivalent
3.3 Paranoid regex for CSS attacks
/((\%3C)|<)[^
]+((\%3E)|>)/I

Explanation:
This signature simply looks for the opening HTML tag, and its hex equivalent, followed by one or more characters other
than the newline, and then followed by the closing tag or its hex equivalent. This may end up giving a few false
positives depending upon how your Web application and Web server are structured, but it is guaranteed to catch anything
that even remotely resembles a cross-site scripting attack.

For an excellent reference on types of cross-site scripting attacks that will evade filters, see the Bugtraq posting
http://www.securityfocus.com/archive/1/272037. However, note that the last of the cross-site scripting signatures, which
is the paranoid signature, will detect all these attacks.

4. Conclusion
In this article, we've presented different types of regular expression signatures that can be used to detect SQL
Injection and Cross Site Scripting attacks. Some of the signatures are simple yet paranoid, in that they will raise an
alert even if there is a hint of an attack. But there is also the possibility that these paranoid signatures may result
in false positives. To take care of this, we've then modified the simple signatures with additional pattern checks
so that they are more accurate. We recommend that these signatures be taken as a starting point for tuning your IDS or
log analysis methods, in the detection of these Web application layer attacks. After a few modifications, and after
taking into account the non-malicious traffic that occurs as part of your normal Web transactions, you should be able to
accurately detect these attacks.