No Features? Think Again

If you hear that Hiawatha is a light-footed web server and immediately assume massively reduced functionality, you are thoroughly mistaken. The complicated rewriting of URLs that solutions like WordPress or Joomla often require is also supported by Hiawatha. The server uses the URL Toolkit, a custom Hiawatha component that bundles URL rewriting logic, for this purpose.

Therefore, Hiawatha is perfectly suited to running Web 2.0 applications like WordPress, and because the web server has a complete transport layer security (TLS) implementation, it can be done on an encrypted basis. Hiawatha also supports basic HTTP login with digest access or basic authentication, which is essential, for example, for accessing the admin interfaces of many web projects.

No Data Flooding

Other features from the security corner include the ability to set up connection throttling at the web server level, which involves specifying the permitted upload speed for individual clients. This feature prevents users from wrecking individual web server instances by saturating their lines with targeted, parallel, multiple uploads.

Of course, protection at the software level is not enough to protect servers against large-scale distributed denial of service (DDoS) attacks; instead, you have to start on the network level, but at least small attacks are reliably stopped by Hiawatha in this way. Built-in caching also enables the server to process incoming and outgoing requests faster and with lower resource consumption. Support for HTTP compression by Gzip, which Hiawatha has also been offering for a few years, is in the same vein.

Preventing XSS and CSRF Attacks

Cross-site scripting (XSS) is a classic attack vector for targeting web servers. The danger potentially exists wherever web applications handle user input. Attacks are usually launched by bots running automatically.

In XSS attacks, attackers, in simple terms, access the infrastructure behind the web server. To do so, they exploit vulnerabilities in the respective web applications that do not consistently prevent unauthorized access. For example, if a web solution has a search form for usernames that triggers a MySQL call in the background, a typical XSS attack would be to enter a MySQL command in the search form. This particular form of XSS attack is quite common, and even has its own name: SQL injection. If the software is not hardened against XSS attacks, it forwards the illegal command directly to the database, where it ends up being executed.

Cross-site request forgery (CSRF) works the other way around, wherein attackers exploit the rights of legitimately logged-in users or their browser sessions to send commands to web servers that the legitimate users do not want to send.

The problem with these and other similar types of attacks is that, for a long time, web servers have almost completely ignored this attack vector and declared themselves not responsible. Hiawatha has been a clear exception to this rule for a long time: The server has code that tries to detect XSS and CSRF attacks on the basis of various parameters and prevents them if ongoing HTTP(S) sessions meet the attack criteria.

The framework that tries to detect attacks does even more in Hiawatha: It not only watches out for the signs of XSS and CSRF, it also detects clients that produce high volumes of traffic in a short time or send unusual HTTP requests. The admin defines the individual parameters for the engine that detects attacks in the server's configuration file.