Forum

Hi,

Hiawatha gives me strange 403 errors with phpMyAdmin.

To reproduce this error:
- open any database
- go to SQL tab
- execute any query, longer than one line, for example:
SELECT * FROM table
WHERE field = 1
You have to press enter in the input box to separate the lines
- Under "Query result operations" click on "Print view"

As you can notice, the weblink has substantially changed, and now it
contains the whole SQL query. If the query contains %0D%0A characters,
hiawatha gives me 403 error.

It looks like this in access.log:

192.168.1.10|Wed 21 Apr 2010 15:00:26 +0200|403|576||GET /dbadmin/sql.php?db=firewall&table=blacklist&printview=1&sql_query=SELECT+%2A+FROM+%60blacklist%60+%0D%0AWHERE+id+%3D+10&token=b14d53f3dc09ded598ef32e0853577c4 HTTP/1.1|Host: localhost|User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19) Gecko/2010040119 Ubuntu/8.04 (hardy) Firefox/3.0.19|Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8|Accept-Language: en,de;q=0.8,sk;q=0.5,en-us;q=0.3|Accept-Encoding: gzip,deflate|Accept-Charset: UTF-8,*|Keep-Alive: 300|Connection: keep-alive|Referer: http://localhost/dbadmin/import.php

For now I solved it by adding these lines to the URL toolkit:

  Match %0D Rewrite %20 20 Continue
  Match %0A Rewrite %20 20 Continue

This is a lame workaround, do you have an idea, how to solve this?
Can I change something in the configuration to make it work?


tested on:
Hiawatha version: 7.0, 7.1

OS: Debian lenny
phpMyAdmin 2.11.8.1deb5+lenny3

OS: Debian squeeze
phpMyAdmin 3.3.1deb1

In many cases, such characters in an URL indicate someone is trying nasty things on your website / webserver. Therefor, Hiawatha does not allow characters with ASCII value below 32 in an URL. You can overrule this behaviour with the following 'hidden' setting:

VirtualHost {
    ...
    SecureURL = no
}

I don't agree with you that your solution is lame. It's simple and secure.
I think I'm going to use it to make a toolkit rule for the HOWTO page. Thanks

Thank you,

SecureURL was exactly what I was hoping for

URLToolkit Rewrite solution may be more secure, allowing %0D, %0A, and %09 only. However, my colleagues pretty soon managed to copypaste some SQL query, which contained way over twenty lines and even more %09 's (tabs).

Would it be possible to allow unlimited <max_loop> in the Rewrite rule? Like '0' or '*' character for infinite rewrites?
Ability to surely rewrite all found strings would make this solution less lame

Unlimited max_loop is dangerous, because it could place the rewrite process in an endless loop and hang the server.

Instead of SecureURL = no, you can also try this rewrite.

Match %[01][0-9a-fA-F] Rewrite %20 20

This works, if the total amount of matches being replaced doesn't exceed 20, right? After then I get 403 anyway.
I could add more lines like

Match %09 Rewrite %20 20 Continue
Match %09 Rewrite %20 20 Continue
...

to be sure that all crazy long SQL queries will be repaired correctly. For now I will stick to SecureURL = no.

I'm used to do global substitutions, like:

echo "foo%0D%0Abar%0D%0A" | sed 's/%[01][0-1a-fA-F]/%20/g'

It's probably hard to implement, but never ends in endless loop. Actually, it may be the best solution to pipe the URL to the external program like sed or perl for processing. That means less work for you, implementing advanced regex in Match/Rewrite
Maybe something like

ProcessURL <command> [Continue|Return]
ProcessURL sed 's/%[01][0-1a-fA-F]/%20/g'

---
Note: after months of testing, we finally moved away from Apache to Hiawatha. On all our servers.
Thank you for making and maintaining the world's best webserver

Cool. Any high profile website you've got running which I can mention on my website as promo?

To answer your question, I've sent you an email. I hope that's OK.