Okay, I understand that part. Only piece I do not fully understand is A - Assuming one does not allow Active X to run on their machine, would not the java sandbox limit sending cookie or other data to another site ? I though java sandbox limits what mobile code can do on the computer while Active X does not have any such limitation,
B - I've seen literaure which says servers should block " < > " ' ; ( ) + - " characters. If one has not blocked all these types what are the implications (i.e., if only <> types are blocked) ? Mike --- Jeremiah Grossman <[EMAIL PROTECTED]> wrote: > So Ive noticed a couple questions relating to Cross > Site Scripting > ask for an explanation... and how to test for the > vulnerabilities. > CSS is still a commonly misunderstood attack and the > dangers > unexplained. > > I wont go into GREAT detail, but I will try and > cover some of the > basics as I know them. > > Cross-Site Scripting attacks are often bundled with > In-line > Scripting attacks... they are hard to distinguish > between so, its > generally all grouped together... I just like to > call them all CSS > vulnerabilities. > > CSS issues occurs only in web applications. (AFAIK). > A CSS vulnerability can be identified when a web > application > echoes improperly filtered HTTP "client-side" data > thus > resulting in executable client-side scripting. > (JavaScript, > ActiveX, JScript, VBScript, Flash, Java, etc.). > > In english... this is means.... if one were to put > in some weird > text string (Containing HTML/JavaScript) into some > search > field and the web page response contains the entered > string > and thus executes the supplied JavaScript.... > there's a > vulnerability. > > Search field are a common occurrence of CSS as most > developers dont know to properly filter the output. > > something like: > www.foo.com/search.cgi?string=*SCRIPT>CSS ME > FUNCTION*/SCRIPT> > > or even 404 error pages: > "The request URL: www.foo.com/*SCRIPT>CSS ME > FUNCTION*/SCRIPT> > could not be found." > > > There are generally 2 ways CSS are taken advantage > of. > > 1) target user needing to click on a special link to > execute CSS. > > Example: > <A HREF="www.foo.com/*SCRIPT>CSS ME > FUNCTION*/SCRIPT>"> > CLICK FOR PIZZA > </A> > > > 2) target user simply only needs to view a page. > > common in WebMail, Message Boards and On-line > Auctions. > Someone send you an email...you read a post... or > whatever... > No clicky, clicky needed. > > Yes, the second is far far the worst. > > > So... why is CSS such a big deal? What are the bad > things that > can be done? Well... of course cookie stealing can > be performed > which leads to session stealing and such. But... > this is just > one potential. The real danger of CSS attacks as I > see > them is that the "Code" executes in the same domain > as the > target site. Such as "foo.com" or "whatever.com" > > Having all the same abilities and access as the > target domain. > > For all intents and purposes the attack becomes > whoever.com > for that moment in time. Like your favorite web mail > provider. This is very important to understand. > > Further, these attacks are very hard to detect once > they run. > They can be extremely fast and stealthy and most > often > leave no log or any trace. > > For instance.... when you check you HTML mail on... > "www.cssme.com" and someone has sent you a crafted > HTML email message... the code in that email message > is executed as "www.cssme.com" so... it can steal > and > set cookies sure... also can exploit holes in your > browser > which can lead to system compromise.... send you > to the latest spammer haven... force you to bid on > the latest > rubber toys....or maybe even just track you for fun > sending > all your data to some off-domain host. Neat eh. > > > How to test.... its easy really... yet can get > tricky... thats why > so many issues are popping up. Pick you favorite CGI > parameter where you see the data getting echoed to > the > screen. If you can get HTML and/or JavaScript to > execute > on the response, chances are theres an issue. > > Many times data output is not properly filtered... > so vulns > are easy to find... the real challenge is to find a > way to bypass > the implemented filters when output is actively > trying > to be stripped. AKA: "Filter-Bypass Manipulation" > > > OK, nuff. Done with the ramble. > > Hopefully the above made some kind of sense. > > Jeremiah Grossman > WhiteHat Security, Inc. > > > > > Adik wrote: > > > Hi! > > There are a lot of CSS vuln discovered everyday. > As i have understood > > Cross site scripting is all about stealing a > cookie, right? Cookies do not > > contain logins and passwords in them. So what is > so important about them? I > > know that you can steal someone's session id and > enter his mailbox but still > > you are limited. I am not quite familiar with it > so my question is what is the > > worst thing attacker can do (besides stealing > cookie), with a website which is > > vulnerable to cross site scripting? Please > enlighten me! Thanks > __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
