23 January 2016, 12:03

Can you bypass Hiawatha's SQL-injection protection?


7 February 2016, 20:55
Hi Hugo,

I think it is a bad idea to tell attackers that your site is protected by WAF. I would suggest a misleading or confusing error page instead.
Hugo Leisink
8 February 2016, 07:56
The error code that Hiawatha returns is configurable. You can also send a 403 or a 404.
8 February 2016, 09:02
Hi Hugo,

Can I mask error code 441 to 404 like that?

ErrorHandler = 441:/error.php?code=404

By the way, where can I get all the WAF error codes and their description?

Hugo Leisink
8 February 2016, 09:38
You can have your own error messages via the ErrorXSLT setting. Use XSL commands to customize the error messages.
Akash Talole
17 March 2016, 15:50
I have written a python script using tornado which writes hiawatha.conf file through my web control panel. So database is not required for configuration. But it is required for adding new sql injection and xss attack pattern detection regular expressions. Currently in session.c sqli patterns are hardcoded but they are not sufficient. So that for security reason it is very necessary that regular expression pattern must be in database. So that new patterns can be easily added and that will provide security to the website.
Akash talole
17 March 2016, 15:53
I have attacked on http://sqli.hiawatha-webserver.org/ with sqli pattern admin' or '1'='1 and your server detected SQL Injection. But when i use hiawatha for my webserver then it doesn't detects sqli.
Hugo Leisink
18 March 2016, 06:56
Did you set PreventSQLi to 'yes'?
9 September 2016, 05:45
Hi Hugo,

Where are the regular expression patterns in hiawatha, I would like to see these.
Hugo Leisink
9 September 2016, 08:12
They can be found in src/session.c at line 35.
15 September 2016, 03:34
I installed with "yum install hiawatha", but I not find src/session.c.
Hugo Leisink
15 September 2016, 07:00
For that, you need to download the source tarbal.
16 September 2016, 03:44
Ok, I made thats.. and It is ready, thanks
Peter Panski
28 November 2017, 10:55
Did anyone bypass it by now?
Hugo Leisink
28 November 2017, 10:56
No, so far no successful injection. A lot of attempts though.
25 January 2018, 17:18
Can we get a valid username (not uncommon in real-world applications)?
Hugo Leisink
26 January 2018, 01:56
Sure. There is a user 'hugo' in the database.
30 January 2018, 10:29
Thanks, with the valid username I've bypassed it. Should I post here / PM / email you?
Hugo Leisink
30 January 2018, 12:47
Hi Simon. I've already seen it in the logfiles. A fix for it will be available in the next release. Thanks!
30 January 2018, 13:14
Cool. My point though was to illustrate that SQL injection prevention is not really the responsibility of the web server (or any WAF for that matter), and the exploitability of any such vulnerability also depends on the code of the application. I've *briefly* browsed through the source code of the SQL Injection detection functionality and it looks quite good, however, I think there will always be a way to bypass this, depending on the back-end code. Like you say on the About page, "I strongly believe that many features you find in several other webservers, shouldn't be placed inside a webserver". Obviously, it doesn't hurt to include a built-in WAF, but I would advise caution in how you communicate the ability of these protections to your end-users.

I must also admit that I have not used the Hiawatha webserver before, but I will surely consider it for any future projects that require a lightweight webserver, and I wish you the best of luck with your future endeavours.
Hugo Leisink
31 January 2018, 01:41
I agree that it might very well be possible that there is a way to bypass it. But it's better than nothing. I'm sure you've read the following in the manual:
Don't use this as a generic security feature. Only use it to prevent a specific vulnerablility in an application that can't be taken offline while you wait for a patch.

The only purpose is to have a tool that might block a certain vulnerability. So, only use it to prevent an SQL injection in case of a vulnerability and after careful testing. But no matter what is communicated about this, there are always people to turn this feature on by default. Can't stop it.