[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [WEB SECURITY] HTTP error codes blocking



------_=_NextPart_001_01C5A1C7.5EE06103
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

So, the problem is with ErrorDocument you can specify the returned
content, but not the returned status code.  It looks like even if I do
something like this:
=20
ErrorDocument 404 /pages/found.html
=20
I still get a 404 status code in the header (even though now I am going
to get some "valid" content).  Which points out your problem I guess.
=20
Additionally, looking at the docs (at least for Apache 2.0) [
http://httpd.apache.org/docs/2.0/mod/core.html#errordocument ] we can
see this note:
=20
"Although most error messages can be overriden, there are certain
circumstances where the internal messages are used regardless of the
setting of ErrorDocument
<http://httpd.apache.org/docs/2.0/mod/core.html#errordocument> . In
particular, if a malformed request is detected, normal request
processing will be immediately halted and the internal error message
returned. This is necessary to guard against security problems caused by
bad requests."
=20
So ErrorDocument might not even be catching the things you want to guard
against!
=20
Your ErrorDocument's can be CGI scripts, of course.  See
http://httpd.apache.org/docs/2.0/custom-error.html to see the headers
that would get passed into the script to help in crafting appropriate
dynamic responses.  I *think* this might let you rewrite the headers,
although I don't have the time just now to whip up an example and give
that a try.  Doing this, you might be able to map all the behaviors of
interest into a single generic response that would fool attackers.
=20
Another option is some sort of proxy in front of the web server maybe
(that catches stuff ErrorDocument will not handle, as shown above).  Oh,
and make it an Apache proxy so you don't introduce those darn
vulnerabilities where Proxy + Server have different behaviors for "bad"
requests :-).  Anyway, a rewriting proxy could probably do what you want
-- intercept the status code of interest and "fix" them.
=20
This may very well be a fool's errand, however - too easy to miss
something that still gives away the actual server you are running.  I'd
be leery of breaking "correct" behavior too.  But if you can figure it
out, I'm sure we'd all be interested in hearing about it.

	-----Original Message-----
	From: joe shmoe [mailto:joeshmoepeter@yahoo.co.in]=20
	Sent: Monday, August 15, 2005 2:01 PM
	To: Paul Schmehl; websecurity@webappsec.org
	Subject: Re: [WEB SECURITY] HTTP error codes blocking
=09
=09
	I am indeed using the apache's errorDocument feature. The
subject I was trying to solicit comments on was this:
	(i) I want to customize not just the content of the error page
thrown to the user ("Dear user, foobar"), but the entire HTTP message --
pls note that the focus here is to defend against/confuse attackers and
scanners. What kind of status codes can I configure for specific errors
such that the attacker cannot fingerprint my server to be apache, IIS
etc.=20
	=20
	Each of these servers return different error codes for different
kind of malformed requests. For ex: For GET HTTP/3.0, Apache returns 400
Bad Request, IIS returns 200 OK and Netscape returns 505 Version not
supported. How can I prevent such fingerprinting?
	=20
	As an aside, can I configure the *headers and response codes* in
Apache via the errorDocument or some other utility? As I mentioned
above, its not just the body that I want to customize, but the entire
status line as well as the headers. Do the commercial webservers provide
such functionality?
	=20
	Thanks!
	Joseph
=09
	Paul Schmehl <pauls@utdallas.edu> wrote:

		My thoughts exactly. Why reinvent the wheel?
	=09
		--On Friday, August 12, 2005 21:40:39 +0200 Dusan Juhas=20
		wrote:
	=09
		>
http://httpd.apache.org/docs/2.0/mod/core.html#errordocument
		>
		> < Hello,
		> < Could anyone englighten on the best way to block
HTTP error codes to
		> avoid < potential fingerprinting by an attacker?
		> <
		> < Would I breaking the protocol if I send a 200 OK
with a blank page
		> instead of < say 404? What is the industry standard?
Or the approach
		> followed by smart < sysadmins?
		>
		>
---------------------------------------------------------------------
		> The Web Security Mailing List
		> http://www.webappsec.org/lists/websecurity/
		>
		> The Web Security Mailing List Archives
		> http://www.webappsec.org/lists/websecurity/archive/
		>
	=09
	=09
	=09
		Paul Schmehl (pauls@utdallas.edu)
		Adjunct Information Security Officer
		University of Texas at Dallas
		AVIEN Founding Member
		http://www.utdallas.edu/ir/security/
	=09
=09
---------------------------------------------------------------------
		The Web Security Mailing List
		http://www.webappsec.org/lists/websecurity/
	=09
		The Web Security Mailing List Archives
		http://www.webappsec.org/lists/websecurity/archive/
	=09
	=09

=09
  _____ =20

	Check out Yahoo! India Rakhi Special for Rakhi shopping,
contests and lots more.=20
	http://in.promos.yahoo.com/rakhi/index.html=20


------_=_NextPart_001_01C5A1C7.5EE06103
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2>So,=20
the problem is with ErrorDocument you can specify the returned content, =
but not=20
the returned status code.&nbsp; It looks like even if I do something =
like=20
this:</FONT></SPAN></DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =

size=3D2>ErrorDocument 404 /pages/found.html</FONT></SPAN></DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
still get a 404 status code in the header (even though now I am going to =
get=20
some "valid" content).&nbsp; Which points out your problem I=20
guess.</FONT></SPAN></DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =

size=3D2>Additionally, looking at the docs <SPAN =
class=3D974021118-15082005><FONT=20
face=3DArial color=3D#0000ff size=3D2>(at least for Apache 2.0) [ <A=20
href=3D"http://httpd.apache.org/docs/2.0/mod/core.html#errordocument";>htt=
p://httpd.apache.org/docs/2.0/mod/core.html#errordocument</A>&nbsp;]=20
we can see this note:</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D974021118-15082005></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial =
color=3D#0000ff><SPAN=20
class=3D974021118-15082005><!--StartFragment --><FONT face=3D"Times New =
Roman"=20
color=3D#000000>"Although most error messages can be overriden, there =
are certain=20
circumstances where the internal messages are used regardless of the =
setting of=20
</FONT><CODE class=3Ddirective><A=20
href=3D"http://httpd.apache.org/docs/2.0/mod/core.html#errordocument";>Err=
orDocument</A></CODE><FONT=20
face=3D"Times New Roman" color=3D#000000>. In particular, if a malformed =
request is=20
detected, normal request processing will be immediately halted and the =
internal=20
error message returned. This is necessary to guard against security =
problems=20
caused by bad requests."</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3D"Times New Roman"=20
color=3D#000000><SPAN =
class=3D974021118-15082005></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D974021118-15082005>So ErrorDocument might not even be catching =
the things=20
you want to guard against!</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D974021118-15082005></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D974021118-15082005>Your ErrorDocument's can be CGI scripts, of=20
course.&nbsp; See <A=20
href=3D"http://httpd.apache.org/docs/2.0/custom-error.html";>http://httpd.=
apache.org/docs/2.0/custom-error.html</A>&nbsp;to=20
see the headers that would get passed into the script to help in =
crafting=20
appropriate dynamic responses.&nbsp; I *think* this might let you =
rewrite the=20
headers, although I don't have the time just now to whip up an example =
and give=20
that a try.&nbsp; Doing this, you might be able to map all the behaviors =
of=20
interest into a single generic response that would fool=20
attackers.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D974021118-15082005></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D974021118-15082005>Another option is some sort of proxy in front =
of the=20
web server maybe (that catches stuff ErrorDocument will not handle, as =
shown=20
above).&nbsp; Oh, and make it an Apache proxy so you don't introduce =
those darn=20
vulnerabilities where Proxy + Server have different behaviors for "bad" =
requests=20
:-).&nbsp; Anyway, a rewriting proxy could probably do what you want --=20
intercept the status code of interest and "fix" =
them.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D974021118-15082005></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D974021118-15082005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D974021118-15082005>This may very well be a fool's errand, =
however - too=20
easy to miss something that still gives away the actual server you are=20
running.&nbsp; I'd be leery of breaking "correct" behavior too.&nbsp; =
But if you=20
can figure it out, I'm sure we'd all be interested in hearing about=20
it.</SPAN></FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> joe =
shmoe=20
  [mailto:joeshmoepeter@yahoo.co.in] <BR><B>Sent:</B> Monday, August 15, =
2005=20
  2:01 PM<BR><B>To:</B> Paul Schmehl;=20
  websecurity@webappsec.org<BR><B>Subject:</B> Re: [WEB SECURITY] HTTP =
error=20
  codes blocking<BR><BR></FONT></DIV>
  <DIV>I am indeed using the apache's errorDocument feature. =
The&nbsp;subject I=20
  was trying to solicit comments on was this:</DIV>
  <DIV>(i) I want to customize not just the content of the error page =
thrown to=20
  the user ("Dear user, foobar"), but the entire HTTP message -- pls =
note that=20
  the focus here is to defend against/confuse attackers and scanners. =
What kind=20
  of status codes can I configure for specific errors such that the =
attacker=20
  cannot fingerprint my server to be apache, IIS etc. </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Each of these servers return different error codes for different =
kind of=20
  malformed requests. For ex: For GET HTTP/3.0, Apache returns 400 Bad =
Request,=20
  IIS returns 200 OK and Netscape returns 505 Version not supported. How =
can I=20
  prevent such fingerprinting?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>As an aside, can I configure the *headers and response codes* in =
Apache=20
  via the errorDocument or some other utility? As I mentioned above, its =
not=20
  just the body that I want to customize, but the entire status line as =
well as=20
  the headers. Do the commercial webservers provide such =
functionality?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Thanks!</DIV>
  <DIV>Joseph<BR><BR><B><I>Paul Schmehl =
&lt;pauls@utdallas.edu&gt;</I></B>=20
  wrote:</DIV>
  <BLOCKQUOTE class=3Dreplbq=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px =
solid">My=20
    thoughts exactly. Why reinvent the wheel?<BR><BR>--On Friday, August =
12,=20
    2005 21:40:39 +0200 Dusan Juhas =
<DNC@SEZNAM.CZ><BR>wrote:<BR><BR>&gt;=20
    =
http://httpd.apache.org/docs/2.0/mod/core.html#errordocument<BR>&gt;<BR>&=
gt;=20
    &lt; Hello,<BR>&gt; &lt; Could anyone englighten on the best way to =
block=20
    HTTP error codes to<BR>&gt; avoid &lt; potential fingerprinting by =
an=20
    attacker?<BR>&gt; &lt;<BR>&gt; &lt; Would I breaking the protocol if =
I send=20
    a 200 OK with a blank page<BR>&gt; instead of &lt; say 404? What is =
the=20
    industry standard? Or the approach<BR>&gt; followed by smart &lt;=20
    sysadmins?<BR>&gt;<BR>&gt;=20
    =
---------------------------------------------------------------------<BR>=
&gt;=20
    The Web Security Mailing List<BR>&gt;=20
    http://www.webappsec.org/lists/websecurity/<BR>&gt;<BR>&gt; The Web =
Security=20
    Mailing List Archives<BR>&gt;=20
    =
http://www.webappsec.org/lists/websecurity/archive/<BR>&gt;<BR><BR><BR><B=
R>Paul=20
    Schmehl (pauls@utdallas.edu)<BR>Adjunct Information Security=20
    Officer<BR>University of Texas at Dallas<BR>AVIEN Founding=20
    =
Member<BR>http://www.utdallas.edu/ir/security/<BR><BR>-------------------=
--------------------------------------------------<BR>The=20
    Web Security Mailing=20
    List<BR>http://www.webappsec.org/lists/websecurity/<BR><BR>The Web =
Security=20
    Mailing List=20
    =
Archives<BR>http://www.webappsec.org/lists/websecurity/archive/<BR><BR></=
BLOCKQUOTE>
  <P>
  <HR SIZE=3D1>
  Check out Yahoo! India Rakhi Special for Rakhi shopping, contests and =
lots=20
  more. <BR>http://in.promos.yahoo.com/rakhi/index.html=20
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5A1C7.5EE06103--



Brought to you by http://www.webappsec.org
Search this site