GET or POST – which is safer?

@magoOct 27.2005

With register_globals set to off, what is considered to be safer – submitting a form using GET or POST? What are the advantages and disadvantages?

Thanks!

to post a comment

PHP

25 Comments(s) _↴

@bokehOct 27.2005 — #POST is considered more 'secure' by people who don't really know what they are talking about. The advantage of GET is it can be sent from an anchor... <a href="file.ext?query=val">link</A>. The disadvantages are that many servers can't accept large queries by this method and that the URL looks a mess. The disadvantage of POST is it can only be sent by a form.

@LiLcRaZyFuZzYOct 27.2005 — #also, you can modify the value of GET, so if you use it, never forget to verify the data and data format, (which you should do in both case anyway)

@bokehOct 27.2005 — #also, you can modify the value of GET, so if you use it, never forget to verify the data and data format, (which you should do in both case anyway)[/QUOTE]You can modify the value of POST too. Data verification is just as important no matter where the data is supposed to be coming from.

@magoauthorOct 28.2005 — #Thank you all for your replies.

So to sum up:

* Always verify data, regardless if you are using POST or GET

* Use GET for <a href>

* Use POST if processing a lot of data or the browser might freeze or info might get lost

1) Do you all agree to this?

2) Is any method considered to be slower than the other?

@bokehOct 28.2005 — #1)no

2)no
the browser might freeze or info might get lost[/QUOTE]
Nothing to do with browsers freezing.

The relevant RFC is pretty vague but to sum up it says something similar to:

Send as much data as you like (there is no limit) via the GET method [B]but only[/B] if the server the request is being sent to is capable of handling such a request.

@pattydOct 28.2005 — #You can modify the value of POST too. Data verification is just as important no matter where the data is supposed to be coming from.[/QUOTE]

How can they modify the value of POST? That is, outside the usual input fields and textarea's.

They can't alter the form itself, unless they have access to the server itself, and I don't see how they can alter the values you put into the form (unless you fetch these from GET). ?

@bokehOct 28.2005 — #They can't alter the form itself, unless they have access to the server itself[/QUOTE]You don't need access to the server to modify a form. All you need is microsoft notepad, installed on 99% of computers worldwide and if it is not installed there will be an equivalent.

@pattydOct 28.2005 — #You don't need access to the server to modify a form. All you need is microsoft notepad, installed on 99% of computers worldwide and if it is not installed there will be an equivalent.[/QUOTE]

... ...

Hang on. As in, servers don't automatically prevent form submission from an url/adres other than the target domain? Hmmm... if they don't I guess it could work as long as people are logged in...

@madddidleyOct 28.2005 — #I'm not to sure about this but when ever I send info in a form <form method="post" action="bla.php?bla=yup"> or in a link <a href=

"bla.php?var1=yo"> I always use $_REQUEST[var] to get the info.

Is this the $_GET[] or $_POST[] or is it neither? Just curious because I've seen questions similar and I wasn't even sure with what I've been doing since I've learned php.

www.maddDidley.com

@pattydOct 28.2005 — #As far as I know, it is both, giving $_POST priority over $_GET.

@magoauthorOct 28.2005 — #$_REQUEST is an associative array consisting of the contents of $_GET, $_POST, and $_COOKIE.

As far as I know there is no alternative to $_GET and $_POST.

@bokehOct 28.2005 — #I guess it could work as long as people are logged in...[/QUOTE] That's a joke, right? If somebody needed to be logged in to submit a form how would they ever get to log in the first place. Hang on. As in, servers don't automatically prevent form submission from an url/adres other than the target domain?[/QUOTE] That show a fundamental missunderstanding of how the internet works. [B]All[/B] forms are submitted from the user's machine and not from the 'target domain'.

@pattydOct 28.2005 — #That's a joke, right? If somebody needed to be logged in to submit a form how would they ever get to log in the first place.[/QUOTE]

Okay then, let me 'refine' it for you a bit more:

It could work 'even on pages where sessions and cookies are required' as long as people are logged in... I don't give a darn about login and signupscreens and what ever scripts that don't demand a session or cookie for starters. Everybody (or at least most people) thoroughly check the values comming in from those anyway.

That show a fundamental missunderstanding of how the internet works. [B]All[/B] forms are submitted from the user's machine and not from the 'target domain'.[/QUOTE]
? You can detect the 'previous' url right? So if that 'url' doesn't start out with the domain name of the target domain, you can discriminate. I don't know the exact method, but I've been told Neopets.com uses it.

@bokehOct 28.2005 — #Okay then, let me 'refine' it for you a bit more:

It could work 'even on pages where sessions and cookies are required' as long as people are logged in... I don't give a darn about login and signupscreens and what ever scripts that don't demand a session or cookie for starters. Everybody (or at least most people) thoroughly check the values comming in from those anyway.[/QUOTE]That has nothing to do with whether GET or POST is more secure.

? You can detect the 'previous' url right? So if that 'url' doesn't start out with the domain name of the target domain, you can discriminate. I don't know the exact method, but I've been told Neopets.com uses it.[/QUOTE]No. Not reliably. That information is stripped out by many firewalls and ISPs (for privacy reasons) and can easily be spooffed. In fact there is an extension for Firefox for just this purpose. Again though this has nothing to do with whether GET or POST is more secure.

@pattydOct 28.2005 — #It has to do with $_POST being secure or not, and whether there is an additional option (asside validating all the values ten times over) to secure $_POST forms. If you feel thats not on topic enough, don't worry, because this will be my last post about it.

No. Not reliably. That information is stripped out by many firewalls and ISPs (for privacy reasons) and can easily be spooffed. In fact there is an extension for Firefox for just this purpose.[/QUOTE]
I have the latest version of firefox, as well as the latest version of zonealarm. Both of them are supposed to do this 'stripping'. So...

*hops over to neopets and tests for a bit*

Works perfectly. They blocked my form posts straight from my comp, from my local server AND from the free host I'm on. I don't know how, and I'm not up to trying to investigate it, all I can say is, apparently there IS a way to discrimitate the source of the posted information by discriminating the urls.

@bokehOct 28.2005 — #this will be my last post about it.[/QUOTE]Good idea! Up until now it would seem that you have modified your argument with every new post. If you stop making these ridiculous posts now less people will realise you haven't a clue what you are talking about.

@Stephen_PhilbinOct 28.2005 — # I don't know how, and I'm not up to trying to investigate it, all I can say is, apparently there IS a way to discrimitate the source of the posted information by discriminating the urls.[/QUOTE]

EDIT: On second thoughts, rather than publicly describing how to get through it, I'll just say it's easy.

@mitconOct 28.2005 — #Mago:

I'll quietly chime in...amidst the heated exchange between Bokeh and PattyD. I don't know who PattyD is, but I know Bokeh is pretty good; I've gotten good ideas from him in the past. Just my .02 worth.

On to the real topic...

These are some of my rules of thumb on the GET/POST topic.

First and foremost, ALL RECEIVED DATA FROM ANY WEB SOURCE IS TO BE CONSIDERED EVIL! With this is in mind, and a general paranoid notion that EVERYONE is out to get my site, consider the following:

Avoid using the $_RESULT superglobal. If you are expecting $_POST fields, ONLY LOOK FOR $_POST fields. Using something like $_RESULT['foo'] gives you no clue whether it's $_POST['foo'], $_GET['foo'] or $_COOKIE['foo']! Don't make it easy for the bad guys!

If for no other reason than POST requests do not display field names on the URL line; I prefer POST whenever possible. I refuse to make it any easier than it already is for malicious people.

Once the data arrives in my PHP script I use white listing to verify the number and exact names of the fields. If either of these fail, I assume that the submitting entity was NOT MY FORM; I handle it accordingly.

Next, I validate that all fields' data are of the correct data types via CTYPES, PCREs (Perl Compatible Regular Expressions) and type casting. The method selected is based on which one fits the bill for the data type. Failing these tests are handled accordingly.

Finally, I do any specific data validations on specific fields.

I also try to keep in mind, that the information and wording of error messages (especially residual debugging messages) can also give away a whole host of valuable info to a would be hacker. Be careful mentioning things like SQL field names, table names, etc. in your messages.

As you can see there is probably more to be done on the data validation side, than deciding the GET/POST option. I believe that Bokeh alluded to that as well; as usual he is right on target.

I can send some examples. They are not the whole answer, but they might give you something to chew on.

There was a good series of articles spanning 3 issues of PHP|Architect (Tips and Tricks) You could try to download the August or September issue as your free sample. If you're interested, eMail me and I'll look it up at home to see which issue was the last one. The last installment had the most comprehensive discussion; the first 2 were a good build-up. I also found their book on PHP Security pretty good reading on alot of other PHP security issues; everything from XSS and SQL Injection to setting up Sandboxes and Tarpits for security.

Mitch

@Daniel_TOct 29.2005 — #Both GET and POST have their own uses, it is not possible to declare one "safer"

If you need information to be sent ONLY through a form and not visible on the next page, POST is for you.

However, with applications like search engines, people WILL want to link to certain search results, and this can only be done with GET.

@magoauthorOct 29.2005 — #Mitch,

Thank you so much! Was getting really confused by the discussion in this thread, but you brought some clarity to it - really appreciate it!

Based on what has been said in this thread I will do the following:

* Use POST for my form data as this will prevent the field names to appear in the URL (although these can be found by viewing the source code).

* Use GET when parsing values through URLs, because apperantly there aren't any other alternatives out there.

Best regards

@rorycanyonOct 29.2005 — #$Post>$Get, the variable transferred by $Get are very easy to change.

@magoauthorOct 29.2005 — #$Post>$Get, the variable transferred by $Get are very easy to change.[/QUOTE]

Yes, but a long as you validate your variables that are parsed through $_GET it should be all right. Don't you agree?

@LiLcRaZyFuZzYOct 29.2005 — #Really, the only difference is the way of declaring the variables you wish to pass. And, as said previously, if you wish the user to be able to save a dynamic page in his bookmark, so later on he'll still be able to access it, without having to re-enter the value.

@felgallOct 29.2005 — #A lot of people use browsers or firewalls that disable the document.referer field and without that information there is no way to tell if the person submitting the form is using a copy of your original form from your site or a modified copy on their own computer or some other site. There is therefore no way to tell if someone has modified the form fields to post different data.

The only real difference therefore between GET and POST is whether or not the passed parameters appear in the address bar. POST is therefore more secure when a password field is involved as if you use GET with a password field then anyone passing the computer can see the password. Once someone else has your visitor's password then they may launch an attack on your site to see if it contains any other security holes.

Where there are no passwords to be passed then GET and POST are equally secure.

@ShrineDesignsOct 29.2005 — #to ensure security you must VERIFY, VALIDATE, and PROCESS the user's data

verify that any or all data is present

validate the data is what is needed or wanted

and then process the data for storage/execution or as a nice little error message

NEVER assume anything

Also in #PHP _↴

how do i modify this?wordpress categories Is this possible with php/mysql

Success!

Help @mago spread the word by sharing this article on Twitter...

Tweet This

GET or POST – which is safer?

25 Comments(s) _↴

Also in #PHP _↴

Success!

Social

Version

GET or POST – which is safer?

25 Comments(s) ↴

Also in #PHP ↴

Success!

The web is an endless sea of information. Don't miss the boat... Subscribe!

Social

Version

25 Comments(s) _↴

Also in #PHP _↴