RE: [WEB SECURITY] Bypassing URL Authentication and Authorization with HTTP Verb Tampering

["Arshan Dabirsiaghi" <arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx>]

------_=_NextPart_001_01C8C18A.17698CA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Martin,
=20
Not sure how you can question whether or not I know the RFC when I cite =
the RFC multiple times in the paper - of course HEAD is GET. There's no =
other way to ensure the similarity between HEAD response headers and GET =
response headers. Here's a snippet from the paper:
=20
> The HTTP specification, RFC 2616 [1], specifies that HEAD requests =
should produce the same results as=20
> a GET request but with no response body.
=20
It's not that we expect anything else from HEAD, indeed it's doing =
exactly as the spec says - we're just alerting most people to its =
usefulness to attackers to access non-idempotent GETs behind URL =
authorization schemes. That is the fact that, which you may still not =
believe, is not well known. Of course that's just half the story, the =
other half is the vendor craziness when dealing with arbitrary HTTP =
verbs.
=20
> Ooop; a bit defensive there.  I was commenting based on the content in
> the blog, which is primarily written by you.
=20
Of course, but being arbitrary about labeling those things that you =
don't know are claims amounts to the same insinuation. I'll try not to =
take offense in the future, but it's hard - I can't share this with =
everybody or someone will leak it and steal credit. On the other hand, =
we do a lot of research and ask some people in the field we consider =
extremely knowledgeable if they know of any prior art. They tell us no, =
it's great and to move on it, and we still get 2 people calling it =
"obvious". C'est la vie, after thinking about it, having 2 non-positive =
feedbacks compared to the numerous positive responses we've gotten is =
not so bad at all.
=20
Incidentally I browsed around for a few hours during our research to see =
what, if any HEAD requests were issued by the browser. The only thing =
that evoked anything other than GET or POST was OWA (WebDAV verbs). Has =
anyone evaluated what, if anything, would break if HEAD suddenly went =
away?
=20
What is more reasonable action, from this point forward? Run into these =
URL authorization mistakes constantly from here on out, or turn off HEAD =
and deal with the consequences?
=20
Cheers,
Arshan
=20

________________________________

From: Martin O'Neal [mailto:martin.oneal@corsaire.com]
Sent: Thu 5/29/2008 8:19 AM
To: Arshan Dabirsiaghi; websecurity@webappsec.org
Subject: RE: [WEB SECURITY] Bypassing URL Authentication and =
Authorization with HTTP Verb Tampering




> It is obvious after reading the paper, isn't it?

You are having a laugh, no?  RFC2616: "The HEAD method is identical to
GET except that the server MUST NOT return a message-body in the
response".  And your expectation of how this would be otherwise
implemented in a server other than a wrapper for GET?  Wasteful,
unmanageable, duplicate code?

> The journalist's assassin word: "claim" - always
> used to install doubt without having actually
> doing any follow up.

Ooop; a bit defensive there.  I was commenting based on the content in
the blog, which is primarily written by you.  I haven't spoken to any of
the chaps listed, so logically whether they did or didn't know is
unsubstantiated (this isn't a personal attack on your integrity, it is
an auditors approach to life; if I can't validate it, then it is chalked
up as conjecture until I can).  So in context, the use of "claimed" is
both accurate and appropriate.  Like 9 out of 10 cat owners will know.

> Did you read the paper?

Yes and watched the clip too.

> The HEAD-redirect-to-GET and arbitrary verbs being forwarded to GET
handler are the unique takeaways.

You're not getting this are you?  HEAD *is* GET, just without the body.
It is by design!  I'm not sure how or why you would expect something
else!

Martin...






----------------------------------------------------------------------
CONFIDENTIALITY:  This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited.  If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.
----------------------------------------------------------------------
DISCLAIMER:  Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.
----------------------------------------------------------------------
Corsaire Limited, registered in England No. 3338312. Registered
office: Portland House, Park Street, Bagshot, Surrey GU19 5PG.
Telephone: +44 (0)1483-746700




------_=_NextPart_001_01C8C18A.17698CA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: [WEB SECURITY] Bypassing URL =
Authentication and Authorization with HTTP Verb Tampering</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16640" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText31611 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Martin,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Not sure how =
you can question whether or not I know the RFC when I cite the RFC =
multiple times in the&nbsp;paper - o</FONT><FONT face=3DArial =
color=3D#000000 size=3D2>f course HEAD is GET. There's no other =
way&nbsp;to ensure the&nbsp;similarity between HEAD&nbsp;response =
headers and GET response headers. Here's a snippet from the =
paper:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&gt; The HTTP specification, =
RFC 2616 [1], specifies that HEAD requests should produce the same =
results as </FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&gt; a GET request but with =
no response body.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>It's not that we expect =
anything else from HEAD,&nbsp;indeed it's doing exactly as the spec =
says&nbsp;- we're just alerting most people to its usefulness =
to&nbsp;attackers to access non-idempotent GETs behind URL authorization =
schemes. That is the fact that, which you may still not believe, is not =
well known. Of course that's just half the story, the other half is the =
vendor craziness when dealing with arbitrary HTTP verbs.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>&gt; Ooop; a bit defensive there.&nbsp; I =
was commenting based on the content in<BR>&gt; the blog, which is =
primarily written by you.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Of course, but being =
arbitrary about labeling those things that you don't know are claims =
amounts to the same insinuation. I'll try not to take offense in the =
future, but it's hard - I can't share this with everybody or someone =
will leak it and steal credit. On the other hand, we do a lot of =
research and ask some people in the field we consider extremely =
knowledgeable if they know of any prior art. They tell us no, it's great =
and to move on it, and we still get&nbsp;2 people&nbsp;calling it =
"obvious". C'est la vie, after thinking about it, having 2 non-positive =
feedbacks compared to the numerous positive responses we've gotten is =
not so bad at all.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Incidentally I browsed around =
for a few hours during our research to see what, if any HEAD requests =
were issued by the browser. The only thing that evoked anything other =
than GET or POST was OWA (WebDAV verbs). Has anyone evaluated what, if =
anything, would break if HEAD suddenly went away?</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>What is more reasonable =
action, from this point forward? R</FONT><FONT face=3DArial size=3D2>un =
into these URL authorization mistakes constantly from here on out, or =
</FONT><FONT face=3DArial size=3D2>turn off HEAD and deal with the =
consequences?</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Cheers,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Arshan</FONT></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Martin O'Neal =
[mailto:martin.oneal@corsaire.com]<BR><B>Sent:</B> Thu 5/29/2008 8:19 =
AM<BR><B>To:</B> Arshan Dabirsiaghi; =
websecurity@webappsec.org<BR><B>Subject:</B> RE: [WEB SECURITY] =
Bypassing URL Authentication and Authorization with HTTP Verb =
Tampering<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>&gt; It is obvious after reading the paper, isn't =
it?<BR><BR>You are having a laugh, no?&nbsp; RFC2616: "The HEAD method =
is identical to<BR>GET except that the server MUST NOT return a =
message-body in the<BR>response".&nbsp; And your expectation of how this =
would be otherwise<BR>implemented in a server other than a wrapper for =
GET?&nbsp; Wasteful,<BR>unmanageable, duplicate code?<BR><BR>&gt; The =
journalist's assassin word: "claim" - always<BR>&gt; used to install =
doubt without having actually<BR>&gt; doing any follow up.<BR><BR>Ooop; =
a bit defensive there.&nbsp; I was commenting based on the content =
in<BR>the blog, which is primarily written by you.&nbsp; I haven't =
spoken to any of<BR>the chaps listed, so logically whether they did or =
didn't know is<BR>unsubstantiated (this isn't a personal attack on your =
integrity, it is<BR>an auditors approach to life; if I can't validate =
it, then it is chalked<BR>up as conjecture until I can).&nbsp; So in =
context, the use of "claimed" is<BR>both accurate and appropriate.&nbsp; =
Like 9 out of 10 cat owners will know.<BR><BR>&gt; Did you read the =
paper?<BR><BR>Yes and watched the clip too.<BR><BR>&gt; The =
HEAD-redirect-to-GET and arbitrary verbs being forwarded to =
GET<BR>handler are the unique takeaways.<BR><BR>You're not getting this =
are you?&nbsp; HEAD *is* GET, just without the body.<BR>It is by =
design!&nbsp; I'm not sure how or why you would expect =
something<BR>else!<BR><BR>Martin...<BR><BR><BR><BR><BR><BR><BR>----------=
------------------------------------------------------------<BR>CONFIDENT=
IALITY:&nbsp; This e-mail and any files transmitted with it =
are<BR>confidential and intended solely for the use of the recipient(s) =
only.<BR>Any review, retransmission, dissemination or other use of, or =
taking<BR>any action in reliance upon this information by persons or =
entities<BR>other than the intended recipient(s) is prohibited.&nbsp; If =
you have<BR>received this e-mail in error please notify the sender =
immediately<BR>and destroy the material whether stored on a computer or =
otherwise.<BR>-----------------------------------------------------------=
-----------<BR>DISCLAIMER:&nbsp; Any views or opinions presented within =
this e-mail are<BR>solely those of the author and do not necessarily =
represent those<BR>of Corsaire Limited, unless otherwise specifically =
stated.<BR>--------------------------------------------------------------=
--------<BR>Corsaire Limited, registered in England No. 3338312. =
Registered<BR>office: Portland House, Park Street, Bagshot, Surrey GU19 =
5PG.<BR>Telephone: +44 =
(0)1483-746700<BR><BR></FONT></P></DIV></BODY><!--[object_id=3D#aspectsec=
urity.com#]--></HTML>
------_=_NextPart_001_01C8C18A.17698CA0--