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
about here.

Kevin Spett
SPI Labs
http://www.spidynamics.com/

----- Original Message -----
From: "Charles Miller" <cmillerpastiche.org>
To: <webappsecsecurityfocus.com>
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
> much.
>
> 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
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]