Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Kevin Spett (kspett_at_spidynamics.com)
Date: Tue Nov 12 2002 - 09:45:34 CST
Consider a development team, where some developers check request methods
before performing operations and some don't. If developers are inconsistent
about method-checking, functionality could be broken, possibly in a way
affecting security, by someone making a GET where it expected a POST. ie,
data is only sanitized on POSTs, becuase one person wrote or modified that
code, but the application will accept and process a GET, because someone
else wrote that. Of course, the bottom line here is making your code
consistent and able to handle both situations, but it's something to think
----- Original Message -----
From: "Charles Miller" <cmillerpastiche.org>
Sent: Monday, November 11, 2002 3:28 PM
Subject: Re: When GET = POST?
> Okay, so this is a pretty belated reply.
> On Tuesday, November 5, 2002, at 09:54 PM, Chris Thomas wrote:
> > - Why does it happen? Is it just lazy coding or do languages like ASP
> > offer no way to differentiate if data was POSTed or GETed?
> I'm going to buck the trend here, and say that from the point of view
> of the script processing the form data, I don't think it matters that
> It matters _before_ the user sends the data. Whether you put
> method="POST" or method="GET" in your form tag matters, for all the
> reasons noted in other posts and some that haven't. (data length
> limits, susceptibility to caching and logging (especially referer
> logs), appearance in browser-history, effect of returning to the page
> from the back button or browser history) My general rule is that if you
> want someone to be able to bookmark a query or email it to someone else
> you use GET, otherwise you use POST.
> After the form is submitted, however, it's just data. If someone
> subverts a form so that the contents are sent by GET instead of POST or
> vice versa, it's not really a security problem for the server. It may
> be a security risk for the user, but it's certainly not something a
> user can do by mistake. To the program that must interpret the
> submission, it's all still user-provided data.
> The exception would be cross-site scripting. If your application may be
> vulnerable to XSS, POST is marginally more trustworthy than GET,
> because browsers are more likely to warn about a cross-site POST. But
> only marginally, you also have to assume users are likely to ignore the
> warning and perform the dangerous POST regardless. If you are taking
> any other, more effective measures to combat XSS, the difference in
> trustworthiness between GET and POSTed data is largely erased.
> There may also be a design-by-contract justification, using the
> form-handling scripts to verify that the HTML has been written
> correctly. But that doesn't move the ultimate responsibility away from
> the HTML, it's just a useful verification of correctness.
> I'm quite possibly wrong. Can someone model a threat based around the
> substitution of one kind of form submission for another, assuming the
> webapp is already being vigilant against cross-site scripting?
> Charles Miller
> Contributing to the Heat Death of the Universe since 1975.
> http://fishbowl.pastiche.org -- the weblog