Many people tried to compare buffer overflows (BOF) with XSS and even the new XSS Book has the subtitle “XSS Is the New Buffer Overflow, JavaScript Malware Is the New Shell Code”. The conclusion’s most of the time, that there are many similar things but the most important difference is, that XSS vulnerabilities are much easier to exploit that BOFs. I agree, that some things are about the same if we look at this two vulnerability types but I really don’t agree with the fact, that XSS vulnerabilities are easier to exploit. In an eweek.com article, they’ve talked to Brian Chess, who’s Founder and the Chief Scientist of Fortify Software and by the way also a very cool guy 
Where it diverges, though, is that buffer overflows are somewhat hard to exploit, Chess said, requiring an attacker to be fairly knowledgable about a system’s architecture and what’s happening on that machine. “XSS vulnerabilities are much easier to exploit,” he said. “Just go to your local bookstore, buy a book on JavaScript and you can get started on XSS.”
If you say this in exactly that way, then I fully agree with this statement but only because there’s the part “get started on XSS”. Of course when you know the basics on XSS and also on JavaScript, it’s no problem to find some websites where you can display an alert box or something. So, now you may ask why I started this posting with saying that I don’t agree that XSS vulnerabilities are easier to exploit. The answer’s very simple, it’s because I think there are different kinds of really exploiting XSS vulnerabilities. Normally to find a buffer overflow possibility it’s very hard but when you found it, you can use your standard pre-prepared shell codes and own the machine. Now, XSS works from my point of view exactly the different way. To find an XSS hole, it’s most of the time very easy and also to have a alert box popping up or changing the content of a website it’s not that hard but now asking yourself when is the exploitation of a XSS vulnerability really dangerous. This is the case as soon as the attack tries to attack the logic behind your application, for example by using functionalities in the name of a targeted user. To find out how an application works, so that you as an attacker can reach your goal by “exploiting the logic” or better say re-using the logic of the application through you XSS exploit, this is from my point of view some times very hard and this is why I would say, that exploiting an XSS vulnerability could be as complicated and difficult as exploiting a BOF.
To have a small conclusion:
BOFs are most of the time very hard to find but when you’ve identified where the vulnerability exactly’s located and what the vulnerability exactly is the final exploitation’s not that hard because you can use per-prepared shell codes which should be executed on the target machine.
XSSs can be found normally very easy but because (mostly) every application’s different from all the others, you have to write a special exploit and payload for every vulnerability (of course this depends on what’s your goal).
Though in fairness with the bar being raised on automated defenses for certain classes of buffer overflows (heap checking, non-executable stacks, etc) the buffer overflows you find take a lot more technical skill to exploit. Sure you might be able to drop in a standard payload, but getting it in the right place, etc. can take a ton of work and deep app/os knowledge.
When you find an application that isn’t doing proper input validation its a lot easier to figure out exactly how to inject XSS into it. Typically the webapp spits your input right back at you so can you iterate till your hearts content with exactly what the app is doing, how it is filtering, etc.
potentially, your standard template for XSS could simply be to steal the user’s cookie. (something like
congrats… your summary is right on
Andy:
Sorry, I’m a bit unsure if I am interpreting your last comment correctly, it seems that you’re saying that exploiting input validation is easier because it spits the results back to you, and you can therefore see what is being filtered, and you don’t have to do blind attacks, right?
Which is true, there are no blind XSS attacks, because you need to get input back, but as I see it, its no harder to find a case where a buffer length is not checked, as opposed to some characters being unfiltered, I’d say its even easier to find buffer overflows actually, and there is never any filtering which needs to be done, either the developer does the length check, or they get owned.
I could go on and on, but the fact that you need to know the OS to execute buffer overflow attacks is no more special than the need to understand browsers, and their quirks, and their versions of the DOM, etc to execute XSS attacks.
And just because its become common practice to apply protection to OS’s, but not to websites, says nothing about the vulnerability class, e.g. have a look at SessionSafe http://shampoo.antville.org/stories/1586524/ and the proposed attacks, I doubt you’ll be able to tell me that those attacks are simple – they are more high level definitely, but they are just as creative and challenging as any attacks at lower levels.
Just because you know a little bit about XSS and the various protections, doesn’t mean you know much at all. Sure, anyone can steal a cookie form a site which doesn’t filter XSS attacks, but anyone can execute a buffer overflow against an app which does no filtering, and an OS which has no protections just as easily.
All I really want to say is; just because you know something about a given attack, don’t assume you know everything.
@ arun
Of course that could be the case and that’s exactly why my last words in this posting are “of course this depends on what’s your goal”
I’ll agree that in the “simple” case these two attacks are roughly equivalent. My point was that if someone has good input filtering in place you’re unlikely to find an XSS vuln and be able to attacks it. Even in some cases where decent buffer checking is being done, or maybe isn’t being done, sometimes you have to hop through a lot more hurdles before you can exploit a buffer overflow.
That is, the number of layered defenses for buffer overflows is greater such that even if the app is faulty you might have a hard time getting a working exploit.
In the web application world there aren’t a lot of layered defenses to work through.
Disenchant: Nice summary!
Kuza555: “just because you know something about a given attack, don’t assume you know everything” I think this sentence drive us a lot in the field of web apps security otherwise, we cannot find anything… Just wanted to cite you again because we need to repeat that