Security

This is where we'll be putting security tests, alerts, and advice for people running Mongrel. We test Mongrel fairly heavily using the following techniques:

• Unit testing what I can. Mongrel is a server so many tests have to be done "live".
• Thrashing Mongrel's HTTP parser internally with random or near-random data (called fuzzing).
• Using "Peach Fuzz":http://peachfuzz.sourceforge.net/ to thrash several live apps with randomness.
• Running several extensive little scripts to explore the edges of death for Mongrel.
• Heavy code audits covering as much code as possible to find any possible loose ends.

The end result is a lot of little fixes which make Mongrel more robust against badly behaving clients and possibly against many potential security risks in the future.

Mongrel's HTTP Restrictions

Many of the exploits out there currently for web servers tend to exploit either ambiguous areas of the HTTP grammar, or the lack of size specifications in the protocol. To protect against this Mongrel uses a fairly strict parser, but since many browser authors don't read specifications (and hell, who'd want to read the mountain of HTTP specifications out there), it can't be too strict. What it does enforce (apart from well formed headers and request lines) is the following size restrictions on each part:

• Any header over 112k.
• Any query string over 10k.
• Any header field value over 80k.
• Any header field name over 256 bytes.
• Any request URI greater than 512 bytes.

The large header size and field value is due to cookies being allowed to be so massive. It's not too clear whether a browser is allowed to cram all 20 of the 4k cookies into one cookie header, or if it should use multiple, but the end result is that a web server has to parser at least 112k of garbage before it can declare a client malicious.

Now, when we say Mongrel is strict, we don't mean that it will abort on any minor little error according to the HTTP 1.1 RFC. Mongrel's parser is pretty forgiving on formats. Where Mongrel is exact is (as mentioned before) in it's treatment of sizes and boundary characters. Clients that can't even get that right aren't following the most basic safety elements of HTTP and you probably shouldn't deal with them.

Quiet Things Happens To Bad People

Rather than wasting any more time--and in order to not give out any information to potentially malicious attackers--Mongrel just closes the socket immediately. This may confuse good people, but it's the best way to deal with bad requests.

The assumption is that either the requesting client is not functioning correctly or it's attempting an attack. If it's not functioning correctly then what's the point of sending back any results? It probably can't parse them anyway. If it's an attacker then why give them any more information?

Caught in the middle are people who are using a poorly written client. We'd suggest in those cases that they report the problem to the client's authors or contact us to see if it's an error on Mongrel's part.

Reporting Security Problems

If you think you've found a security problem with Mongrel, please report it to the list right away at http://rubyforge.org/mailman/listinfo/mongrel-users. We're usually very responsive and will probably help even if the security problem is outside of Mongrel or if you need help securing your system.