Re: [Full-disclosure] on xss and its technical merit

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@xxxxxxxxxxxxxx>

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.
Hosted and sponsored by Secunia -

Relevant Pages

  • [Full-disclosure] Minify and related plugins DOM-Based XSS Vulnerability
    ... Minify and related plugins DOM-Based XSS Vulnerability ... Minify integrated into other Projects/Plugins ... attack wherein the attack ... by the original client side script, so that the client side code runs in an ...
  • XSS vulnerabilities in
    ... XSS vulnerabilities in ... Two XSS vulnerabilities were identified in the website, ... Although Google uses common XSS countermeasures, a successful attack ... The server response lacks charset encoding enforcement, ...
  • Re: [Full-disclosure] Attacking the local LAN via XSS
    ... this is a url that carries an XSS attack bla ... border router vulnerable to XSS ... For that purpose the malicious JavaScript fires several ...
  • Re: [Full-disclosure] on xss and its technical merit
    ... execution flow and as such make the attack stealthier. ... limited chars in a xss isnt really comparable to having limited characters ... Also "controlling execution flow" of a browser which you only control ... traditional attack techniques. ...
  • Re: [Full-disclosure] XSS vulnerabilities in
    ... > XSS will always remain part of the Full-Disclosure list if little ... >> legal to just audit a website without ... >> services or to mount a phishing attack. ... >> The server response lacks charset encoding enforcement, ...