Subscribe: Comments on: Tips for Protecting Querystring Keys & Values in PHP
Added By: Feedage Forager Feedage Grade A rated
Language: English
average joe  code  data  don  encrypt  encryption  escape  hash  jay  point  querystring  security  source code  user  values  variable 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments on: Tips for Protecting Querystring Keys & Values in PHP

Comments on: Tips for Protecting Querystring Keys & Values in PHP

A blog featuring tutorials about JavaScript, HTML5, AJAX, PHP, CSS, WordPress, and everything else development.

Last Build Date: Tue, 20 Feb 2018 22:37:26 +0000


By: Jamie

Tue, 27 Dec 2011 09:10:31 +0000

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.

By: John

Tue, 18 Jan 2011 09:15:11 +0000

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?

By: rabia

Thu, 01 Apr 2010 06:41:17 +0000

hi... im using php4 and dw_encrypt is not eorking here is the code in which i embedded dw_encrypt hi

By: Rabe'e Wahab

Wed, 06 Aug 2008 12:49:20 +0000

thanx alot .... this post is simple and very userful

By: Martien de Jong

Sat, 02 Aug 2008 12:37:38 +0000

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

By: Jay

Fri, 30 May 2008 13:13:54 +0000

Essential PHP Security is the way to go, this is what we use as our handbook. It's really short and pretty thorough:

By: Jay

Thu, 29 May 2008 21:42:54 +0000

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.

By: Jay

Thu, 29 May 2008 21:42:07 +0000

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: david

Wed, 28 May 2008 13:01:30 +0000

@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.

By: Steffan

Wed, 28 May 2008 10:26:58 +0000

My thought on "Encrypt Querystring Values" 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. Click here

By: david

Tue, 27 May 2008 14:55:48 +0000

@Aaron: I see your point and agree -- thank you for posting.

By: Aaron Saray

Tue, 27 May 2008 14:39:16 +0000

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


Tue, 27 May 2008 14:21:21 +0000

Hi) i want to share my class for filtrating with you