XSS Incident Handling
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.
Firefox as the weapon of choice?
The security testers alike are always seeking new tools to make their testing more effective. I am really not thrilled about some testers wannabe thinking that tools are the only thing they need to be good security testers. Skills, techniques and understanding of the overall picture are all very important to security testing especially while testing the non-standard components (eg. application security assessment). That's the exact reason I discuss not only tools but also the techniques and reasons some security checks were done in my web application security testing course.
Most application security testers are already using some Firefox plug-ins to assist in their testing. These plug-ins are usually very helpful in getting some quick and easy test tools directly from within the browser. The folks from security-database.com has compiled a catalog of the security plug-ins in Firefox, called FireCAT. I would suggest taking a look at their catalog and load up your Firefox browser with some of the security tools. Although most of these plug-ins would not be considered best of breed tools in their respective area, the ability to use them from within the browser usually makes them very accessible and easy to use. You might also want to know that these tools would not only benefit the application testers but also the infrastructure testers and most other security professionals as well.
Comments