XSS Incident Handling

Published: 2007-09-25
Last Updated: 2007-09-25 22:15:57 UTC
by Jason Lam (Version: 1)
0 comment(s)

There are tons of cross site scripting vulnerabilities around the Internet. Any online sites are potential victims of cross site scripting attacks. More accurately, the actual victims are the users of the victim site. If you have not handled a XSS attack yet, you might want to start planning for one. It could hit any online sites and yours might be next.

Identification - Symptoms

There are some easy giveaways when it comes to XSS attacks, you might get users complaining about your site leaking their information or they discover funny activities after visiting your site. Yet, there are no clear indication that your site has been compromised. The goal of XSS is to trigger the browser to render some abitary content as if it comes from a legit site. Scripting can be used for the attack payload so that scripting commands get executed in the context of the victim site. It is extremely hard to determine the potential outcome, that limit is up to the attacker.

Another possibility is for the victim's site to show HTTP and application logs of funny looking cross site scripting strings. Reflective XSS is a lot easier to detect than the Persistent XSS, since reflective XSS would mean the victim sending in XSS string everytime an attack happen. Keep in mind that not all XSS attack would show up in the logs, some XSS attacks do not involve the attack strings to be sent to the victim site at all.

Containment


Once the XSS vulnerable field is identified by looking at the logs and through other investigative means, the process of stopping further attack would be pretty simple. A emergency code fix would be reasonable, just throw in proper input and output validation and we are done for containment. For some environment that has web app firewall capability, it might be as simple as filtering out bad input with web app firewall.

Eradication

Eradication is not easy. We have seen sites getting nailed time and time again. Close off one XSS hole and the next hole get nailed. My best advise here, if you get XSS attacked, it might be time to get some help with identifying all the web app vulnerabilities on your site. If someone has that much interest to attack you, it might not be too long before the person come back thru another hole. (eg. XSS, SQL injection) In the end, it might be time to ensure security is incorporated in your development lifecycle.

Overall, XSS can be hard to detect. Once detected, fixing the particular vulnerability is not too difficult. Fixing the whole development lifecycle is required for a fundamental fix of the problem. This is often very costly and slow.

To learn more about XSS attacks, SANS offers defensive web app course SEC519 and also the testing course SEC538.

Keywords:
0 comment(s)

Comments


Diary Archives