How to Detect Cross-Site Script Attacks (XSS)

Sax2 tutorials

Overview

Cross-Site Script attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site Script (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 that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

Solution1:

Diagnosis View is the most direct and effective place to detect cookies stealing XSS attacks and should be our first choice. Sax2 can generate invasion events when it detected attacks. Picture 1 is an example of detection cookies stealing XSS attacks.

(Picture 1)

Internet Explorer / Firefox support HttpOnly flag for cookies
Not sure how I missed this one previously, but Microsoft introduced functionality in IE6 SP1 designed to help mitigate the risks of XSS attacks getting access to user credentials by accessing cookies.

Essentially, in compliant browsers, cookies marked with this flag are not accessable to scripts run in the browser’s context (for example, document.cookie in javascript.)

According to this page and various others Firefox also added support for this in 2.0 – but with some limitations (there is still an access path to the cookies via another call).

Share this