Top 15 Free SQL Injection Scanners

J.R writes "The Security-Hacks blog has a summary of the 15 best free SQL Injection scanners, with links to download and a little information about each one. The list is intended asan aid for both web application developers and professional security auditors."

asian aid

[User 956]

The list is intended asan aid for both web application developers and professional security auditors.

Ok, so that covers China and Japan, but what about Europe and the U.S.?

Re:

[Mr0bvious]

I don't think it was the editor's fault. His post appears to have been hacked, most probably using some SQL injection.

Why is this needed at all?

[Anonymous Coward]

If you just make sure you always use prepared SQL statements with positional arguments, you will never have any problems with SQL injection.

I suppose the over-use of PHP (which for a long time didn't even support prepared statements (does it even do it today?)) combined with stupid users that created the current situation.

Re:

[koh]

The DB interface in PHP5 supports positional arguments AFAIK. Now, if only the service providers would switch to PHP5, there would be less problems. Unfortunately, it seems that, at least here, the major providers are still stuck in PHP4-for-compatibility-with-existing-apps mode.

Re:

[billcopc]

Gee that's an easy solution: dump the legacy apps! PHP 5's only been out for 3 years :P How hard can it possibly be to rewrite the vulnerable bits of SQL anyway ? I never really felt much of a shock when I switched to PHP5 years ago, the bulk of my coding habits were unaffected and the few things that broke involved a 5-minute fix or less.

Non Issue

[encoderer]

1. You can easily run both PHP4 and PHP5 on the same server. When it's done, it's usually determined by a .php5 extension or <?php5 ?> braces.
2. The upgrade from 4 to 5 CAN be quite painful if you've done a lot of OOP coding in PHP4. Nearly all of the upgrade was focused on increasing and improving OO support. Some of the changes made (like, for example, constructor naming) are backwards compatible, but most aren't.
3. This is all moot because you don't HAVE to use the Circa-php4 mysql extension, anywa

Re:

[neoform]

mysql_real_escape_string() has been a function going back to php4..

Re:

[ThwartedEfforts]

magic quotes ain't helping though either, but I suppose seeing backslashes littering the output (as is common on many websites) is better than SQL injection. The magic quotes setting, and the concept behind and naming of the stripslashes function, is so confusing that it's best to just turn off magic quotes, don't use stripslashes, and manually make sure you either quote everything (hard) or use prepared statements (much easier).

Re:Why is this needed at all?

[mabinogi]

It's the completely wrong answer to the problem though, as it still promotes the idea of using SQL built by string concatenation.
The result being that SQL injection is only one forgotten function call away.

Re:

[PhotoGuy]

It's the completely wrong answer to the problem though, as it still promotes the idea of using SQL built by string concatenation.
The result being that SQL injection is only one forgotten function call away.

I agree. I actually find it easier to use the call with parameters, rather than trying patch together a string. Putting in the "?" parameters in the string, and listing them afterwards, pretty damn simple. I'm amazed SQL injection is an issue at all. I guess there's a lot scarier programming out the

Re:

[GnuDiff]

I think it is due to 2 reasons:

1) the string concatation technique being present in several pretty popular (and awful) PHP books, and (afai remember) in the PHP documentation itself, thus becoming defacto "standard";

2) The general ignorance of a significant part of PHP developers of any database abstraction layers and in fact anything but the magic LAMP.

Re:

[smellotron]

Personally, I like either of these two case (syntax off the top of my head):
// Using PHP5's PDO
$stmt = $pdo->prepare('SELECT f1, f2, f3 FROM foo WHERE x = ?');
$stmt->execute(array($x));

// Using native Postgres calls (ADOdb does this internally)
$stmt = pg_prepare('SELECT f1, f2, f3 FROM foo WHERE x = $1');
pg_execute($stmt, array($x));

However, there are cases where prepared statements are insufficient, though they are certainly not mainstream. You can't prepare an incomplete statement. I

Re:

[Firehed]

Only helps if you use it. It's easy to forget at least once, especially in a big project.

Re:

[vdboor]

For a security audit of an existing code base! Or are you willing to hire someone to browse code in a month time?

I suppose the over-use of PHP (which for a long time didn't even support prepared statements (does it even do it today?))

Every language allows you to write libraries which do things properly. The language is not a limiting factor here.

Re:

[matthewbarr]

I have to agree - these tools could be very useful in getting to grips with a bunch of code that's been written by someone else. However, if you're writing the app yourself, sloppy code (concatenating queries on the fly, ignoring functions such as mysql_real_escape_string(), etc.) and not validating user input are your main concerns. PHP is not the problem if used correctly!

Re:Why is this needed at all?

[hclyff]

Every language allows you to write libraries which do things properly. The language is not a limiting factor here.

PHP did not for a long time. And no, I don't believe that "magic quotes" allows you to write secure code properly. Any framework which relies on string concatenation for building an SQL command is inviting insecure code, because the programmer has to *actively* seek to fix injection problems. There is statistical certainty he will overlook something sooner or later. Coupled with the fact that PHP4 was (is?) prevalent compared to PHP5/6 for a long time, it just might be the single most contributing factor to why are SQL injections so common.

Re:

[encoderer]

1. Explain to me how PHP didn't allow libraries to be written? I don't understand that whatsoever. In PHP4 I'd write (and have written) a data abstraction layer that wrapped the inbuilt mysql functions, incorporating, among other things, string cleansing. The mysql library is procedural in PHP4 and below (and is both proc and oo in 5). So even if you're using <4 you can just write your own wrappers for all the functions and throw them in a file that gets auto_prepend()'ed to every page. (auto_prepend act

Re:

[Sancho]

There's a lot to be said for learning proper programming practices up front. A language which lets you shoot yourself in the foot that easily will likely cause the student to learn bad habits which will make later languages harder to learn, and which lends itself to creating security holes. I'd definitely not learn on PHP first, unless secure practices are a part of the criteria (not the case for most self-learners who read through a book.)

Re:

[encoderer]

Oh come on. The same thing (shooting yourself in the foot) could be said, nay, SCREAMED, about C. But nobody here is blaming bad programming on the language in that case. Anybody learning "proper prgramming practices" can do so with PHP just as well as she could with any other language.

Re:

[Sancho]

The same thing (shooting yourself in the foot) could be said, nay, SCREAMED, about C.

Absolutely. Did I say that C was a good learning language? The reason that I didn't mention C was because this is a thread about PHP, and because this is a story about SQL injection where one of the most common interfaces to the database is (wait for it)..... PHP.

And if you'll note, I alluded to the fact that you could learn proper programming practices with any language, however that requires learning aids which mention them. In schools, this is sometimes the case. In books, it's much less so. Withou

Re:

[FooBarWidget]

Prepared statements are slower because it needs an extra server roundtrip. I've recently discussed this issue on the Ruby on Rails core mailing list [google.com], and people mentioned this while asking why we need prepared statements.

Re:

[ensignyu]

You could always use client prepared statements, which is mostly the same as building your own SQL statements strings but are much cleaner and does the quoting for you.

Re:Why is this needed at all?

[ceswiedler]

Huh? Do you prepare your statements every time you execute them? That would certainly be slower, but if you prepare the statement once and execute it many times, the local overhead becomes minimal and the execution time in the database improves because the DB doesn't have to re-parse and re-plan the query.

Re:

[FooBarWidget]

"Huh? Do you prepare your statements every time you execute them?"

Uhm, if you use PHP then you *can't* cache your prepared statements (unless you do the same query many times in the same PHP run, but that's unlikely). PHP is stateless, after one run it frees everything.

"but if you prepare the statement once and execute it many times, the local overhead becomes minimal and the execution time in the database improves because the DB doesn't have to re-parse and re-plan the query."

In theory, yes. But are there

Re:

[Gotebe]

I wrote a little test script which inserts 300000 rows in MySQL Do you know if your DB of choice has a cache of prepared statements (many do)? If no, what did you expect?

Re:

[enrevanche]

I cannot answer for Ruby, but for Java/JDBC this is only true for the first call to a prepared statement. For the second and subsequent calls to a prepared statement, a prepared statement is always better or at worst equivalent. With connection and prepared statement pooling, performance can be improved dramatically.

Note that this all depends on the database and the driver, as some databases do not cache query plans or the driver does not properly coordinate the query plan with the database.

There is no s

Re:

[smellotron]

Because PHP is stateless, there is no connection pooling and SQL statements must be re-prepared at ever script execution. In my experience, there are very few cases where a query gets executed multiple times on a single script, so the benefit for preparing goes wayyyyy down. If you really need a complex query prepared, turn it into a procedural function in your database. This pushes the expensive query-parsing to the first function call for PL/PGSQL (Postgres), and turns all of your SQL queries into stuf

Re:

[jZnat]

PHP 5 does natively via PDO [php.net], and PHP 4 (and 5) does via PEAR's MDB2 [php.net] (older version: DB [php.net]). There is also ADOdb [sourceforge.net] which has a very similar API to Microsoft's ADO RDBMS API (acronym overload!).

The availability of robust packages like those still doesn't stop newbie (and veteran) PHP programmers alike from just using the raw MySQL API subset known as the mysql_* functions (which were deprecated in favour of the newer MySQLi [php.net] functions/objects that also support prepared statements) along with occasional use of adds

Re:

[smellotron]

The availability of robust packages like those still doesn't stop newbie (and veteran) PHP programmers alike from just using the raw MySQL API subset known as the mysql_* functions

I'm a veteran PHP programmer, and I've worked in a dedicated Postgres environment (we were more likely to switch our scripting language from PHP to Python than our database from Postgres to anything). We used PEAR::DB, and frankly, I think it sucked. It didn't support modern Postgres features at all (including using addslashes

Re:Why is this needed at all?

[vr]

If you just make sure you always use prepared SQL statements with positional arguments, you will never have any problems with SQL injection.

Actually, that is not true, as it ignores one problem: bugs in the database drivers. Seriously, there have been bugs in database drivers that have enabled SQL injection... I specifically remember a bug in the PostgreSQL JDBC driver [postgresql.org] a while back.

I also remember seeing a JDBC driver that simply inserted arguments into the string containing the SQL statement, although I fail to remember exactly which driver that was. This was a while back, mind you, so hopefully errors like that have been fixed. :)

Until I encountered these things, I believed that positional arguments was the silver bullet. The point here is that positional arguements in itself is no guarantee, it is only a part of an API. At some point you have to trust the developers of the database driver and the database itself, of course...

Re:

[nurb432]

Because people sometimes goof, and its always good to test test test test.

Re:

[xwipeoutx]

I use prepared statements most of the time... however it's a pain in the butt when using the IN clause - there's no real way to do that, and I end up just concatenating SQL for those anyway

Re:

[Shados]

Thats still fine with IN Statements: you concatenate strings, yes, but from a trusted source (your own!) to add the parameter placeholders, and then loop to add the parameters to the collections. So its completly safe, and still ends up as a prepared statement.

Another way that I like, is (for DBMS that supports it) pass as a parameter an XML document with (if i'm paranoid) a schema, then pivot it as a table, and use the IN on that. Works pretty good.

Re:

[AnObfuscator]

If you just make sure you always use prepared SQL statements with positional arguments, you will never have any problems with SQL injection.

Well, prepared statements have their own shortcomings -- they're not the magic bullet to solve all our DB issues. Some would have you believe they are, but don't be fooled.

I suppose the over-use of PHP (which for a long time didn't even support prepared statements (does it even do it today?)) combined with stupid users that created the current situation.

IIRC

Re:

[1110110001]

which for a long time didn't even support prepared statements

Let's take an example: http://viewcvs.php.net/viewvc.cgi/php-src/ext/oci8 /oci8.c?revision=1.1&view=markup [php.net] - added 8 years ago. Prepare? Yes. Bind? Yes. For 8 years. Now that's what I call supported for a long time.

The problem is more with this database named after a child, which didn't support any of the advanced features for years.

Alternatives

[stonecypher]

Of course, security through obscurity is badbear.

That said, there are times - and this is one of them - that I'm glad my recently most common database isn't fundamentally SQL, or anything well-recognized. It also helps that (I believe) mnesia is immune to injection [erlang.org], given that its queries are never textual, but rather always functional, and given that data are always presented as arguments. Every route to injection I'm aware of just doesn't make sense in context (though if someone knows a way attack Mnesi

Detecting SQL Injection is hard ...

[Gopal.V]

The feedback factor for SQL Injection is very low. It is very hard to generically detect the after-effects of a successful sql-injection attack.

In comparison, something like XSS is easy because if you inject a string, the string re-appears in the HTML returned (HTML injection). The XSRF and XSS attacks dominate the internet attacks because they are really easy to scan for - though technically that should be an excellent reason they shouldn't exist :)

Rasmus Lerdorf has this awesome test-tool for XSS he keeps demo'ing (thankfully not released). You can see the tool in action [flickr.com] in the background. But there's still no real easy way to reliably scan for Sql injection.

Re:

[gratemyl]

True, but a XSS attack is only going to hit individual users (usually ones stupid enough to click where baited)

No need to click - it is easy to steal cookies and other information by injecting an img tag with onload=...

Re:

[Plutonite]

Rasmus Lerdorf has this awesome test-tool for XSS he keeps demo'ing (thankfully not released).

Why thankfully? I've left this stuff a long time ago, but nothing has changed about security and obscurity. You cannot win this way, you only prolong a possibly undetected failure.

Re:

[larry bagina]

Rasmus Lerdorf has this awesome test-tool for XSS he keeps demo'ing (thankfully not released).

Actually, it [php.net]'s been released for a while now.

Re:

[account_deleted]

Comment removed based on user account deletion

what exactly is an sql injection?

[siddesu]

i hear people talking about them from time to time, but i still can't figure out how they appear.
ain't there query parameters in practically all database access APIs?

Re:what exactly is an sql injection?

[MickDownUnder]

SQL injection attacks target code in which sql statements are dynamically created.

e.g.

'select * from employees where fullName like ' + mySQLInjectedInputFromUser

where mySQLInjectedInputFromUser has been asssigned a value entered by the user:-

Fred Flinstone; GO; delete employees; GO

Re:

[weicco]

Yep. And that's why you should use parameters instead of dynamically creating SQL commands as string. Not like this (C# .NET):

SqlCommand cmd = new SqlCommand(); cmd.CommandText = "SELECT * FROM t_Table WHERE Something LIKE '" + InputString + "'";

But like this (C# .NET):

SqlCommand cmd = new SqlCommand(); cmd.CommandText = "SELECT * FROM t_Table WHERE Something LIKE @param1"; cmd.Parameters.Add("param1", DbType.String).Value = InputString;

Lousy example, I know. A lot of languages and/or frameworks sup

Re:

[Shados]

Its not the language that makes it so you use ? or @name for the parameters, but the access layer and/Or the DBMS itself. For example, using ODBC or OLEDB, even if you connect to SQL Server with C#, you'll end up using the ? way of doing things. Just a side note :)

Re:

[Tablizer]

Is there a way to turn off the execution of multiple statements per query? Why the API's allow this, I don't know.

Re:

[Sancho]

I don't know if you can turn it off--it's probably a per-database or -interface issue, however why they allow it is simple: complex queries and operations can require it.

Wikipedia is your friend

[CaptainZapp]

For more information about SQL Injection [wikipedia.org]

Re:

[cheater512]

Oh the common interface is there. Its just that people (like you) dont know about it.

www.php.net/pdo

Re:

[siddesu]

pray tell, how does (using the example above, and an imaginary access api)

this:
st = api.createStatement('select * from employees where fullName like ' + mySQLInjectedInputFromUser);
st.execute

take more time to write than this:
st = api.createStatement('select * from employees where fullName like ?' )
st.execute(mySQLInjectedInputFromUser);

Re:

[FooBarWidget]

What do you mean, "I'll bite"? What makes you think it's a troll? Can't people have a legit question these days without being seen as flamers and trolls?

Properly written software...

[MickDownUnder]

In well written software SQL injection attacks shouldn't be possible. Don't use dynamic SQL, use stored procs. If you think you have to use dynamic sql, then create the sql statement within a stored proc (not code) then access that stored proc using authentication details that permit only read only access. I've never seen a situation in which dynamic SQL was required for updating or inserting data, generally it only gets used when performing complicated searching and even then it's not the only option...

Re:

[growse]

Why go through the faff of stored procedures whn you can just use parameterized queries? As far as I know, you need to have access to the db server to create/edit stored procs, and also, afaik, there's no way to use a source code control system on them.

Because a parameterized query sits in the code, you don't have to touch the db server if you want to do a code update.

Re:

[MickDownUnder]

It is common practice with database development tools to update stored procs from sql scripts which are checked into source control systems. Microsoft has a whole verion of Visual Studio [microsoft.com] for this purpose.

Not using stored procs at all in your application is typically done by novice developers, it is not how an experienced professional works with a database.

Re:

[growse]

Which I'm sure is fabulous if you're using .NET and MSSQL. However, I imagine that particular combination doesn't make up a very large percentage of all the database applications out there.

Don't get me wrong, stored procs are a useful tool which are the correct answer to some types of problem. But completely overkill if you just need simple or even slightly complicated CRUD operations. Using stored procs when they're not really necessary is the mark of a developer who doesn't know how to use every tool in

Re:

[MickDownUnder]

Most database engines takes advantage of store procedures to create a pre-prepared execution plan which is used to optimise and speed execution time. Visual Studio will work with any database with an ODBC connection. All Visual Studio gives you is a nice environment in which to extract sql scripts and check them into source control, you don't actually need Visual Studio, you can just use notepad and edit sql scripts and check them in and out of source control manually.

*sigh* I don't know what I was thinki

Re:

[Jaime2]

Most database engines takes advantage of store procedures to create a pre-prepared execution plan which is used to optimise and speed execution time.

Most database engines also apply the exact same techniques to plain text queries. If the plain text queries are parameterized, then it works even better.

All Visual Studio gives you is a nice environment in which to extract sql scripts and check them into source control

Visual Studio also give you powerful tools to build parameterized queries and wraps t

Re:

[MickDownUnder]

The whole parameterized query thing vs stored procs argument has been argued from the day the internet was born.
Here's the arguments I would make for stored procs.

Most database engines also apply the exact same techniques to plain text queries. If the plain text queries are parameterized, then it works even better

Database engines more often than not will generate a whole new execution plan for plain text queries, it can also cause the execution plan cache to fill up more quickly, plus it opens you up to s

Re:

[Jaime2]

plus it opens you up to sql injection

No, it doesn't. That's the false dichotomy that sp supporters like to espouse. A poorly called sp is vulnerable to SQL injection, while a well written, properly called ad-hoc query is not vulnerable. Just using a stored procedure does not protect you from SQL injection and just avoiding them does not make you vulnerable to it. I just worked up a real quick ad-hoc paraeterized SQLCommand in Visual Studio and here is what SQL Profiler shows me is really executing;

Re:

[Doctor Faustus]

What about my argument that T-SQL is a horrible language? You have one looping construct and one statement level conditional construct. Cursor loops require you to write the FETCH both before the loop and at the end of the loop making maintenance that much more tedious. Compile errors can be tough to track down as the messages are often vague. Hidden gotchas like compiling a procedure with QUOTED_IDENTIFIERS on and modifying it with them off are always fun. No select construct (as in a traditional programmi

Re:

[growse]

I'm sorry, but if you think that stored procedures are the be-all and end-all to db query security, then it would appear that you don't have a clue.

It is perfectly possible to write secure code without using stored procedures. It might be more difficult, in some cases, but not impossible.

Re:

[MickDownUnder]

No clue?

Riiight...

Well the biggest clue I have about security is that you build it into every tier of your architecture. Sticking security in one place is not a security architecture, well OK it might be, but as far as security architecture goes it sux.

Re:

[growse]

Correct. And randomly throwing stored procs into your database when you don't need them doesn't make your database secure.

Re:

[Shados]

Btw, what cracks me up is, bringing Visual Studio to the table, then talking about most database engines taking advantage of SPs for query plans...then forgetting...

One of the database engine thats the most used in tandem with Visual Studio, does NOT. In SQL Server, the execution plan is not pre-prepared. Its made at runtime, and cached. What does that mean? That dynamic sql (using prepared statements ONLY!), and stored procedures, have the same performance advantage, so that argument falls flat. I know not

Re:

[MickDownUnder]

Basically I think it comes down to consistency. I don't like writting an application where one half of my T-SQL code is in the DB and the other half in my source code.

At the end of the day I find in just about every enterprise app there is at least one feature that requires a complex set of T-SQL instructions to be executed that have definite performance benefits when executed within a stored proc as opposed to parameterised queries executed from source code.

So for consistency and extensibility I always st

Re:

[Shados]

As long as you put the right info (like application name) in your connection string, your DBAs will stay happy, no worries.

And there is NOOOOOOOOTHING you can do in a SP that you can't do in a param query. Nothing. None. ZERO. The only performance benefit you'll get is the bandwidth (if you run a long query 1000000 times in a row, its a lot of data going).

The rest is a decent argument, but one that only holds water in simple applications. In complex enterprise apps, you have a billion datasources. Probably

Re:

[MickDownUnder]

Stored procedures can also improve performance. Many tasks are implemented as a series of SQL statements. Conditional logic applied to the results of the first SQL statements determines which subsequent SQL statements are executed. If these SQL statements and conditional logic are written into a stored procedure, they become part of a single execution plan on the server

http://msdn2.microsoft.com/en-us/library/aa174792 ( SQL.80).aspx [microsoft.com]

Re:

[Shados]

Did you know that msdn has a lot of mistakes and errors, especially when it comes to SQL Server? Hell, I personally talked with some of its own engineers that had to be corrected by their superiors afte a discussion about its inner working. Thats not counting the insane amount of syntax error in their samples on SSIS, for example. :) That being said, that omits a simple detail: again, anything in a SP can be done in a dynamic sql statement.

That means conditionals, loops, temporary tables, transactions, you

Re:

[MickDownUnder]

I think the only way anyone is going to settle the whole performance thing is to actually go off and do some performance and load testing with two systems using both methods. What you're saying (depending on the literature you read) sounds entirely plausible, however I think the proof is always in the pudding.

I have faith that stored procs are actually going to win if only by the barest margin simply because there's an obvious reduction in network traffic for large complex queries. Plus I have faith that

Re:

[Shados]

Indeed, its probably better to drop it, but just to settle something: I personally always go with the "best tool for the job" philosophy, and i'm always looking for ways to improve what I do. What that means is, I actually HAVE been doing benchmarks on every versions of SQL server I've used, sniffed network traffic, personally discussed with some of microsoft's engineers, stressed test real life scenarios :) I -do- work for for an extremely large corportation, so these things tend to be crucial. One of the

Re:

[heinousjay]

In theory, that works, but there needs to be a very clearly defined separation regarding what ends up in the stored procedures. I'm a little gunshy about using this technique because I've seen it grow into an unmaintainable monster. Without a clear line between the DB interaction logic and the app logic things tend to settle all over the place. Granted, this isn't specifically a stored procedure problem, more a dev lead/team experience one, but it's still something that needs to be watched carefully lest

Re:

[Ash Vince]

What alovely idea, but here in the real world we have things called design constraints. Like maybe you have a web application that has been doing its job for the previous 5 or 6 years but is also constantly evolving. You have a lot of legacy code that was written to run against a mysql database from 5 years ago. That puts you on MySQL 4.0 with no stored procedures.

Now I am not saying this doesnt need an upgrade (currently in the works), but when you are talking about a mission critical app that is already m

Re:

[MickDownUnder]

In my real world I don't come across many legacy apps that don't leverage stored procs. Stored procs for way longer than 5 or 6 years. They were officially made part of the SQL language in 1999 and they were unofficially around many many years before that.

I don't go round re-writting everything just for the sake of making it mine. In the real world you evaluate every application on a case by case basis. In the real world it is very often the case that the time required to add new features or fix existing

Re:

[Ash Vince]

I also don't come across many jobs dealing with legacy apps, and the ones I do I tend to steer clear of. I prefer creating my own crap than dealing with somebody elses.

Good for you, I used to do nothing but create new code in my last job.

Nowadays I work in collaberation with serveral other developers and we all maintain each others code. Since I started I have learnt far more than I ever did when I only worked on designing my own projects from scratch. I also find it far more challenging and hence more rewa

Re:

[MickDownUnder]

Yes one day I could be as good a developer as you... dare to dream.

My comment was obviously meant with humour. I collaborate with other developers all the time. I even go to user group meetings to get exposure to as many alternate views on development as possible.

And like most developers I prefer to work with new or next generation technology rather than working within the confines of some sort of time bubble from 10 years back due to the restrictions of some legacy system's architecture.

Re:

[Shados]

While stored procedures are good, using dynamic sql inside the stored proc is (almost) as vulnerable as using normal dynamic sql.

The truly secure methods are:

1) Use stored procedure, with no dynamic sql whatsoever.
2) Use prepared statements: this make dynamic sql just as secure as stored procedure, and in the more advanced RDBMS, allows query plan to be cached (aka: it is virtually exactly as fast as stored procedures. SPs being used for performance reasons is a myth folks, at least with the better RDBMSs)
3

Re:

[MickDownUnder]

and... If your db is MS SQL Server use sp_executesql not EXEC

Re:

[Gotebe]

Don't use dynamic SQL, use stored procs. Ah, you mean like this: EXEC MyProc "UserInputHere". Yeah, that helps, especially if UserInputHere == "Nevermind""; drop table X". Coming from MS background, I reckon? Dynamic SQL and stored procs are largely orthogonal (using one doesn't preclude using the other).

Testing slashdot

[mobby_6kl]

blah'; UPDATE users SET uid = '1' WHERE uid = '668092';

Top 15 _______?

[kjart]

What is this, Digg?

Re:

[Jesus_666]

Hey, I'm not complaining; this makes my upcoming IT Security assignment much easier. Once again reading Slashot pays.

Validating Input

[mtjo]

Validating input prevents alot of problems. Prepared queries help but can still be exploited in poorly written statements. As in the classic SELECT query example, "where id=23 OR 1=1", using a datatype test as well as testing for null values for a $_GET or $_POST parameter before executing the query would throw back an error if expecting an unsigned integer.

One of the best SQL injection attacks I've seen...

[thewils]

...was in conjunction with an error page which displayed the results of failed SQL.

I was able to change an innocuous 'select ... from catalog where section=1' into 'select ... from catalog where section=(select password from users where id=1)'.

This was nicely reported back to me as a SQL error stating that SQL was unable to convert "sdfsdfsdfsdf" into an integer, where "sdfsdfsdfsdf" was user id 1's password. I reported the problem to the site's owners, and it was still a month before they fixed it.

Moral of story - don't show the users any SQL errors, it gives them far too much information.

Re:One of the best SQL injection attacks I've seen

[mig21bp]

don't show the users any SQL errors, it gives them far too much information

What do you mean by 'too much information'? Security through obscurity [wikipedia.org]?

do they check cookies?

[brunascle]

it's not just URLs and post-back forms that can be vulnerable, cookies can be too. i didnt realize that until i found one on my own site. (it wasnt exploited, i found it on my own.)

intresting

[MadKad]

intresting read thank you and well put together

Bwah

[bytesex]

I don't need SQL injection scanners. I use perl DBI and I always put arguments in as '?'.