Tips for Protecting Querystring Keys & Values in PHP
The easiest way to pass information to a page is by placing information in the URL. This, of course, is referred to as the querystring and the information in the querystring can be accessed by using $_GET['varname']. Simple, yes. Insecure, possibly. Here are some guidelines for managing querystring information.
Typecast Value when Expecting Numbers
When you're expecting an integer in the querystring, typecast the value before using it. This prevents string values from causing you problems.
$id = (int) $_GET['i'];
Sanitize Input
Build a basic function for each type of variable you are passing that you can use throughout your website. That ensures consistency and security.
Make Sure REGISTER_GLOBALS is Off
Stating the obvious of course, but having REGISTER_GLOBALS on is a major problem. Make sure it's turned off.
Don't Make Variable Names Meaningful
Lets just say that having a $_GET variable with the name of 'user_id' isn't a good thing. Change it to 'u' or something different.
<!-- no! --> <a href="/profile.php?user_id=<?php echo $user_id; ?>">Your Profile</a> <!-- yes! --> <a href="/profile.php?q=<?php echo $user_id; ?>">Your Profile</a>
Encrypt Querystring Values
If you need to pass sensitive information from page to page, use at least a basic encryption algorythym or an md5.
<a href="/profile.php?i=<?php echo dw_encrypt($user_id); ?>">Click here</a>
Hi) i want to share my class for filtrating with you
http://mabp.kiev.ua/content/2008/04/20/request/
In regards to “Don’t make variable names Meaningful”:
This is just another form of security through obscurity… and I disagree. I have seen it far too many times where programmers will see an article like this and grab only the easiest ones – such as that point – and then think their scripts are secure. In the grand scheme of things, if you have a variable named ‘q’ and it is always a numeric ID, I’m going to assume its the $user_id… so you really haven’t protected against really anything.
All in all, good post – I just wanted to point out that one disagreement. :) Thanks!
-aaron
@Aaron: I see your point and agree — thank you for posting.
My thought on “Encrypt Querystring Values”
<a href=”/profile.php?i=”>Click here
The so called encryption used in this example is actually a hash. The significance of a hash function is you cant reverse the hashed value back to its original value. In opposite to encryption/decryption, there is no de-hash. So if you want to decrypt Http get values use encryption like RSA, 3DES etc.
Different approach: you can add a md5 hash to verify your Http Get parameters and check if non of them has been modified. Further you would need a secret value which you include within your hash.
<a href=”/profile.php?user_id=&check=”>Click here
@Steffan: Oh wow — I have no clue how I missed that. I do have an encrypt/decrypt function but the md5 doesn’t do that. Sorry — totally whiffed on that one.
Ya don’t do the changing of var names, that really doesn’t get you any more security. Also passing hashed deals as parameters doesn’t really make sense to me, I’d rather use an encrypted session to handle those. And hash of course is one way.
The main way to secure php pages is just like securing any other language, escaping input and output. Most programmers escape input but alot still don’t escape output which is why XSS hacks are so rampant. I am guilty of this as well sometimes, usually trusting data from a database even tho it originated for a user. Technically you should really escape all data regardless.
By one way I mean you can’t decrypt hashes so that’s not a good way of passing data if you need it decrypted.
Essential PHP Security is the way to go, this is what we use as our handbook. It’s really short and pretty thorough:
http://www.amazon.com/Essential-PHP-Security-Chris-Shiflett/dp/059600656X/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1212153167&sr=8-1
I agree with Jay about the varnames and encryption thing.
Authorization should be done in the back-end code, not in the querystring ;)
When we make sure someone cannot access content they are not allowed to, we can user any variable we want in the querystring, since we know nothing is gonna happen.
As a suggestion, can you add a section about strings vs integers (ie. userID vs account name) and how to handle it.
That would be really nice.
Regards,
Martien de Jong
thanx alot …. this post is simple and very userful
hi…
im using php4 and dw_encrypt is not eorking
here is the code in which i embedded dw_encrypt
<a href="search.php?msg= “>hi
I have always wanted to know how do I remove/clear the querystring portion from the URL after I extacted the data in the same function?
There is very little reason I can see for using query strings, ever! Ok one, debugging.
I work for a company who sells theatre tickets. We use a very good database system that is used by many of the household known branded ticket agents. So when any large scale concert goes on sale, I can always get tickets quickly and easily (sometimes before they go on sale!)… Why because the practise of using querystrings.
However, I have always recommended (although people don’t always listen!) that using form POSTs are far better. Yes people in the know will second guess that you are supplying information to the next page but the average joe isn’t going to check the source code. And the average Joe isn’t going to then copy the source code onto a page and submit it. It takes the temptation out of the URL bar.
If you are supplying info to your own page, use a POST and if you ise it often store it in a Session variable. That way it is only seen once at point of entry, the most hidden way needed.
There is also very little reason (with a little slightly optional validation) why you couldn’t ask external sites to use forms either. If you offer commision it is also then easier to collect a referral URL or id.
I imagine this may be a little controversial judging from past reactions and I am open to changing my mind if theres a compelling argument.