Will this regex patterns catch all the needed SQL injections?

Question

We changed our firewall rules (REGEX) to the following:

Name
 Type
 Context
 Severity
 Pattern

CS:select_into
 signature
 http-url
 critical
 .*\[select\]\s+.*\[into\].*

CS:select_from
 signature
 http-url
 critical
 .*\[select\]\s+.*\[from\].*

CS:insert_into
 signature
 http-url
 critical
 .*\[insert\]\s+.*\[into\].*

CS:drop_database
 signature
 http-url
 critical
 .*\[drop\]\s+.*\[database\].*

CS:drop_table
 signature
 http-url
 critical
 .*\[drop\]\s+.*\[table\].*

CS:delete_from
 signature
 http-url
 critical
 .*\[delete\]\s+.*\[from\].*

CS:drop_view
 signature
 http-url
 critical
 .*\[drop\]\s+.*\[view\].*

CS:exec
 signature
 http-url
 critical
 .*\[exec\].*(%28|\().*(%29|\)).*

CS:update_set
 signature
 http-url
 critical
 .*\[update\](%20|\+)(%20|\+|.)*\[set\].*

Will this block all SQL injection attempts? For example, is it possible to drop a view using multiple spaces?

Answer 1

A blacklist is the wrong approach. There will always be things you haven't thought of, which the attacker will think of.

What programming language / database are you using? They all have methods of passing parameters to SQL statements. For example:

String userName = .... ; // from your GET or POST parameter
String sql = "SELECT id FROM user where user_name=?";
ResultSet rs = executeSql(sql, userName);

See http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements

Answer 2

Trying to prevent sql injection by filtering out certain words is not going to work - there will always be something you miss and will be very time consuming to try and find everything to cover.

You should look at things like how you query the database - if you're building SQL on the fly and concatenating values from the client directly into the statement, then that's going to be an important area to focus on - switch to using parameterised SQL / stored procedures. Stored procedures will also give you an added layer of security as you can grant permissions to execute those without giving direct permissions on the underlying tables.