 |
|
How to Detect Cookies
Stealing XSS Attacks with Sax2
|
| |
Overview
Cross-Site Scripting attacks are a type of injection
problem, in which malicious scripts are injected into the
otherwise benign and trusted web sites. Cross-site scripting
(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)
Protecting cookies
from XSS attacks
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).
|