[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [WEB SECURITY] POST arbitarily changed to GET after form submission
- From: "PELL Scott H" <Scott.H.PELL@xxxxxxxxxxxxxxxx>
- Subject: RE: [WEB SECURITY] POST arbitarily changed to GET after form submission
- Date: Fri, 18 May 2007 10:27:40 -0700
------_=_NextPart_001_01C79971.D5E55457
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
John,
as to this part of your issue:
=20
"As regards security implications, although not being an expert here, it
would strike me that anything which can convert POST to GET between the
points of form submission and receipt of data by a script opens up a
security loophole. However, aside from that, if anyone has any idea of
what sort of mechanism could achieve this, I would be more than grateful
to hear as unless we resolve the problem rapidly, my client will have to
close down this particular service to his own clients."
=20
There are web application proxies, e.g. WebScarab, that can make such
changes, but would have to insert itself into the middle of the
conversation via web browser proxy settings. The OWASP site hosts
WebScarab for web application security training, so you can see how a
web app proxy works and could be used to change a POST to a GET.
http://www.owasp.org/index.php/Chaining_WebScarab_onto_another_proxy
Whether or not this is the mechanism that achieved in your environment
is, of course, is another question. If the application is an
external-facing one, then anyone who uses it could use a web application
proxy to inject such changes; if internal use only, same possibility but
at least more possible to deal with.
=20
Scott
=20
________________________________
From: John Gosling [mailto:johngosling@realneedsoftware.co.uk]=20
Sent: Friday, May 18, 2007 2:11 AM
To: websecurity@webappsec.org
Subject: [WEB SECURITY] POST arbitarily changed to GET after form
submission
Firstly, this may or may not be a security issue, so apologies to all if
it turns out not to be.
=20
Secondly, I am not by any means a security expert, so apologies for any
naivety here.
=20
On around 10th May, a couple of days after the recent IE Security
update, a web application which has run unproblematically for six years
began to fail. The problem as we discovered was that, intermittently,
POST requests explicitly made from the form were arriving at the server
(Linux) as GET requests, as determined from the site Access logs. This
seemed to happen with roughly 10% of all requests and with different
versions of IE (5, 6 and 7).
=20
Our first thought was that this was a CGI problem at the ISP so we
shifted the application to another ISP and found the problems continued.
The problems were also not specific to geographical location of the user
as users in various client companies were affected. We then rewrote the
application (originally based on standard HTML forms) as an embedded
Flash application, submitting all data at the end rather than from
separate forms. This did not resolve the problem.
=20
Essentially nothing has changed with the application for several months
so we have to conclude that there has been a recent update to commonly
used software (browser, local firewall, server OS) which is causing this
problem.
=20
We suspect however that the problem may be caused by a particular
interaction between the data submitted and some recent software update.
This is because we have so far been able to reproduce the problem via
our own testing and it may arise only when certain data is submitted.
Specifically, the data is from a questionnaire and is in the form of
strings of numbers and typed comments, separated by commas and @
characters. Alternatively, it may be that the problem is specific only
to certain software configurations at the user end.
=20
As regards security implications, although not being an expert here, it
would strike me that anything which can convert POST to GET between the
points of form submission and receipt of data by a script opens up a
security loophole. However, aside from that, if anyone has any idea of
what sort of mechanism could achieve this, I would be more than grateful
to hear as unless we resolve the problem rapidly, my client will have to
close down this particular service to his own clients.
=20
John G
=20
------_=_NextPart_001_01C79971.D5E55457
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2995" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D252411117-18052007>John,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D252411117-18052007>as to this part of your =
issue:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D252411117-18052007></SPAN></FONT> </DIV>
<DIV><FONT size=3D2><SPAN class=3D252411117-18052007>"</SPAN>As regards =
security=20
implications, although not being an expert here, it would strike me that =
anything which can convert POST to GET between the points =
of form=20
submission and receipt of data by a script opens up a security=20
loophole. However, aside from that, if anyone has any idea <U>of =
what sort=20
of mechanism could achieve this</U>, I would be more than grateful to =
hear as=20
unless we resolve the problem rapidly, my client will have to close down =
this=20
particular service to his own clients.<SPAN=20
class=3D252411117-18052007>"</SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN =
class=3D252411117-18052007></SPAN></FONT> </DIV>
<DIV><FONT size=3D2><SPAN class=3D252411117-18052007>There are web =
application=20
proxies, e.g. WebScarab, that can make such changes, but would have to =
insert=20
itself into the middle of the conversation via web browser proxy =
settings. =20
The OWASP site hosts WebScarab for web application security training, so =
you can=20
see how a web app proxy works and could be used to change a POST to a =
GET. =20
<A=20
href=3D"http://www.owasp.org/index.php/Chaining_WebScarab_onto_another_pr=
oxy">http://www.owasp.org/index.php/Chaining_WebScarab_onto_another_proxy=
</A> =20
Whether or not this is the mechanism that achieved in your environment =
is, of=20
course, is another question. If the application is an =
external-facing one,=20
then anyone who uses it could use a web application proxy to inject such =
changes; if internal use only, same possibility but at least more =
possible to=20
deal with.</SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN =
class=3D252411117-18052007></SPAN></FONT> </DIV>
<DIV><FONT size=3D2><SPAN =
class=3D252411117-18052007>Scott</SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN =
class=3D252411117-18052007></SPAN></FONT> </DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> John Gosling=20
[mailto:johngosling@realneedsoftware.co.uk] <BR><B>Sent:</B> Friday, May =
18,=20
2007 2:11 AM<BR><B>To:</B> websecurity@webappsec.org<BR><B>Subject:</B> =
[WEB=20
SECURITY] POST arbitarily changed to GET after form=20
submission<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT size=3D2>Firstly, this may or may not be a security issue, so =
apologies=20
to all if it turns out not to be.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Secondly, I am not by any means a security expert, =
so=20
apologies for any naivety here.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>On around 10th May, a couple of days after the =
recent IE=20
Security update, a web application which has run unproblematically for =
six years=20
began to fail. The problem as we discovered was that,=20
intermittently, POST requests explicitly made from the form were =
arriving=20
at the server (Linux) as GET requests, as determined from the site =
Access=20
logs. This seemed to happen with roughly 10% of all requests and =
with=20
different versions of IE (5, 6 and 7).</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Our first thought was that this was a CGI problem at =
the ISP=20
so we shifted the application to another ISP and found the problems=20
continued. The problems were also not specific to geographical =
location of=20
the user as users in various client companies were affected. We =
then=20
rewrote the application (originally based on standard HTML forms) as an =
embedded=20
Flash application, submitting all data at the end rather than from =
separate=20
forms. This did not resolve the problem.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Essentially nothing has changed with the =
application for=20
several months so we have to conclude that there has been a recent =
update to=20
commonly used software (browser, local firewall, server OS) which is =
causing=20
this problem.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>We suspect however that the problem may =
be caused by=20
a particular interaction between the data submitted and some recent =
software=20
update. This is because we have so far been able to reproduce the =
problem=20
via our own testing and it may arise only when certain data is =
submitted.=20
Specifically, the data is from a questionnaire and is in the form =
of=20
strings of numbers and typed comments, separated by commas and @=20
characters. Alternatively, it may be that the problem is =
specific=20
only to certain software configurations at the user end.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>As regards security implications, although not being =
an expert=20
here, it would strike me that anything which can convert POST to GET=20
between the points of form submission and receipt of data =
by a=20
script opens up a security loophole. However, aside from that, if =
anyone=20
has any idea of what sort of mechanism could achieve this, I would be =
more than=20
grateful to hear as unless we resolve the problem rapidly, my client =
will have=20
to close down this particular service to his own clients.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>John G</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV></BODY></HTML>
------_=_NextPart_001_01C79971.D5E55457--
Brought to you by http://www.webappsec.org
Search this site
|