Re: on xss and its technical merit

[reepex <reepex () gmail com>]

i seemed to reply to nexxus as you were writing your original reply which
ive since replied to. about this email though...

On Nov 4, 2007 3:13 PM, pdp (architect) <pdp.gnucitizen () googlemail com>
wrote:

> XSS today is where buffer overflows were 10-15 year ago. Moreover, did
> you missed when I said that 99% of all sites are vulnerable to XSS.
> Given the percentage of available XSS vulnerabilities, what chance you
> think you have finding one? simple math! of course it is easy. It is
> easy for most of XSS issues. However, those that really matter are not
> easy at all. DOM based XSS is a debug hell, mainly because every time
> you want to do something you have to deal with the remote server. This
> is not very ofline.


yes buffer overflows were everywhere then and yes xss is everywhere now. but
to say that xss is the buffer overflow of 15 years ago is not a good
comparison. Even if xss evolves for 15 years, which it may, would the result
be as damaging as even simple stack based overflows have been? Could you
have such mass damage worms as overflows have caused? I know there has been
myspace worms (which you mention), but xss cannot have the same effect as
overflows to a server.

lets say 10000 servers are running a vuln ftpd and another 10000 are running
the same open source web app. Which would you rather have the explot for?
also which would be more practical to attack? assuming you have the same
system and a good exploit you could get all the 10000 ftpds, while the xss
on 10000 msg boards would require 10000 users to view the page you attacked.

xss just does not have the same potentional as overflows do unless browsers
develop some new technology or extend an old one to let client side
scripting to have much more control on the system.


> if you want to do it right, then it is harder to get a successful XSS
> attack. do you know why? cuz XSS involves a bit of strategy as well.
> because it is an indirect type of attack. A single XSS attack
> sometimes may involve several sub XSS each one of which call the next
> one in an exponential manner. By the time you reach level 5 you head
> is so screwed up that you need to start all over again because you
> code breaks on 50 places. JavaScript in particular is not an easy
> language. You may think that you know it but you don't know 90% of it.
> When it comes to scoping you get into a mess of things. Have you ever
> done XSS on GMail. Try it! See how far you will go. Unless you have
> some solid understanding on AJAX debuging and some nifty tools that
> can put back Google's mess into order, you have no chance. Today
> software hackers relay on tools such as IDA Pro or Soft Ice, which is
> discontinue but still. Check this out there are not tools like that
> for XSS and in particular AJAX, therefore I have to start from zero.
> Where is my JavaScript deobfiscator? I don't have one... I have to
> write it myself. Where is my debugger. I am stuck with Firebug for
> Firefox... Great! How about dynamic tracing, tracking, stepping and
> all other things on a complete BlackBox application that you can only
> see the incoming and outgoing requests. At least when you have a
> binary you know what it is. You can do it offline and you have all of
> the parts.
>
> XSS can be very complicated. Don't be fulled by what people post on FD.


the problem is that if you are going to xss 5 times deep why cant you just
find a client side browser bug?  you are researching how to basically steal
credentials/force requests/steal accounts when one browser or client side
bug would make all of that unnecesary. People like the ones i mention in the
other email will put this much time into xss because they are incapable
doing the client side bugs because they require much more skill that he ppl
simply do not have.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/