[prev in list] [next in list] [prev in thread] [next in thread] 

List:       websecurity
Subject:    RE: [WEB SECURITY] RE: Trustwave's SpiderLabs Security Advisory
From:       David Byrne <DByrne () trustwave ! com>
Date:       2010-02-17 1:41:52
Message-ID: E64731F3ABEB554E8591AFD1DC20DEE1128FF062DE () SKYVS1 ! trustwave ! com
[Download RAW message or body]

Chris,

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.


Thanks,
David Byrne
Senior Security Consultant
Trustwave – SpiderLabs, Application Security

Email: dbyrne@trustwave.com
Phone (office & cell): 720-279-4123



-----Original Message-----
From: Chris Weber [mailto:chris@casabasec.com] 
Sent: Saturday, February 13, 2010 12:31 AM
To: David Byrne; websecurity@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

Best regards,
Chris Weber

P.S. I see the vulnerable code in reflector but I can't repro using your example.


[prev in list] [next in list] [prev in thread] [next in thread]