You of course design the attack script in such a way that it doesn't hurt you. Some examples of what you can do with cross-site scripting:
Stealing user credentials, for identity theft, gaining administrator access etc.
Modifying transactions performed on the site
Inserting false information
And the list goes on. Cross-site scripting attacks very often take advantage of browser security holes, but even with a 100% secure browser but less-than-perfect script, some types of attacks are still possible.
Cross-site scripting and other attacks based on unescaped input are actually pretty much like executing arbitary code using a buffer overflow. You can hijack sessions (get elevated privileges) and cause limited denial of service, just to mention a few possibilities.
I think it would be possible to design a self-propagating exploit, that would "infect" user sessions and then use those sessions to "infect" more vulnerable pages, which leads to more infected sessions, and so on. If the attack script was be compatible with the browser the site administrator is running, you would gain root access at some point.
Slashdot Mirror
I mean, I can't even afford to build a storage server, but some need a storage server just to store their budget!
Stealing user credentials, for identity theft, gaining administrator access etc.
Modifying transactions performed on the site
Inserting false information
And the list goes on. Cross-site scripting attacks very often take advantage of browser security holes, but even with a 100% secure browser but less-than-perfect script, some types of attacks are still possible.
In a week we'll see their new paper, The Anatomy of Distributed Denial of Service.
I think it would be possible to design a self-propagating exploit, that would "infect" user sessions and then use those sessions to "infect" more vulnerable pages, which leads to more infected sessions, and so on. If the attack script was be compatible with the browser the site administrator is running, you would gain root access at some point.