WebApp Sec mailing list archives

Re: Dropping connection instead of returning 400


From: Mariusz Pękala <skoot () qi pl>
Date: Thu, 3 Mar 2005 23:20:56 +0100

On 2005-03-01 20:59:37 -0800 (Tue, Mar), christopher () baus net wrote:
One thing that keeps coming back to me is 400 Bad Request handling.  It is
now my opinion that security proxies should just drop connection when
faced with traffic they refuse to handle.

I put some thoughts on this on my blog here:

http://www.baus.net/400-bad-request

Which cause one client developer to call me a non-compliant wanker here:

http://www.mackmo.com/nick/blog/java/?permalink=Please_send_400_Bad_Request_and_.txt

I then followed up with the general thought that I'm willing to be
non-compliant in the name of security:

http://www.baus.net/breaking-the-spec-in-the-name-of-security

So what do you think?  Is security worth non-compliance with the HTTP spec?

I humbly believe that it's not good to 'drop connection' instead of
returning 400.
What would I do when connection dies after I send my request?
I would retry. If it dies again I retry wondering 'What the ...?'

It may be good to limit the response to something really short, but
there should be SOME response.

As a more 'general' answer to the question whether security is worth
non-compliance I would say: NO, it is not.
The standards are something that gives us confidence in the world. ;-)

To be secure ensure that your program can catch bad request. If it does,
why wouldn't you tell them back: "I am secure! Your request was bad.
Don't waste your time trying to crack me!"


-- 
$ ls -lart
/bin/ls: you must be root to use LART

Attachment: _bin
Description:


Current thread: