CODEWITHSUNDEEP
securitysql-injection
Vanwaril
Vanwaril

Reputation: 7518

Non-programmatic prevention of SQL injection

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.

Upvotes: 4

Views: 868

Answers (4)

rook
rook

Reputation: 67019

The only way to leave the code untouched while patching vulnerabilities like SQL Injection is to use a web application firewall like the open source project mod_security. Recently Oracle has released a database firewall which filters nasty queries. This approach is better at solving the problem of SQL Injection, but that all it can address.

WAF's are very useful and free, if you don't believe it put it to the test.

A WAF is just one layer. You should also test the application* under it. This is a defense in depth approach.

*This is a service I sell with a limited free offer.

Upvotes: 1

Abe Miessler
Abe Miessler

Reputation: 85046

The company i work for uses Barracuda Web Application Firewall 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.

Upvotes: 8

Jeremy
Jeremy

Reputation: 607

The default behavior with PreparedStatements in Java where you pass in each parameter makes it mostly foolproof because the framework escapes the input for you. This doesn't prevent you from doing something like

exec spDoStuff <var>

where spDoStuff does:

exec( <var> )

But if you use normal queries it's very effective. I don't know whether you'd consider it non-programmatic but the developer doesn't have to write the code to manage input validation themselves.

Like this:

int id;
String desc;
Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement("SELECT * FROM table1 t1 WHERE t1.id = ? AND t2.description = ?");
// or conn.prepareStatement("EXEC spMyProcedure ?, ?");
ps.setInt(1, id);
ps.setString(2, desc);
ResultSet rs = ps.executeQuery();
...
rs.close();
ps.close();
conn.close();

Upvotes: 1

SpliFF
SpliFF

Reputation: 38956

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.

Upvotes: 3

Related Questions