Weblog

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.

The error code that Hiawatha returns is configurable. You can also send a 403 or a 404.

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?

You can have your own error messages via the ErrorXSLT setting. Use XSL commands to customize the error messages.

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.

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.

Did you set PreventSQLi to 'yes'?

Hi Hugo,

Where are the regular expression patterns in hiawatha, I would like to see these.

They can be found in src/session.c at line 35.

I installed with "yum install hiawatha", but I not find src/session.c.

For that, you need to download the source tarbal.

Ok, I made thats.. and It is ready, thanks

Did anyone bypass it by now?

No, so far no successful injection. A lot of attempts though.

Can we get a valid username (not uncommon in real-world applications)?

Sure. There is a user 'hugo' in the database.

Thanks, with the valid username I've bypassed it. Should I post here / PM / email you?

Hi Simon. I've already seen it in the logfiles. A fix for it will be available in the next release. Thanks!

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.

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:

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.

By passed with saying Query failed!
oK6SmD8p');select pg_sleep(9); --

No, you did not bypass it with that malformed query.