Note: this post is a rambling with no solutions at all–I’m just bitching/rambling, whatever you want to call it–hell, it’s my blog, I’ll write what I please :)

There’s an interesting trend in the formerly “Gospel” OSI virtual model for the way computers talk…

It used to be that the application layer was sacred and didn’t violate lower-level protocol’s. When I say that, I mean that when you talked on TCP port 80 (i.e your IP packet was tagged with 80 in it’s TCP header) to a web server, you talked RFC HTTP lingo…the server understood your requests, your browser understood the responses, etc.

Now, the “web application layer” has become the new virtual transport layer. We have decreased the overall exposure from the packet-byte perspective, taken advantage of the proliferation of web-based “thin-client” applications, and we are now building client-server applications that transcend the browser-server barrier and utilize embedded or installed client applications, mirroring a more legacy client-server deployment strategy.

What comes immediately to mind is the .NET “Smart Client” technology (http://msdn.microsoft.com/en-us/library/ms998468.aspx), which is getting some increased discussion on some popular webappsec forums…

Basically, the technology utilizes web services technologies over HTTP to facilitate what looks more like legacy client-server technology. This scares me a little in terms of the wide-spread adoption of “web-enabled” technology.

If we take the standard user-available browser out of the picture and require a client-technology, what have we really achieved here, except take an already overly-exploited protocol and base our future on this?

So, lets close all of our firewalls except for web traffic on TCP ports 80 and 443 (sometimes 81, 8080 and others) and run all of our applications over these few ports….we haven’t closed the gap, we haven’t solved anything…we’ve just made the virtual model of understanding IP communications more consolidated to the old “application layer” of the old, old, old OSI model. (i’m not sure, but I think the “O” in OSI meant “OLD”….

Like I said at the beginning of this post…I’m just rambling/bitching/whaterver..it’s my blog

So after 12 years of analyzing security risks (and with a specialty on web app security) I’m surprised to find that a large percentage of webappsec risks we find still revolve around the configuration of the web server itself.

What I’m finding
1. Verbose, default vendor-supplied error messages – this is really prevalent with IIS/ASP implementations…what a major impact when ASP.NET reveals exactly why a SQL Injection or Cross-Site Scripting attack failed…

2. Building a “secure” website, but still allowing standard HTTP connections – this seems like a no-brainer, but so many organizations will “SSL-enable” their web servers, only to let standard HTTP requests to the same content!

3. Not differentiating Server requests from Form requests or from URL requests – I’ve seen too many times where “Request” variables are handled in the generic fashion, rather than specifying “Request.Form” or “Request.Querystring” (in ASP.NET) or $_GET and $_POST (in PHP) –this can and HAS been a BIG problem with web apps I’ve analyzed.

These three points I see over and over and over again. (can I say “over and over ” again?– ’cause it happens nearly 100% of the time! — seriously, the numbers are in favor of this statistic)

What most organizations don’t realize is that these seemingly minor configuration flaws allow automated tools to really exploit most web applications.

So how can we protect our web apps from these seemingly minor issues?

Basic Protection
1. Always use custom HTTP error messages. These can be configured in IIS and Apache very easily. Where ASP.NET is involved, set “customErrors” to On or RemoteOnly (if you really need local debug) and set the “defaultRedirect” option to a generic HTML page with no specific error messages.

2. With IIS, if you don’t control your firewall, set the “Require Secure Channel” option under the Secure Communications section of the Directory Security tab for the site at question. This will generate a default error message, so use a custom error message or issue a redirect. If you DO control the firewall, don’t allow port 80 inbound…simple

3. Differentiate Request.Form from Request.Querysting from Request ($_GET and $_POST rather than $_REQUEST in PHP).

These are some basic (and I mean basic) protection measures that can reduce the overall attack footprint of your site and save face should you be subject to an assessment or audit.