Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: Dropping connection instead of returning 400

Subject: RE: Dropping connection instead of returning 400
Date: Tue, 19 Apr 2005 22:16:05 -0400
Sounds like a good idea to me, but of course what are the dependencies
on returning a proper 400 ?  Could break things down the road. 

Instead of sending a RST, may want to consider just dropping the
connection altogether as well.  I'm a big fan of just hanging the
connect, instead of resetting . Just adds another layer of pain
(althought admittedly slight)  to whomever's perputrating the fraud.

-----Original Message-----
From: Kanatoko [mailto:anvil@jumperz.net] 
Sent: Monday, April 18, 2005 5:29 AM
To: webappsec@securityfocus.com
Subject: Re: Dropping connection instead of returning 400 

 
On Tue, 1 Mar 2005 20:59:37 -0800 (PST)
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.

Google web server (GWS) works just like that.

If you send an invalid HTTP request like this to Google,
--
GET / AAAA/1.0
User-Agent: hoge
Host: www.google.com

--

GWS drops the TCP connection with RST packet.
On the other hand, Apache and IIS return a 400 response.

BTW, I got this information from the book "Intrusion 
Prevention and Active Response" page 137.
http://www.amazon.com/exec/obidos/tg/detail/-/193226647X/

--
Kanatoko<anvil@jumperz.net>
Open Source WebAppFirewall
http://guardian.jumperz.net/


<Prev in Thread] Current Thread [Next in Thread>