An XSS attack occurs when a malicious script from an untrusted source is executed while rendering a page, generally in the form of a browser side script, to a different end user.
Executing scripts at locations where user inputs are required or modifying the scripts on a webpage to gain access to a web app or web server is one of the oldest flaws that we still witness. Although configuring web applications to detect XSS threats requires an organization to invest enough resources to achieve considerable security, that by itself is not enough.
Known Attack Vectors
When launching an XSS attack or testing a web site’s vulnerability to it, the attacker may try using a script tag, such as
<script>alert("OK")</script>. Besides hex equivalents may also be used to bypass the perimeter data validation present on the webpage; so the
<script>tag would appear as
</script>would appear as
Sometimes, a more sophisticated attack w.r.t the use of
<marquee>tags or the use of images for XSS, and similar such attack vectors, may be used to bypass the filters on most web applications.You can read more on the methods to bypass a filtering/validation check for XSS on the XSS Filter Evasion Cheat Sheet(OWASP)
How We Help
If we look at the logs from a typical web server, with ongoing XSS attacks, we use the Search interface of the DNIF web console to find the relevant attack vectors.
Here’s an example - Let’s say we’re going to use a query that looks for a text-like script or document within the URL field of our log sample, as shown below:
_fetch * from event where $Duration=5m AND $LogType=WEBSERVER AND $LogEvent=*document* AND $LogEvent=*script* group count_unique $URL limit 100
We can see that there is a match in the URL fields. If we look closely, we’ll find the malicious code, entered as the URL.
If you come across such suspicious activity, you can create an alert and assign it to an analyst for further investigation. However, to foolproof your machine forever, you can create modules out of these attack vectors, that get triggered whenever such an attack takes place and furnish you with details that can then be investigated.
To give you an example of what this looks like, we have created a module for this issue, which automates the detection of such attacks. Take a look at the configuration details of this module.
You could create such modules yourself too.
Correlation rules can be created, similar to the detecting strategy used for snort rules, and updated as per the sophistication level of the encountered attacks. However, you can use the shared rule below to identify the attack, when the attacker tries to perform XSS using some popular attack vectors:
- Signature below can identify a typical alert script
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC cross site scripting attempt"; flow:to_server,established; content:"<SCRIPT>"; nocase; classtype:web-application-attack; sid:1497; rev:6;)
- Signature to identify a typical
- Signature that looks for the opening HTML tag (or its hex equivalent), followed by one or more characters (other than the new line), followed by the closing tag (or hex equivalent). It is virtually assured of identifying a cross-site scripting attack.
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;)
By now you’re well aware that detecting threats like the XSS attacks can easily be accomplished using DNIF. We used the search dashboard as a starting point to detect suspicious behavior. Using these DNIF searches, a security analyst can check for common data exfiltration behaviors, set up monitoring of potentially compromised machines, and take the necessary remedial action.