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

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

------_=_NextPart_001_01C8C181.0A540BA2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'd like to respond inline:
=20
> The paper is grammatically well written but somewhat states the =
obvious.
=20
It is obvious after reading the paper, isn't it? Well, that's the goal =
of the paper. =3D) Given the amount of off-list responses I got from =
bugtraq... I don't know, I can't think of a really good way of saying I =
think you're just wrong.=20
=20
> I think the most surprising bit about this is the list of people on =
the
> blog who it is claimed didn't know about this stuff.=20
=20
The journalist's assassin word: "claim" - always used to install doubt =
without having actually doing any follow up. You can talk to any of =
them, though you'll probably want to be a little less insulting with the =
'obvious' bit. If there is definitive prior art I'm happy to cite it, =
but the only thing that's obvious is that the new stuff in the paper is =
not common knowledge.
=20
> The core of the issue is the implicit-allow used in some rulebases,
> which is ancient news.=20

Did you read the paper? The HEAD-redirect-to-GET and arbitrary verbs =
being forwarded to GET handler are the unique takeaways. There is a lot =
of supporting information in there to allow the conversation to get to =
that point. We've all changed a GET to a POST or a POST to a GET to =
bypass some poorly built URL authorization scheme. That's so not what =
this is about.
=20
I think it's very telling that I've gotten loads of off-list emails with =
the complete opposite feedback, and from people who you'd think are "in =
the know". Something about appearing to not know about something in =
public scares people - especially something (HEAD/arbitrary verb =
handling) that is so fundamental to what we do.
=20
Cheers,
Arshan
=20
=20
________________________________

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




The paper is grammatically well written but somewhat states the obvious.
I think the most surprising bit about this is the list of people on the
blog who it is claimed didn't know about this stuff.=20

The core of the issue is the implicit-allow used in some rulebases,
which is ancient news.  Firewall engineers all over the globe will be
spitting coffee and soggy doughnut bits into their keyboards when they
find this in their in-box...

We test for this stuff as part of our standard methodology, and one of
the things that isn't picked out in the paper which we see from time to
time is functional configuration to block unwanted methods, but only
applied to the root URI (and not flowing down the tree on a wild-card).
Generally the tools won't pick this up, but you can happily get
OPTIONS/TRACE/TRACK/DELETE/WEBDAV/PUT etc to run on a URI post auth,
further down the tree.

The other thing not mentioned in the paper is that you need to watch out
when testing this stuff, as some of the MITMs use common libraries to
deliver the HTTP transport, which helpfully fix your deliberately broken
methods or silently drop the request.

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_01C8C181.0A540BA2
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=3DidOWAReplyText40122 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I'd like to =
respond inline:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial>&gt; </FONT>The paper =
is grammatically well written but somewhat states the =
obvious.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>It is obvious =
after reading the paper, isn't it? Well, that's the goal of the paper. =
=3D) Given the amount of off-list responses I got from bugtraq... I =
don't know, I can't think of a really good way of saying I think you're =
just wrong. </FONT></DIV></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>&gt; I think the most surprising bit about =
this is the list of people on the<BR>&gt; blog who it is claimed didn't =
know about this stuff.&nbsp;</FONT></DIV><FONT size=3D2></FONT>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>The =
journalist's assassin word: "claim" - always used to install doubt =
without having actually doing any follow up. You can talk to any of =
them, though you'll probably want to be a little less insulting with the =
'obvious' bit. If there is definitive prior art I'm happy to cite it, =
but the only thing that's obvious is that the new stuff in the paper is =
not common knowledge.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>&gt; The core of the issue is the =
implicit-allow used in some rulebases,<BR>&gt; which is ancient =
news.&nbsp;</FONT><BR></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Did you read the paper? The =
HEAD-redirect-to-GET and arbitrary verbs being forwarded to GET handler =
are the unique takeaways. There is a lot of supporting information in =
there to allow the conversation to get to that point. <FONT face=3DArial =
size=3D2>We've all changed a GET to a POST or a POST to a GET to bypass =
some poorly built URL authorization scheme. That's&nbsp;so not what this =
is about.</FONT></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I think it's very telling =
that I've gotten loads of off-list emails with the complete opposite =
feedback, and from people who you'd think are "in the know". Something =
about appearing to not know about something in public scares people - =
especially something (HEAD/arbitrary verb handling) that is so =
fundamental to what we do.</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><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Martin O'Neal =
[mailto:martin.oneal@corsaire.com]<BR><B>Sent:</B> Thu 5/29/2008 6:16 =
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>The paper is grammatically well written but somewhat =
states the obvious.<BR>I think the most surprising bit about this is the =
list of people on the<BR>blog who it is claimed didn't know about this =
stuff.&nbsp;<BR><BR>The core of the issue is the implicit-allow used in =
some rulebases,<BR>which is ancient news.&nbsp; Firewall engineers all =
over the globe will be<BR>spitting coffee and soggy doughnut bits into =
their keyboards when they<BR>find this in their in-box...<BR><BR>We test =
for this stuff as part of our standard methodology, and one of<BR>the =
things that isn't picked out in the paper which we see from time =
to<BR>time is functional configuration to block unwanted methods, but =
only<BR>applied to the root URI (and not flowing down the tree on a =
wild-card).<BR>Generally the tools won't pick this up, but you can =
happily get<BR>OPTIONS/TRACE/TRACK/DELETE/WEBDAV/PUT etc to run on a URI =
post auth,<BR>further down the tree.<BR><BR>The other thing not =
mentioned in the paper is that you need to watch out<BR>when testing =
this stuff, as some of the MITMs use common libraries to<BR>deliver the =
HTTP transport, which helpfully fix your deliberately broken<BR>methods =
or silently drop the =
request.<BR><BR>Martin...<BR><BR><BR><BR><BR>----------------------------=
------------------------------------------<BR>CONFIDENTIALITY:&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_01C8C181.0A540BA2--