[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[WEB SECURITY] POST arbitarily changed to GET after form submission
- From: "John Gosling" <johngosling@xxxxxxxxxxxxxxxxxxxxxx>
- Subject: [WEB SECURITY] POST arbitarily changed to GET after form submission
- Date: Fri, 18 May 2007 11:10:52 +0200
------=_NextPart_000_003D_01C7993D.32CEB1D0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Firstly, this may or may not be a security issue, so apologies to all if =
it turns out not to be.
Secondly, I am not by any means a security expert, so apologies for any =
naivety here.
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).
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.
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.
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.
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.
John G
------=_NextPart_000_003D_01C7993D.32CEB1D0
Content-Type: text/html;
charset="Windows-1252"
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=3Dwindows-1252">
<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<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_000_003D_01C7993D.32CEB1D0--
Brought to you by http://www.webappsec.org
Search this site
|