Question: I agree that correct input validation is the only 'fool-proof' way to prevent SQL Injection, however it requires modifying a lot of code in existing applications, possibly might require a badly designed application to be re-structured.

There has been a lot of academic interest in automated mechanisms to prevent SQL Injection (won't go on listing them here, I've done a literature survey and seen at least 20), but I haven't seen anything that's actually been implemented.

Does anyone know of any framework that's *actually* in use outside an academic environment, either Signature-Based, Anomaly-Based, or otherwise?

**Edit**: I'm looking for something that **does not** modify the code-base.

Answer: 
The company i work for uses [Barracuda Web Application Firewall](http://www.barracudanetworks.com/ns/products/web-site-firewall-overview.php) for what you are talking about. From what I have seen it works fairly well. Basically if it detects suspect input it will redirect the user to a page of our choosing. This allows you to place a layer between the internet and your applications and does not require you to change any of your code. 

That said, it's a bad idea to not secure your applications.
If you aren't going to modify your code then you can only intercept requests. Since there is no such thing as a good or bad SQL command you're pretty limited in options but you could try rejecting multiple queries which initiate from a single string. In other words:

**LEGAL**

```
SELECT * FROM foo WHERE bar='baz';

```

**ILLEGAL**

```
SELECT * FROM foo WHERE bar=''; DELETE * FROM foo; SELECT 'baz';

```

Since pretty much every injection attack requires multiple queries in a single request and provided your application doesn't require this feature you may just get away with this. It probably won't catch every type of attack (there's probably a lot of damage you could do using subquerys and functions) but it's probably better than nothing at all.