diff options
Diffstat (limited to 'site/src/docs/security.page')
| -rw-r--r-- | site/src/docs/security.page | 94 |
1 files changed, 94 insertions, 0 deletions
diff --git a/site/src/docs/security.page b/site/src/docs/security.page new file mode 100644 index 0000000..2781b12 --- /dev/null +++ b/site/src/docs/security.page @@ -0,0 +1,94 @@ +--- +title: Security +inMenu: true +directoryName: Security +--- + +h1. Web Application Security Issues + +Mongrel takes a different approach to security than most web servers. Rather than +relying on massive human efforts to audit all possible code, Mongrel is implemented +using algorithms and methods that are difficult to subvert. There is still auditing +and checks, but Mongrel simply tries to avoid errors by not doing things that cause them. + +Read the "Iron Mongrel Security page":/security.html for information on how security +is done in Mongrel. The main points to remember with Mongrel's security are: + +* Mongrel uses a "Ragel":http://www.cs.queensu.ca/home/thurston/ragel/ generated parser +instead of a hand coded HTTP handler. The grammar is very close to the ABNF specification, so +if you see "BAD CLIENT" errors in your logs, that probably is a bad client. +* Security tests have found that Mongrel stops most security attacks at the protocol level due to +it's correctly written parser *and* it's explicit limits on the sizes of everything. +* The Mongrel reaction to a protocol violation is to close the socket immediately. It doesn't waste +time and resources on bad clients since this is *always* a hack attempt. If it isn't then it's a +poorly written client and the author should learn to write a correct one. +* Mongrel works with all the main clients out there, and ones it doesn't work with are crap living +in a tiny tiny niche of the internet designed by horrible programmers. +* While Mongrel is more strict than other servers, it isn't draconian. The clients that can't get +through are typically skating on the edge of the HTTP grammar where they do not belong. + +Mongrel isn't infallible, but if Mongrel complains about something then you should investigate it. +If you think Mongrel is wrong then shoot a message to the mailing list detailing what it should do +and we'll consider adjusting the grammar. If you think Mongrel should violate the grammar so that +your little WebDAV++ Social Network Bookmark Chat Web 2.0 monstrosity can see the light of day, then +you "should write your own web server":/not_mongrel.html instead. + +h2. Learning About Web Application Security + +You should read the "OWASP":http://www.owasp.org/index.php/Main_Page document +"Top Ten Project":http://www.owasp.org/index.php/OWASP_Top_Ten_Project for information on +the big security risks and how to avoid them. The summary of these is: + +* Unvalidated Input +* Broken Access Control +* Broken Authentication And Session Management +* Cross Site Scripting +* Buffer Overflow +* Injection Flaws +* Improper Error Handling +* Insecure Storage +* Application Denial Of Service +* Insecure Configuration Management + +Many of these errors depend on how you write your application and have little to do with Mongrel. +The two that relate the most to Mongrel are *Buffer Overflows* and *Application Denial of Service*. + + +h2. Buffer Overflows + +Mongrel is doing some heavy C buffer thrashing internally, but several controls are in place to make +sure that things stay safe: + +* Pointers are checked with asserts and if statements to test if there's been a buffer overflow. +* Ragel generates a safe state machine that is accurate to the byte level. +* There are none of the "unsafe" string handling functions except for where absolutely necessary, and +that one spot is checked heavily. +* Input is limited to maximum sizes--which also helps prevent denial of service. + + +h2. Application Denial of Service + +Normally this is things like using algorithms in your application that make it easy for +someone to take down your application with simple queries. A good example is a SQL database +query that when given the right inputs takes forever. It only takes a few of these to +destroy your application's response time. + +Mongrel helps with Denial of Service by doing the following things: + +* Mongrel strict parser boots clients immediately to save on resources and time. +* Mongrel boots clients that go over the (generous) size limits for input. +* When Mongrel gets overloaded it starts denying clients and then finds existing +requests that are taking to long and kills them. It is pretty conservative about this, but +you can use options to tune it more or less severe. +* Mongrel is already using pure HTTP so there's plenty of tools available to help you. +* It's designed to be as efficient as possible, but this has limits because of Ruby. + +Don't count on Mongrel to suddenly make your Rails application withstand a Russian +DOS blackmail operation though. It works hard to prevent DOS potential, but there's only +so much it can do. + +If you're very serious about security then you should check out "mod_security":http://www.modsecurity.org/ +which is an Apache module that has lots of active prevention of such things. It can stop many web +scanner attacks, DOS attempts, and other security attempts. It does slow your server down, but it's +probably worth it if you have something valuable. + |