When testing for SQL injection in an URL like this: example.com/videos.php?id='34, we use character sequences like:
'
"
""""
/*/
-' --
And many others...
How could you test links like these for SQL injection:
example.com/articles/another-perspective-on-data
example.com/category/tutorials/cooking/
How you plan to use the information is the greater tell of how to handle this. If you're attempting to ensure the nobody is using and SQL injection attack against you, the answer isn't to try and detect it with blacklists. The proper approach is to make use of features such as bind variables.
If your goal is to provide a warning system for somebody poking around at things they shouldn't, detecting SQL keywords such as "and, or, select, delete, where, update, drop" and the like can help. The problem with blacklisting ( SQL query sanitation (black list) ) is that two-fold: you will probably get false positives and you will probably miss well-obfuscated attacks. While it can give you an edge in attack detection, I've written queries that get beyond these filters and I've become very frustrated when normal sentences are blocked when filling in forms.
sqlmap makes it easy (add an * for each test position):
sqlmap.py -v 4 -u http://example.com/category*/tutorials*/cooking*/
sqlmap.py -v 4 -u http://example.com/articles*/another-perspective-on-data*
-v 4 will display each GET request on stdout so you can see the exact requests and observe how sqlmap is probing.
When a URL looks like that it means it is being rewritten. On an Apache webserver it's accomplished through the htaccess file using mod_rewrite.
Here's an example rewrite:
RewriteRule ^([a-z])-([0-9]).html$ /index.php?page=$1&id=$2 [L]
Any characters other than the ones defined in the regular expression will be filtered out. It's mostly used with GET queries and it provides some protection. But a regular expression that isn't specific enough could let an injection through.
Here's an example vulnerable rewrite:
RewriteRule ^([a-z.*])-([0-9]).html$ /index.php?page=$1&id=$2 [L]
Testing for an SQL injection would look like this:
example.com/cate'gory/1234
Assuming no other form of protection and not using parametrized queries or properly escaping input, that query would alert you of a possible SQL injection.
1) You can't reliably detect an attempted attack by statically analyzing the text of the request.
2) Correctly written request handlers have nothing to fear from SQL injection attacks.
I can see two things you might be trying to do.
Perhaps you want to identify malicious requests so you can ban the attacking IPs. It would be reasonable to do that by instrumenting your SQL quoting code (the part that quotes incoming data so it is safe to insert into a query) to look for lists of suspicious characters. Mostly the things you're expecting to insert into queries will be simple text or numbers, and finding punctuation characters is very suspicious.
Perhaps you'd like to have a rear guard watch for attacks that might have succeeded, because of bugs in your form processing. You should treat any failed queries as extremely serious, log them and send alerts. Most attempted SQL injection will fail because they're only guessing how to structure the inserted SQL.
