diff options
Diffstat (limited to 'site/src/docs/security.page')
| -rw-r--r-- | site/src/docs/security.page | 94 |
1 files changed, 0 insertions, 94 deletions
diff --git a/site/src/docs/security.page b/site/src/docs/security.page deleted file mode 100644 index 2781b12..0000000 --- a/site/src/docs/security.page +++ /dev/null @@ -1,94 +0,0 @@ ---- -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. - |