URL Scan 3.0 Beta - New version helps detect SQL Injection Attacks (Full Version)

All Forums >> [Security, AntiVirus, and Patching] >> Best Security Practices



Message


hwaldron -> URL Scan 3.0 Beta - New version helps detect SQL Injection Attacks (6/27/2008 8:43:46 AM)

Microsoft has just enhanced a key IIS based security tool in response to the new wave of automated SQL injection attacks, that are currently circulating. This security tool can help spot weaknesses that should addressed by the web development tool (e.g., strengthening SQL-Server calls for improved security by using parameterized lists, ADO, stored procedures, and other secure techniques). URL Scan can detect or block many of the generic attacks by searching for special keywords.

URL Scan 3.0 Beta - New version helps detect SQL Injection Attacks
http://blogs.iis.net/wadeh/archive/2008/06/05/urlscan-v3-0-beta-release.aspx 

QUOTE: UrlScan installs as a filter on IIS and looks at incoming requests in real time. It can then screen requests based on a set of general request properties. For example, it can block overly long URLs or headers. It can block requests with unexpected HTTP verbs or strings in the URL.

Today, in 2008, we find ourselves in a similar situation. We are seeing a particularly nasty automated SQL Injection attack that is targeting our customers. This attack defaces web servers and sends their clients off to malicious servers that attempt to install malware. As before, the vulnerability does not exist in IIS - or any software from Microsoft. In this case, the attack is exploiting vulnerabilities in customer developed applications. And as before, the real fixes will need to come from the myriad developers of those applications.

The new set of features in version 3 are:

* Support for query string scanning, including an option to scan an unescaped version of the query string.
* Change notification for configuration (no more restarts for most settings.)
* UrlScan can be installed as a site filter. Different sites can have their own copy, with their own configuration.
* Escape sequences can be used in the configuration file to express CRLF, a semicolon (normally a comment delimiter) or unprintable characters in rules.
* Custom rules can be created to scan the URL, query string, a particular header, all headers or combination of these. The rules can be applied based on the type of file requested.

We also have plans to update the IIS 7 request filter to add these features. In the interim, UrlScan 3 is fully supported on IIS 7.

IMPORTANT RECOMMENDATION: Finally, it cannot be overstated that these tools are just an interim measure to buy time to fix the affected applications. While they are effective against the current wave of automated attacks, they cannot protect against more directed attacks against a specific server. The category of SQL Injection vulnerabilities is so broad that there are no known filter strategies that can block a determined hacker against application vulnerabilities. There are many resources available for learning about SQL Injection attacks and prevention strategies.

ADDITIONAL RESOURCES - HOW TO PREVENT SQL-INJECTION ATTACKS

http://msmvps.com/blogs/harrywaldron/archive/2008/05/31/microsoft-best-practices-for-preventing-sql-injection-attacks.aspx 

http://msmvps.com/blogs/harrywaldron/archive/2008/06/15/new-sql-injection-attacks-the-need-to-improve-legacy-web-applications.aspx 

http://msmvps.com/blogs/harrywaldron/archive/2008/06/25/sql-injection-mitigation-tips-for-asp-development.aspx




ndaniels -> RE: URL Scan 3.0 Beta - New version helps detect SQL Injection Attacks (6/27/2008 9:23:02 AM)

quote:

As before, the vulnerability does not exist in IIS - or any software from Microsoft. In this case, the attack is exploiting vulnerabilities in customer developed applications. And as before, the real fixes will need to come from the myriad developers of those applications.


That statement hits the nail right on the head.  Any site with an SQL backend is primarily going to be protected against attack by those who initially develop it.  If developers are not checking the validity of information being passed to the database from the frontend, mayhem will abound.  The old adage "plan ahead" comes to mind...  I'm not a web developer (and I don't want this post to sound like I'm hating on them); however, I wonder how often security is added on after the fact and not incorporated in at the development phase.




Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.234375