Developers should never store
sensitive information in the viewstate.
A common misconception about viewstate is that it is user-specific and prevents
cross-site request forgery (CRSF) attacks (www.isecpartners.com/files/XSRF_Paper_
0.pdf). While viewstate prevents CSRF in some cases, the security benefit is generally
provided by accident. When attempting to exploit a CSRF issue, the attacker will try to
remove the viewstate from the page, since often viewstate is not required for a page to
function properly. If the page complains when the viewstate is removed, the attacker will
try logging into the application, visiting the page, and then copying the viewstate from
the page into the CSRF exploit. Depending on the application, ASP.Net may accept the
viewstate on behalf of the victim. Viewstate may be omitted or substituted because not
all applications depend on the viewstate being present or initialized.
To mitigate the CSRF weaknesses, ASP.Net 1.1 introduced the Page.ViewStateUser-
Key property. The property can be used to add entropy to the viewstate. When ASP.Net
receives a postback it will use the ViewStateUserKey along with the validation key to
calculate the page viewstate??™s HMAC.
Pages:
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258