IIS Show #4 with Brett Hill

Play IIS Show #4 with Brett Hill

The Discussion

  • User profile image

    Something just seems wrong when it is possible to specify web paths that will fool the parser.  This seems inherently insecure.  I don't disagree with your comments to keep paths short and clean but to be worried that specifying a directory with .com is going to fool the parser just makes me wonder about either the URL/HTTP specifications or the implementation of IIS.

    Microsoft has spent lots of effort allowing users to have long file names and directory names.  I rememeber the old 8.3 days and I for one love good descriptive names - though I hate blanks in names like "Program Files" and needless dots (.) are kinda silly too - yet .Net actually encouraged this practice.

    Your advise is good but the Microsoft examples out there contradict them.


  • User profile image
    I completely agree - though my biggest problem is this was a total waste of time.  The message seemed slightly rehearsed and for the most part completely "out-of-date." 

    I, personally, would like more exciting, powerful topics coming out of Microsoft considering IIS was pretty much the first hackable product for Microsoft.  Were you around, or seriously involved with IIS when Code Red was in it's prime?
  • User profile image
    Yup, i was around. Of course the basics would have prevented code red such as applying existing patches or disabling extensions you aren't using. I didn't cover that info in the podcast since this was not about administration as much as much as what to tell developers. I can assure it was not rehearsed. 

    So what I would like to know is what you would like to have heard in this? In other words, what would you say to developers are the top things the should know to write secure code for web applications?

  • User profile image

    I appreciate your concern here, however, the thing to keep in mind is that the parser is not fooled, it is simply parsing according to its rules. Keep in mind that you cannot send this kind of URL from IE as it wil not allow it. You have to use another utility of some kind.
    See http://www.windowsitpro.com/Article/ArticleID/23278/23278.html?Ad=1

    And Writing Secure Code by Michael Howard
    "Just say no to parent paths. If you remove the requirement for parent paths in your application, anyone attempting to access a resource by using parent paths is, by definition, an attacker!"


Add Your 2 Cents