Hiawatha webserver

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% ... [More] 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. Update: 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. [Less]

New versions of the Hiawatha webserver and the Hiawatha Monitor have been released. Hiawatha now supports chunked encoded requests and logfile rotation. Several bugs were fixed, included a few found via Coverity. I've added access rights per ... [More] webserver and support for CGI errors to the Hiawatha Monitor. The server statistics have been replaced by two graphs for connection count and bad requests. [Less]

I read an interesting article at Slashdot about HTTP/2. As you can read in earlier posts, I don't like SPDY. It's a protocol by Google, for Google. Unless you are doing the same as Google, you won't benefit much from it. The main reason SPDY was ... [More] taken as a base for HTTP/2 is because the W3C was too indolent to do its job. Many things that are wrong with HTTP/1.x are not solved in HTTP/2. Specially all the things that make a webserver unnecessarily complex. For example, the feature called pathinfo. URL's are still ugly and it requires the webserver to search for the actual CGI script. A better solution is URL rewriting, but using regular expressions for it is also not very efficient. Many CMS's and frameworks require a long list of rewrite rules while they should all be replaced with three simple rules: If the file exists, serve it. Does the URL start with a specific part, for example /images, /css or /js, then return a 404. Use a specific URL instead, like /index.php, /default.aspx or /index.py. These simple rules allow you to use clean URL's and are very easy and fast to implement. I know HTTP was meant to be stateless, but all webbrowsers use a separate connection for every website. Even if those websites are served by the same webserver. Therefor, a lot of the same HTTP headers are sent over and over again. This can be improved. Also, why send a separate request for every file? Why not let the browser specify a list of files which the server can then send in one stream? We have CGI, FastCGI, SCGI, WSGI, etc, all doing the same thing. Why not choose one as standard and drop the others? Take a look at all the modules available for Apache. The amount of crap that many web developers want to put in their web application are not going to be fixed by SPDY. The only reason Hiawatha offers reverse proxy functionality is because several web application developers thought it was a good idea to make their application speak HTTP instead of (Fast)CGI and users wanted to run that shit with Hiawatha. You want things to be faster? Start by making things more simple. Anyway, I think we don't need a new protocol like SPDY. What we need is HTTP/1.2 in which the unnecessary junk is removed, the gaps are filled and things are made more easy. [Less]

New versions of the Hiawatha webserver and the Hiawatha Monitor have been released. The Monitor has had some major changes. The support for request monitoring has been removed and support for CGI statistics has been added. Of course, Hiawatha has ... [More] been changed for that as well. Other new things in Hiawatha are the EnforceFirstHostname option, which allows you to enforce the usage of a certain hostname for a virtual host, and the ScriptAlias, which does what it says. :) [Less]