Cenzic 232 Patent
Paid Advertising
web application security lab

ASP.NET 1.1 vs 2.0

My friend Michael Eddington did a very good write-up on the differences between ASP.NET 1.1 vs 2.0 in terms of XSS protection. Surprisingly, it’s actually gotten quite a bit worse between the two versions. So much so that all the event handlers are now wide open, directives are wide open, and style sheets are wide open. I haven’t tested this myself yet, but if Michael’s diagnosis is correct that’s spelling bad news for anyone who adopted the 2.0 filters to prevent against XSS.

The funny part is that I actually thought the old ASP.NET filters were pretty good, not perfect, maybe, but good. Not only did they prevent against most of the major classes of XSS vulns, but because of the heavy reliance on viewstates, it also made tampering credentials a far more difficult task, and in some cases entirely impossible (via CSRF). My question is why would you intentionally make your filters worse? For the time being I’d stick to 1.1 if you use ASP.NET and are really concerned about XSS.

9 Responses to “ASP.NET 1.1 vs 2.0”

  1. John Ther Says:

    If one relies on ASP.NET protection against XSS he or she already lost the game.

    Potentially they’ve changed their filters because if you filter a lot then people will disable request validation totally and this is even worse. there are lots of open source asp.net application already disables it for false positives etc.

  2. Awesome AnDrEw Says:

    Michael’s post was very forward, and straight to the point about the issue. There isn’t too much I can actually say about this other than “Why?”

  3. Felstatsu Says:

    Well, my guess as to why might be that MS is stepping things back after taking some flak for the Vista UAC alerts that gets in the way so much that people find ways to it them off.

    For the common user security is important, but usually not as important as just being able to get things done without jumping through hoops. If the old filters made it difficult to make sites with AJAX and whatever other flashy “impressive” looking things the user wanted or had too many false positives from anything, then the common user finds that ASP.NET fails them because they can’t do what they want to with it even though it’s protecting them/their visitors from exploits. It’s not like your average user will know what the filtered strings can do if left alone, they just know their favorite web effect uses “xyz” and “xyz” is blocked by the filter, and then they likely find it easier to disable the filter than learn a new way to program in their effect.

    Seems like MS to take the easy way out to keep market share. At least that’s what came to my mind when I asked the same question.

  4. n0mad Says:

    Any proof of concepts around?

  5. Felstatsu Says:

    I don’t think that ASP.NET lowering the strength of its filters really involves a PoC anywhere. ASP.NET simply now is open to exploits it protected against before.

  6. kuza55 Says:

    I’m not saying this is right or wrong, but they probably decided they didn’t want t maintain a huge filter that is applied to every request.

    Does anyone know if the generic filter bypasses were backported to 1.1? Because if they weren’t it might not be the best idea to recommend using them.

    Also, if the filters are as simple as Michael describes, then most of them are trivially bypassed; “expression(” can be split up with comments, and if you can do that you have no need for event handlers. And while the “script:” filter may be useful on IE, on Firefox (and Opera?) you can always use the data: URI scheme instead (and if there is a html entity that does not include &# that can be used to replace any character in ’script:’, then that can be bypassed as well; I don’t know if there is, but there might be a colon one in some browser…).

    So rather than saying people serious about XSS should use ASP.NET 1.1, I think people serious about XSS should audit their code to make sure they’re not relying on this.

  7. Erwin Says:

    So it will be impossible to have a secure web application when a developer cannot rely on the framework to handle security issues like XSS and CSRF.

    So another reason to have the OWASP ESAPI framework in ASP.NET asap.

  8. John Ther Says:

    > So it will be impossible to have a secure web application when a
    > developer cannot rely on the framework to handle security issues
    > like XSS and CSRF.

    CSRF is already solved in ASP.NET check out userkey and viewstate.

    XSS is impossible to solve blindly, and in fact also it’s solved in control level in ASP.NET by binding values with controls where control properties encode it.

    So both of them already solved, but if you are not using your framework properly, that’s your problem not your framework’s. Framework can’t you force you to do stuff in a certain way that’d kill flexibility in programming but it can help and educate you. That’s what they do, but programmers are never change they always want to do stupid things, and mostly they uneducated about security.

  9. Mr.E. Says:

    John Ther: CSRF is already solved in ASP.NET check out userkey and viewstate.

    That’s interesting. Do you have a url or can you provide a brief explanation?