RELATED: "The IIS7 Difference" and "IIS and WAS Hosting Architecture."
I recently ran into a painful experience with IIS 7.5 that wasted a lot of my time. More importantly, this experience highlighted a recurring problem that I keep bumping into with Microsoft's products—which is especially problematic given what this problem can mean from a security standpoint. The problem is that Microsoft needs to communicate new feature changes better so that their users don't end up banging their heads into a wall.
Bang Forehead Here
A few years ago, I built a WinForms application for a client that parses gobs and gobs of government data. The application packed a subset of that data into a .zip file and then securely uploaded the file to a website running an ASP.NET MVC 1.0 application so that it could later be imported into Microsoft SQL Server when needed. This application has run without problems or hiccups for years. But lately, it started bumping into problems when the amount of data being uploaded barely exceeded 28MB.
I started running some simple tests to find the cause of the problem. Sure enough, files just over 28MB in size would crash and burn, but smaller files had no problems. What confused me in this case is that I had clearly configured the MVC 1.0 site to enable uploads of up to 200MB in size through the Web.config's httpRuntime element by setting the appropriate value on the maxRequestLength value.
After checking into several possibilities for what was causing my problems, I wondered if I might have run into some sort of weird bug in which MVC 1.0 sites couldn't enable uploads over a certain size via SSL. Even in thinking that possibility out loud, I realized I was grasping at straws, but by this point I had been over and over the documentation on the httpRuntime element and checked my application's maxRequestLength value so many times that my eyes felt like they were going to bleed -- so this idea seemed as likely as any other at this point.
Happily, my harebrained idea about SSL panned out in roundabout fashion. When I started testing uploads via HTTP (instead of HTTPS), I noticed that I could push up files that were just under 29MB in size -- which was enough additional information to help me finally Google my way to a key clue when I threw in maxRequestLength and 28 MB as part of my search.
IIS 7.5's Max Content Length Setting
In the end, I was getting burned by a new feature of IIS 7.5 -- a (very poorly documented) default constraint on the maximum number of bytes that can be uploaded to a server before IIS 7.5 freaks out and assumes that it's being attacked. And although this feature is truly a fantastic security option to have, the fact that it was stealthed into play on IIS 7.5 was what burned me here.
Of course, I'm sure that a number of IIS gurus or even members of the IIS team might not take very kindly to me talking about this feature being stealthily put into play in IIS 7.5. The reality is that unless you've poured over all the docs for IIS 7.5, you really aren't likely to know that this new restriction is in play. Instead, you'll end up banging your head into this feature if you need to allow larger uploads to one of your sites.
Microsoft Needs to Communicate Better
What really bugs me most about this new feature is that it's not something that developers are likely going to know about or bump into -- until they come up against it the hard way. And there are two primary reasons why I say that. First, the documentation for "What's New in IIS 7.5" patently sucks; it says that "there are no significant changes in how you use IIS," which I'd argue isn't true given how Request Filtering works. Second, there's absolutely no mention of Request Filtering throwing additional limitations into the mix from within the latest docs for the httpRuntime Element.
Of course, I can hear Microsoft's response to that second criticism even as I type this out. From the company's perspective, the httpRuntime documentation belongs to the ASP.NET team, which effectively means that this documentation has to be independent of whatever changes and issues are thrown into the mix by outside, or external, teams such as the IIS team. Or in other words, the fact that there isn't some sort of warning in these docs about how maxRequestLength can be invalidated by IIS 7.5's Max Allowed Content Length setting is, well, no one's fault per se. Although that argument can be made, the reality is that Microsoft's customers are the ones that are left to struggle with this problem.
Conflicting Configuration Settings Make for Poor Security
Ultimately, although this particular problem is more or less just a communications (or ownership) failure between the IIS and ASP.NET teams, security hurdles such as this are what cause many developers and administrators to simply give up on trying to correctly secure their applications. And that, in turn, means that far too many systems and applications end up running with overly elevated permissions -- which, in turn, defeats many of the security initiatives and wins that Microsoft is trying to achieve by introducing features such as the one I banged my head into over and over again the other day.
So, long story short: If Microsoft really wants to improve security (and I know that they do), they're going to have to step things up a notch and start working as a company toward achieving this goal instead of just as multiple, independent teams working on this larger puzzle.
