Re: When GET = POST?

[Charles Miller <cmiller () pastiche org>]

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