ASP.NET View State - Security Issues


Published on

ViewState is not Encrypted, ViewState is not Signed & ViewState xss.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ASP.NET View State - Security Issues

  1. 1. • Stateless- means that there is no persistent connection between server and client. • Client says “Give me this site" and the Server responds with the site.. After that the web server releases or closes all the resources which were involved with the request. • There will always be a 1:1 connection. • Means remembering what they did last time by implement various state management techniques, such as ViewState, Cookies etc..
  2. 2. • When a user log into a site, the website needs to maintain that role until the user signs out. • Stateless sites need do not maintain the state or data, leaving the user to provide their credentials for every request. • State management will provide richness on you website . ASP.Net providing various techniques already mentioned to manage state information. • Client – Side: View State, Cookies, Query String, Hidden Fields and Control State. • Server – Side: server's memory or a database
  3. 3. • Approach to saving data for the user. • Allows ASP.NET to repopulate form fields on each postbacks to the server. • The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE.
  4. 4. • ViewState misconceptions: ViewState is encrypted or somehow unreadable by the user. • May look like it is unreadable to some users but to others the ViewState can reveal juicy information regarding a user actions within the site. • It is only base64-encoded, not encrypted in any way.
  5. 5. • ViewState decoded and data within is now readable.
  6. 6. • If encryption is turned on, which is not the default, ASP.NET will use the web site machine key as the key used to encrypt and sign ViewState and cookies. • As you can set the machine keys (for validation and decryption) to a known value in web.config you could then use this to decrypt manually if necessary. • In this case an attacker might modify the content of the ViewState and subvert the logic of the application, or carry out other attacks by changing the ViewState. • Examples of these attacks could be XSS 
  7. 7. • Malicious JavaScript (XSS) needs to be encoded using HTML Entities • Use:
  8. 8. • OWASP Zap or Fiddler can be used to capture the request and tamper with the ViewState. • XSS is inserted and when released if the site is vulnerable it the malicious JavaScript will execute.
  9. 9. • Don’t store critical information in ViewState. • Encrypt – so no data will be readable. • Sign the ViewState - enable the built in functions like ViewStateMac, which will help prevent an attacker from tampering with the ViewState.