[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [WEB SECURITY] Bypassing URL Authentication and Authorization with HTTP Verb Tampering
- From: "Arshan Dabirsiaghi" <arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx>
- Subject: RE: [WEB SECURITY] Bypassing URL Authentication and Authorization with HTTP Verb Tampering
- Date: Thu, 29 May 2008 12:57:23 -0400
------_=_NextPart_001_01C8C1AD.10E56552
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Adam,
=20
I wonder how many times I'll have to say we didn't invent verb tampering =
before people will start listening - wow! I imagine this is what Al Gore =
feels like (http://www.snopes.com/quotes/internet.asp). =3D]
=20
Cheers,
Arshan
=20
________________________________
From: adam.muntner@quietmove.com [mailto:adam.muntner@quietmove.com]
Sent: Thu 5/29/2008 12:34 PM
To: Arshan Dabirsiaghi
Cc: Martin O'Neal; websecurity@webappsec.org
Subject: RE: [WEB SECURITY] Bypassing URL Authentication and =
Authorization with HTTP Verb Tampering
There was a whitepaper I recall reading a few years ago that discussed =
doing the same thing with servers running WebDAV.
I did some googling for it, but couldn't find it. Hopefully my summary =
of the paper will trigger someons's memory!
WebDAV allows the use of arbitrary HTTP verbs. The Apache LIMIT =
directive is a blacklist. Put the two together and you have problems - =
an attacker can call a script on a server running WebDAV if they know =
the exact path, using an arbitrary HTTP verb, if the server is running =
WebDAV.
It's all just another feather in the cap of "why blacklists can suck."
Some commercial web scanners like Hailstorm have rules to do things like =
substitute GET for POST to see if interesting things happen. Depending =
on how the web server code is written, I've seen a number cases where =
authentication occurs during a POST but not a GET to the same script.
So, you gave some interesting examples, but the concept of verb =
substitution is nothing new. I enjoyed the paper, but it's hardly =
groundbreaking.
PS - Please lay off the namecalling. After all, this isn't the =
full-disclosure list. :)
Cheers!
Adam Muntner, CISSP
Managing Partner
QuietMove Inc.
http://www.quietmove.com <http://www.quietmove.com/>=20
> -------- Original Message --------
> Subject: RE: [WEB SECURITY] Bypassing URL Authentication and
> Authorization with HTTP Verb Tampering
> From: "Arshan Dabirsiaghi" <arshan.dabirsiaghi@aspectsecurity.com>
> Date: Thu, May 29, 2008 8:11 am
> To: "Martin O'Neal" <martin.oneal@corsaire.com>,
> <websecurity@webappsec.org>
>
> I don't exactly know why, but you're trying to blur the difference =
between "alerting the world when most of them are doing it wrong" and =
"knowing what the RFC says", which is fairly unimportant.
>=20
> If this is a well known issue, please point me to the CWE ID or any =
other prior listing of this information? I'm not saying you didn't =
already have attack technique in your pocket, I'm saying that the world =
needed an alert.
>=20
> Incidentally, if there is no prior art out there, and someone releases =
something, and you say "I knew about that before you did!!! And seeing =
it out on the Interweb makes me soooOO madd!!", you are an idiot.
>=20
> Love,
> Arshan
>
> ________________________________
>
> From: Martin O'Neal [mailto:martin.oneal@corsaire.com]
> Sent: Thu 5/29/2008 10:25 AM
> To: Arshan Dabirsiaghi; websecurity@webappsec.org
> Subject: RE: [WEB SECURITY] Bypassing URL Authentication and =
Authorization with HTTP Verb Tampering
>
>
>
>
> Ok, so you've changed your mind then; the HEAD-redirect-to-GET isn't
> anything unique.
>
> Which leaves you with making people aware of the problems with
> implicit-allow rules. Which is old news. Which is where we started
> out.
>
> 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_01C8C1AD.10E56552
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=3DidOWAReplyText7530 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Adam,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I wonder how =
many times I'll have to say we didn't invent verb tampering before =
people will start listening - wow! I imagine this is what Al Gore feels =
like (<A =
href=3D"http://www.snopes.com/quotes/internet.asp";>http://www.snopes.com/=
quotes/internet.asp</A>). =3D]</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </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> </DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> adam.muntner@quietmove.com =
[mailto:adam.muntner@quietmove.com]<BR><B>Sent:</B> Thu 5/29/2008 12:34 =
PM<BR><B>To:</B> Arshan Dabirsiaghi<BR><B>Cc:</B> Martin O'Neal; =
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>There was a whitepaper I recall reading a few years =
ago that discussed doing the same thing with servers running =
WebDAV.<BR><BR>I did some googling for it, but couldn't find it. =
Hopefully my summary of the paper will trigger someons's =
memory!<BR><BR>WebDAV allows the use of arbitrary HTTP verbs. The Apache =
LIMIT directive is a blacklist. Put the two together and you have =
problems - an attacker can call a script on a server running WebDAV if =
they know the exact path, using an arbitrary HTTP verb, if the server is =
running WebDAV.<BR><BR>It's all just another feather in the cap of "why =
blacklists can suck."<BR><BR>Some commercial web scanners like Hailstorm =
have rules to do things like substitute GET for POST to see if =
interesting things happen. Depending on how the web server code is =
written, I've seen a number cases where authentication occurs during a =
POST but not a GET to the same script.<BR><BR>So, you gave some =
interesting examples, but the concept of verb substitution is nothing =
new. I enjoyed the paper, but it's hardly groundbreaking.<BR><BR>PS - =
Please lay off the namecalling. After all, this isn't the =
full-disclosure list. :)<BR><BR>Cheers!<BR><BR>Adam Muntner, =
CISSP<BR>Managing Partner<BR>QuietMove Inc.<BR><A =
href=3D"http://www.quietmove.com/";>http://www.quietmove.com</A><BR><BR><B=
R><BR>> -------- Original Message --------<BR>> Subject: RE: [WEB =
SECURITY] Bypassing URL Authentication and<BR>> Authorization with =
HTTP Verb Tampering<BR>> From: "Arshan Dabirsiaghi" =
<arshan.dabirsiaghi@aspectsecurity.com><BR>> Date: Thu, May 29, =
2008 8:11 am<BR>> To: "Martin O'Neal" =
<martin.oneal@corsaire.com>,<BR>> =
<websecurity@webappsec.org><BR>><BR>> I don't exactly know =
why, but you're trying to blur the difference between "alerting the =
world when most of them are doing it wrong" and "knowing what the RFC =
says", which is fairly unimportant.<BR>> <BR>> If this is a =
well known issue, please point me to the CWE ID or any other prior =
listing of this information? I'm not saying you didn't already have =
attack technique in your pocket, I'm saying that the world needed an =
alert.<BR>> <BR>> Incidentally, if there is no prior art out =
there, and someone releases something, and you say "I knew about that =
before you did!!! And seeing it out on the Interweb makes me soooOO =
madd!!", you are an idiot.<BR>> <BR>> Love,<BR>> =
Arshan<BR>><BR>> ________________________________<BR>><BR>> =
From: Martin O'Neal [<A =
href=3D"mailto:martin.oneal@corsaire.com";>mailto:martin.oneal@corsaire.co=
m</A>]<BR>> Sent: Thu 5/29/2008 10:25 AM<BR>> To: Arshan =
Dabirsiaghi; websecurity@webappsec.org<BR>> Subject: RE: [WEB =
SECURITY] Bypassing URL Authentication and Authorization with HTTP Verb =
Tampering<BR>><BR>><BR>><BR>><BR>> Ok, so you've changed =
your mind then; the HEAD-redirect-to-GET isn't<BR>> anything =
unique.<BR>><BR>> Which leaves you with making people aware of the =
problems with<BR>> implicit-allow rules. Which is old =
news. Which is where we started<BR>> out.<BR>><BR>> =
Martin...<BR>><BR>><BR>> =
----------------------------------------------------------------------<BR=
>> CONFIDENTIALITY: 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. 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: 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></FONT></P></DIV></BODY><!--[object_id=3D#aspectsecurit=
y.com#]--></HTML>
------_=_NextPart_001_01C8C1AD.10E56552--
Brought to you by http://www.webappsec.org
Search this site
|