Tuesday, September 11, 2012

Stored XSS Via Viewstate

While researching I have found that Stored XSS can be found Via Viewstate Parameter even when Viewstates Mac is Encrypted. The actual cause of this vulnerability existence is that the viewstate parameters value is not properly getting decoded on the server-side therefore any XSS payload in this paramter will get excuted and if there is any filter then it can be bypassed by converting the XSS payload in base 64 payload.

Steps to execute this attack are as following:

1. First input any random data in login page and submit it on any aspx application.

2. intercept the using burp proxy if there is any client side validation submitted request then modify the actual  viewstate parameter as shown below.


to __VIEWSTATE=<scripts>alert(document.cookie)</script> the intercepted request

Also the XSS Payload <scripts>alert(document.cookie)</script> can be converted to base 64 Jmx0O3NjcmlwdHMmZ3Q7YWxlcnQoZG9jdW1lbnQuY29va2llKSZsdDsvc2NyaXB0Jmd0Ow==

3. now forward the request using burp web proxy

4. the javascript payload will execute on the client side as there the decoding of the base 64 value in viewstate parameter is not properly decoded on the server side therefore the malicious XSS payload will not be sanitized on the server side and if there is no HTTP only cookie attribute is implemented so the attacker can get all the authentication session cookies of the victim.


5. using the web proxy burp we were able to inject the XSS payload and it also executed successfully after modifying and forwarding the intercept request but the interesting thing is that this payload was successfully executed using the vulnerable Viewstate parameter then this payload actually got stored in the server side and the XSS vulnerable page redirected to an error webpage with a different Url, then we copied and opened this Error page Url in another browser. As the XSS payload is stored on the server side so this XSS payload got executed again and again. So, the same attack can now be done without any web proxy like burp as the malicious XSS payload is stored on the server side and that can be reused using the error page Url which was generated after the execution of malicious XSS payload using the web proxy burp.

Malicious Url with Stored XSS Payload:



Client-side code (like JavaScript) can be injected into the web application which is then returned to the user's browser. This can lead to a compromise of the client's system or serve as a pivoting point for other attacks.)


User inputs must be validated and filtered before being returned as part of the HTML code of a page. Don't rely on this security mechanism to protect against Cross-Site Scripting and SQL injection attacks. Make sure that proper input validation is built into web applications.


  1. Hi Abhay thanks for the comment i will try to post regular from now...I have removed ur comment bcz u have posted a url to do a course i don't allow advertisements on this blog.

  2. Bro Plz More NEW Post
    brother iam Intrested Xss Val FInder love u
    Regard Zeee

    1. Hi Zeeshan Haider,

      Soon I will post on some new topics, thats great to know that you are interested in learning XSS.

  3. bro Plz Teach me XSS
    iam Thank Full To U
    And Plz Post New Topic About Xss
    And Also Post Val Founder
    Iam Very Intersted Xss
    And Love Ur work :)
    Very Nice blog Brother :)


You Have Successfully Posted the Message.