Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [Full-disclosure] Self-contained XSS Attacks (the new generation of XSS) |
|---|---|
| Date: | Fri, 22 Sep 2006 10:03:11 -0400 |
Hello pdp,
http://www.gnucitizen.org/blog/self-contained-xss-attacks XSS attacks can be persistent and non-persistent. Persistent XSS is more dangerous since it allow attackers to control exploited clients for longer. On the other hand non-persistent XSS is considered less dangerous although it has been widely used in many phishing attempts. In this article I will expose some of my findings around a new attack vector which is of type non-persistent XSS but a lot more dangerous than the persistent one. Some of you might be familiar with this attack vector; this subject has been covered very vaguely in the past and none of its full potentials has been explored. The impact of this attack is much bigger today and could affect many web applications.
This is a very interesting vector. However, I would argue that it is
not a new class of XSS. Generally, the classes have been defined based
on where the injected data flows from, not how it is injected in the
page.
For instance, stored or persistent XSS comes from an attacker via one
communication, gets saved on the server, and is later reproduced to
another user. Reflected is generally embedded in a link, sent to a
victim, which a victim then sends to the webserver and is reflected back
to achieve injection. DOM-based is similar, but does not need to flow
to the webserver before coming back to get injected. I personally label
these three classes Type 2, Type 1 and Type 0 respectively, in order to
reduce confusion about terminology [1].
All three of these scenarios could be used with your injection vector.
A server side script could store the URL supplied by an attacker, and
later present it to a victim, thus making it persistent. Similarly, a
document.write() call could be exploited to inject a data: link, even if
the typical dangerous characters (', ", <, >, etc) were handled.
Don't get me wrong... I really like the vector, and what you've brought
to the list. I just don't think it should be considered another class.
cheers,
tim
1. http://en.wikipedia.org/wiki/XSS
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [Full-disclosure] Self-contained XSS Attacks (the new generation of XSS), pdp (architect) |
|---|---|
| Next by Date: | Re: [Full-disclosure] Self-contained XSS Attacks (the new generation of XSS), pdp (architect) |
| Previous by Thread: | [Full-disclosure] Self-contained XSS Attacks (the new generation of XSS), pdp (architect) |
| Next by Thread: | Re: [Full-disclosure] Self-contained XSS Attacks (the new generation of XSS), pdp (architect) |
| Indexes: | [Date] [Thread] [Top] [All Lists] |