Forum

Is it possible to get file upload to work with PreventSQLi = yes? I can't really figure it out. Another related question is if it is possible to get some more info on why the client was banned. The only thing I can find in the logs are that the client tried some sql injection but nothing of what triggered the banning.

Hiawatha version: 7.5
Operating System: Ubuntu 11.04

I've rewritten the SQL injection prevention routine in version 7.6. It no longer corrupts file uploads, so upgrading to 7.6 should fix your problem.

If a client is banned, Hiawatha writes the reason to the system logfile (/var/log/hiawatha/system.log).

Thanks for your quick response! I have checked the log and the only thing that I found is "Client banned because of SQL injection". The problem is that I sometimes can't figure out why I get banned. Is there a way t get some kind of hint of which violation of the rules I have committed. For instance if I get an attacker who tries to use sql injections I would like to know where and how.

At line 37 in session.c you can see what patterns Hiawatha will look for when detecting SQL injection. Hiawatha logs all exploit attempts to /var/log/hiawatha/exploit.log (or wherever your log directory is located).

I cant still figure out why this postdata gives me an atemted sql-injection.

Content-Type: multipart/form-data;
boundary=---------------------------10514163711109948684621388072
Content-Length: 686
-----------------------------10514163711109948684621388072
Content-Disposition: form-data;
name="post"
fgdsg
-----------------------------10514163711109948684621388072
Content-Disposition: form-data; 
name="bild";
filename=""
Content-Type: application/octet-stream
-----------------------------10514163711109948684621388072
Content-Disposition: form-data;
name="bildtext"
gsdfg
-----------------------------10514163711109948684621388072
Content-Disposition: form-data;
name="topic_id"
313
-----------------------------10514163711109948684621388072
Content-Disposition: form-data;
name="country"
se
-----------------------------10514163711109948684621388072--

It turns out that a form ellement with enctype set to MULTIPART/FORM-DATA triggers the sql-injection protection but multipart/form-data not. I have no clue why but It might help someone else.

Try changing line 39 in session.c to

    {"[\\s'0-9a-z]\\s*--\\s+.+"},

It would be great if one could get the part of the that causes the trouble highlighted in the logs in some way. It would be so much easier to analyze false positives that way. At least for people like me that are not so well versed in regex.

Because there are a lot of different ways to perform a SQL injection, they only sensible way to detect it is by using regular expressions. And because regular expressions works by matching a string with a pattern, it's not easy to say where the actual SQL injection is in the string.

What you should do is learn what there is to learn about SQL injection (it ain't rocket science) and I'm sure you will have no problem in finding the false positives.

This form data works fine when using post but when using enctype="multipart/form-data" Hiawata responds with 409.

facebook
forum_category_id 4
group_id 291
group_image login2.jpg
group_manager_2 0
group_manager_3 0
group_name Sylt från stan
group_presentation fgfd
group_rss
group_twitter
linkedin
profiling_until 2012-11-10
url

Do you have any reason to believe that your application is vulnerable for SQL injection? If not, don't use the PreventSQLi option.

Unfortunately I know it is vulnerable. I have not done most of the coding myself so it is a pretty crappy situation. To secure the application is a pretty big job which is probably both out of time and budget so I'm kind of caught between a rock and a hard place.

Can you send me a dump of the POST request that is causing problems? If you don't want to post it here, send it to hugo@hiawatha-webserver.org.