More than 10 years ago the industry became aware of smashing-the-stack buffer overflows. Many exploits later, these issues became harder to come by in popular software. The industry then moved onto heap overflows in pursuit of greener pastures. Once the grass was eaten up, the next evolutionary step occurred, integer overflows came to be identified more often. My prediction for the next 3-5 years is DOM-Based Cross-Site Scripting (XSS), credited to Amit Klein, vulnerabilities will follow a similar path.
Today the vast majority of XSS vulnerabilities fall into the persistent (HTML Injection) or non-persistent (link click) variety. I expect most of these issues to be cleaned up on major websites. If fact I see this trend already as people become aware of the dangers. From there it’s reasonable to assume DOM-based XSS will grow in interest, where currently it lays in wait. For how long is the question.
As far as the next type of XSS, its has yet to be identified. ;)
Could you provide an example of DOM Based XSS ?
DOM based XSS:
User enters a value, such as username into a field. Say this function exists:
username = document.getElementByID("username");
// munge username somehow
errorMsg = document.getElementByID("errorMsg");
errorMsg.innerHTML = "Username " + username + "invalid";
Then if you can insert arbitrary text into username, you can take over the DOM and play with it, starting with the script src tag and moving on from there.
Amit's paper has some concrete examples. I've got a demo which takes over the page and defaces it with the l33t 0wned kitten.
Andrew's example seems not dangerous, because it needs users interaction (fill in something to username input box).
I have real-world story. One time I tested self-service terminals for unspecified bank, the access for web browser was limited only for bank's domain. There was apply form with very similar DOM based XSS vulnerability as in Andrew's example.
The terminal was Windows NT machine. So I typed on self-service terminal's keyboard the HTML, executed Outlook, from there I was able to execute anything and take full control of that machine:)
Jeremiah, your comment regarding DOM manipulation not traversing the firewall is by know means new but certainly a valid point. I think RSnake's Firefox plugin detection demonstrates this nicely.
(the "foo" is important)
Post a Comment