As you all know, Hiawatha has the ability to detect and block SQL injection attacks. It does so by matching user input with several regular expression patterns, which can be found at the top of src/session.c. I've always said that there is no 100% guarantee that all SQL injections are detected, hoping that someone would pick up the challenge and provide me with SQL injections that would bypass Hiawatha's filter. Unfortunately, no one did.

For the 9.7 release, I want to further improve Hiawatha's SQL injection detection capability. I've already made some improvements. Not only to the patterns itself, but to the entire approach. I've already seen that the filter can easily be bypassed by using the /* */ comment syntax, so those are stripped first. What I need is someone with good knowledge of SQL injection and regular expressions to pick up the challenge to provide me with a set of regular expressions that block SQL injections without false positives.

To make this all more easy, I've created a PreventSQLi test page. What this page does is strip the /* */ style comments, match it with the detection patterns and if no match was found, execute the query in a sandbox.

If you have good hacking skills or you know someone who does, please help to make Hiawatha an even more secure webserver.

To be clear, the PreventSQLi feature was never intended as a replacement for writing safe code. It's only purpose is to reduce the risk of being hacked while you wait for a patch for a vulnerable application when taking the application offline is not a real option. Nothing more than that.

2 June 2014, 21:41
You can find tons of information on the owasp website, esp.
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet for 2013 top 1 prio Injection.
Marc Abel
2 June 2014, 22:10
While I don't consider myself proficient in either, it is not immediately obvious that regular expressions are complete enough to accomplish this task. And if they were, it is not immediately obvious that (a) they would not be extremely inefficient computationally, or (b) that such inefficiency would not introduce a new DOS attack vector to Hiawatha. With these dual concerns, I would think seriously think about writing a parser for this purpose. But again, I have not studied the problem sufficiently to answer authoratatively.
2 June 2014, 22:11
p.s. Not always inefficient, but in certain boundary cases.
Hugo Leisink
2 June 2014, 22:23
I never said that regular expressions are the only possible solution. If anyone as a better solution, let's hear it!
3 June 2014, 04:59

t is very hard to create a list of SQLi pattern as the SQLi is depending on the web application vulnerability and web server configuration.

However, it is worth to study the mod_security rules set at https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project and http://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules. Most hardened Apache web server will use this set of rules.

mod_security is not perfect too. You can take a look in it for reference.

There are some papers for SQLi and Obfuscate, such as http://www.exploit-db.com/papers/17934/, http://code.google.com/p/teenage-mutant-ninja-turtles/wiki/AdvancedObfuscation, http://code.google.com/p/teenage-mutant-ninja-turtles/wiki/BasicObfuscation.

I just named some here.

Thanks for your works!
14 August 2014, 21:12
Hi Hugo,

This post is not new, I know, apologies for the late reply.

A very simple SQLi string that should be catched by pattern #3 actually succeeds. The string and a pattern that catches it (not sure if the change is okay!) are given below:

blah' or 'x'='x

Hugo Leisink
17 August 2014, 16:52
Hi Yassen. The SQLi detection pattern was not copied correctly from the Hiawatha source. Fixed now. Thanks!
17 August 2014, 19:43
Thank YOU for the Hiawatha project!
1 November 2014, 10:19

one of Tiki Wiki devs sent me the following email today:

Subject: Would Hiawatha have protected against DRUPAL-SA-CORE-2014-005 ?



What is the answer?
Hugo Leisink
1 November 2014, 11:15
Unfortunately not. I never expected a bug to be this stupid. In most cases, an SQL injection is done by changing an existing one. This bug lets your specify a complete new query. Anyway, the next version of Hiawatha will also detect this kind of injection.
Esmaeail Rahimian
2 May 2016, 22:43
with this username filed sql injection has been bypassed
username fild : ' group by ExtractValue(1,(if(1=1,1,@@version))) #
1=1 is condition
group by ExtractValue(1,(if(substring(version(),1,1)=5,1,@@version)))#
please patched it !!!!!
thanks for your project !!!
Hugo Leisink
2 May 2016, 23:08
I can't reproduce it. What exactly goes into the 'user input' field?
jay hou
28 July 2016, 09:31
Hi Hugo,
The symbol ` in your Patterns regular expression really confuses me. Could you explain it?
jay hou
28 July 2016, 10:30
Hi Hugo,
I get a array of Query result, when I input '--'. Is it a injection omitted?
Hugo Leisink
31 July 2016, 08:39
The single quote (') is for data in a query, the backtick (`) is for table and column names.

Thanks for the '--'. A block for it will be included in the next release.
21 June 2020, 13:13
how do I call this regular expression with php? tnks.
Hugo Egon Balder
3 August 2020, 09:34
preg_match as example