[WEB SECURITY] RE: Trustwave's SpiderLabs Security Advisory TWSL2010-001
DByrne at trustwave.com
Tue Feb 16 20:41:52 EST 2010
Trustwave's position is that it isn't possible to "avoid using the dangerous controls". Consider how common the effected HTML tags (A, HEAD, TABLE, FORM, etc) are just for the HtmlContainerControl class. As far as I know, the .Net Control classes do not have a view state safety contract. Even if someone did enumerate which ones use view state "safely", this could easily change in a future release from Microsoft. Overriding the methods that use view stat in an unsafe manner pose similar challenges.
Regarding the example attack, I double checked that it still works on my VM. I'm guessing that it's related to .Net version or something like that. I'll contact you off-list about it.
Senior Security Consultant
Trustwave – SpiderLabs, Application Security
Email: dbyrne at trustwave.com
Phone (office & cell): 720-279-4123
From: Chris Weber [mailto:chris at casabasec.com]
Sent: Saturday, February 13, 2010 12:31 AM
To: David Byrne; websecurity at webappsec.org
Subject: RE: [WEB SECURITY] RE: Trustwave's SpiderLabs Security Advisory TWSL2010-001
This seems a much better description of the problem than the original advisory. Though I suspected something like this I wasn't clear before that the control was inherently rendering VIEWSTATE data as 'innerHtml'. Good finding.
However, the real issue seems to be with the 'controls' being vulnerable, not the viewstate. After all, VIEWSTATE is still just a delivery mechanism no different than other request or POST data. The controls are what are acting dangerously here.
"There are other .Net controls that take properties from the view state that may also be vulnerable.
Enumerating them is not very helpful because the solution will always be the same:
secure the view state."
Or stated another way - don't unsecure it. It seems secured by default after all (contrary to MSDN documentation http://msdn.microsoft.com/en-us/library/system.web.ui.page.enableviewstatemac.aspx ). However I disagree with your take - there does seem value in enumerating the vulnerable controls. In the cases where developers need to disable VIEWSTATE's builtin security (which Arian sees as common), it gives them some options:
- avoid using the dangerous controls
- implement overrides for the affected subclasses or methods
P.S. I see the vulnerable code in reflector but I can't repro using your example.
More information about the websecurity