In collaboration with SQL Server, IIS, and Hewlett Packard, the Microsoft Security Response Center (MSRC)

Pingback from  Microsoft: Rise in SQL Injection Attacks  | Infosecurity.US

When I went to download scrawlr I found that the code checking the form fields for zip and phone number is broken for non US locations. It tries to enforce a US format ZIP code (our postcodes have 4 digits) and some sort of phone number that appears to choke on an international dialling prefix. This despite selecting "outside US" from the dropdown. Consequently I had to make up fields that would get past the checks which makes their entry pretty pointless for HP.

Oh dear. This "useful" tool is clearly going to be used by hackers (or worse - script kiddies) to determine which sites are vulnerable! I mean how perfect a tool can a hacker ask for - this thing even gives them the table names!

if only we could download outside of us - keeps throwing back invalid zip/postal code on download page

"Will not test forms for SQL Injection (POST Parameters)"

I think that the tool is pretty useless without testing forms, don't you?

Interesting stuff.  Hey we're a hosting provider and are considering implementing a new security policy requiring that all customers hosting web applications on our servers modify their code to read from read-only datasources and write to write-only datasources.  SQL injections an admittedly still be executed on the write datasources, but we think it might at least slow hackers down and provide an additional layer of security.  Think it's worth the trouble?  Is this a common practice?  Thanks!

I will be getting back to the "Day in the Life of the DBA" series of posts, but I got this from the security

Doesnt' support POST forms or Javascript. In other words, this demo tool can't actually test anything that any web developer would have written since, oh, say 2001.

Epic fail.

In response to edddy:

update footable set last_name="Jones" where row_id="47";

Write-only users tend to be useless if you ever have to update rows based upon criteria. Assuming your users do more than keep a database of page hits, your solution has a serious problem.

Hi everyone, thanks for your feedback, a lot of people are pretty critical about our decision to not include testing of POST parameters. we thought about it, but the original scope of this tool was to find the same types SQL injection vulns that were recently responsible for the compromise of over 500,000 sites (some estimates suggest 2 million sites). I know, most people would think something like this wouldn't be so prevalent but it would seem that the majority of web sites are still developed without regard to security issues. It's out hope with this tool that we can build awareness of this issue and help folks out there justify the need to consider security issues when they are building and testing their applications. If folks have feature requests or other rants and raves, please feel free to let us know in our Scrawlr forum at www.communities.hp.com/.../198.aspx

Thanks!

It would be nice if the tool could use cookies from previous authentications or allow the tester to input their credentials prior to initiating the crawl.  Without one of these features, the tool can't crawl websites that require authentication so it's not very useful.  

Is this tool just a subset of HP/SPI Dynamics' SQL Injector tool?  If I already own that own, should I bother with this tool?

Reply to Richard Jackson:

SQL injection can be used to steal data on a read-only database (such as account numbers and addresses).  It can also be used to run code on the server if the DB engine hasn't been hardened.  Your suggested limitations do not add protection but will instead break some well designed sites.

We Mac users need to be able to check the vulnerabilities of our web sites too, but we can't use the MSI file. Are there any plans to create software that I can use on OSX?

thanks for the info

Erik, If's tough trying to "train" developers, seems they are all from the "show me" state. Raising awareness is nice, getting in the face of developers with their tablenames is much nicer, finding the offensive code to protect an infrastructure is best. You get us 5/8 of the way there.

Pingback from  A Promenade Digital Life??? -   Scrawlr: Functional SQL Injector Tool

Well the tool is pretty cool, but there is a glitch in one of the scripts that reads out the database. The tool performs a: select cast(db_name(dbid) as int)  from master..sysprocesses where spid=@@SPID

which when encrypted looks like:

(select+cast(CHAR(+127+)%2bdb_name(dbid)%2bCHAR(+127+)+as+int)++from+master..sysprocesses+where+spid%3d%40%40SPID)

The script should in fact read:

(select+cast(CHAR(+127+)%2bdb_name(dbid)%2bCHAR(+127+)+as+nvarchar)++from+master..sysprocesses+where+spid%3d%40%40SPID)

The cast has to be to nvarchar instead of int to be able to read out the database name. :-)

Roll on developers for version 2.0?

In collaboration with SQL Server, IIS, and Hewlett Packard, the Microsoft Security Response Center (MSRC)

In collaboration with SQL Server, IIS, and Hewlett Packard, the Microsoft Security Response Center (MSRC)

Pingback from  New tools enhance SQL Server security « Circuitous windings in thought

Poorly written web code is one of the most causes of sql injection!.

Interesting post.

F.

I just tried to run this on my site.

It keeps saying scan did not complete (Scrawl limit reached).

Pingback from  Scrawlr - check *your* website for SQL injections | SecurityGuy.org

Pingback from  » New tools enhance SQL Server security | SQL Server Feeds

Pingback from  » New tools enhance SQL Server security | SQL Server Feeds

Pingback from  » New tools enhance SQL Server security | SQL Server Feeds

Pingback from  » New tools enhance SQL Server security | SQL Server Feeds

Pingback from  greg hughes - dot net - SQL Injection attacks in the wild - why they're working and what to do

Pingback from  Finding SQL Injection vulnerabilities on your site