Operation n

I neglected to mention in the original post what the implications of two-step XSS there are.

The behaviour of some website to put in viewstate and cookies may well be used to fight CSRF. If that’s the case, it may be possible to inject malformed strings into the viewstate by forcing errors. So you may well see more of this, if people are fighting the difficult problem of CSRF. The viewstate is usually handled by the framework, so it looks like you can’t rely on the framework on everything! All I can really suggest is make sure if anything is echoed back to the user, it must be checked and filtered.

The only way to utilise the two-step attack is probably through phishing emails and getting the user to click on both links. This can be easily be done by simply saying try the first link first and if that fails, try the second.

Everyone in security knows about XSS where malformed strings in the form of code can be injected into parameters of pages. But something that has been seen lately by yours truly is a two-step XSS attack. The basic idea is to inject malformed strings and script tgs into one page and then view another page, which will spit back the injected parameters.

A classic example is a registration application. I would enter my details including a malformed string. When the application is sent, it is likely to be stored on the server. When another page (e.g. a contacts page) accesses this information, it will display the malformed string. There you have an indirect two-step XSS.

Another scenario that I have seen is where a malformed string is injected into a query parameter and an error message is returned. However, when connecting to another page on the site, the injected parameter is realised and XSS occurs. Something is definitely happening on the server. Simple navigation around the website does not normally cause this issue.

Why is this happening?

Well whilst looking at another website that the pieces of the puzzle fit into the place. When attempting to inject a parameter, an error page was returned. On deeper insection, it was noted that when a page is called, a number of page requests were made. Using one of those page requests, code was injected. However, the parameter was reset to the original parameters. These parameters were stored in a hidden viewstate field.

What does this mean?

If a page is called, it may well reuse whatever was set by a hidden viewstate or even a cookie. If that is the case, if you can inject a script tag and cause an error, it could be stored in the viewstate field and reused. This is a bit like when a program crashes, whatever was last on the program stack is remembered and used in debugging for example. The debugger may crash or even cause a buffer overflow when the program stack is assessed if it does not do proper sanitisation.