En esta entrada se incluye una alternativa al filtrado de los típicos ataques por SQL Injection. En pocas palabras, si tenemos firewalls a nivel de red, propone el uso de "firewalls" a nivel de aplicación que pueda "detectar" este y otros tipos de ataque, y actuar. Nada excesivamente nuevo.As botnets and other automated tools are hammering at websites trying to exploit SQL injection vulnerabilities, site operators are trying hard at defending their websites. ASProx and other botnets were hitting hard at the ASP + MS SQL platform, millions of websites fell victims to the SQL injection vulnerabilities already. Although there has been a decline of wild SQL scanning by ASPRox type of botnet, we are still not in the clear yet. The unauthenticated portion of some sites might be secure, but the authenticated portion might be totally vulnerable. Since most scans only target what can be seen by Googlebots, there are still tons of web pages out there vulnerable waiting for exploitation.
If you have tons of vulnerabilities on your site, you likely will take some time to fix all of it as fixing code isn't the easiest and fastest thing to be done. A short term remediation to SQL injection can be web application firewall. Web application firewall (WAF) is similar to a network firewall except it also inspect the application layer information, such as cookies, form fields and HTTP headers. With Microsoft IIS as web server, one of the quickest and easiest WAF solution maybe Microsoft's Urlscan, it is an addon to IIS5 and built-in for later versions of IIS. Urlscan runs as an ISAPI filter, so it can be easily deployed and removed. Since version 3.0 of Urlscan, there are decent level of coverage on SQL Injection capabilities. The biggest complaint is that Urlscan do not inspect HTTP request body (POST data), so it could be missing attacks that are submitted using POST.
I have recently played with another free WAF product on IIS called Webknight and found it to be easy to config and full of nice features. The default configuration file is reasonably tight. In most cases, you would probably want to loosen things up so Webknight won't break your site with false positives. It inspects SQL injection in header, cookies, URL and in POST data. The detection is based on hitting two of the preset SQL keywords. For most cases, this generally works well. It may render false positives with some more complex textarea field that expect various text. Overall, Webknight is a good WAF that can fulfill basic protection needs.
Remember that WAF products are meant to be an extra layer of defense and/or a very short term mitigation until you fix up all the code. For mitigation, you are really just buying yourself more time before a compromise happens. While WAF do a good job at making the site harder to compromise, they have various limitation, the most effective long term mitigation is still fixing up the code.
[Fuente.: http://isc.sans.org/]
