Largest Attack Vector Still Poor Configuration…

Thursday, November 06, 2008

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.

Vulnerabilities Webappsec->General
Post Rating I Like this!
avelin injector