| SitePoint Sponsor |
Is there any reason why passing the "MemberID" in the URL/Query String could be considered dangerous??
I have had a lot of people tell me emphatically, "No!" but I'm not so sure myself...
One reservation that I have, is that unlike Username and Email, the MemberID is not necessary "public" information.
Thanks,
Debbie
No its not bad. It is just a number. As long as they cannot bypass authentication and make changes to that user.
I require an E-mail and Password and activation to log in, and am using Prepared Statements, Salt, Vinegar, and sha512, among other things...Originally Posted by logic_earth
Debbie
I guess you never noticed, but this very forum uses GET variables eg.
http://www.sitepoint.com/forums/member.php?399760-DoubleDee
Have you ever experienced problems here because of it?
Yes, I have noticed that, but I also know people who have smoked 2 packs (of cigarettes) a day their entire life...
Does that mean it is a good idea?
Debbie
In this case, it's only getting a publicly viewable (to logged in members) page - not a "private" or "restricted use" file. Nor is it doing anything like database entry or file writing.
The generally accepted rule of thumb is to use GET (i.e. in URL) to "get" stuff - a page, json etc. and POST (i.e. in a form) to post (send) stuff to the server for further handling.
I guess not, but again, I thought you might consider "Member ID" to be secret like your "Bank Account #" or "Social Security #", whereas a "Username" seems less secret, that's all.
Well, someone told me I shouldn't be so reliant on $_SESSION because it is easier to break - especially with Tabbed Browsing. (I didn't really understand what the person meant at the time, but sine then, I have been trying to get more comfortable passing stuff from page to page via the Query String *IF* I think it is safe data to pass, and thus the whole point of this thread?!The generally accepted rule of thumb is to use GET (i.e. in URL) to "get" stuff - a page, json etc. and POST (i.e. in a form) to post (send) stuff to the server for further handling.
Thanks,
Debbie
I've never heard that, not that there couldn't be a problem under certain circumstances.
This forum uses SESSION variables and I always have at least 2 tabs open and often up to a dozen or more.
it not so much from a security point of view, but from a functionality/usability point of view.
Eg say you open an edit product page and assign then product Id of the product you are editing to the session[edit_id] but before you save that, you open up an edit product page for another product in another tab (to Check something, eg stock level). Now when you go back to you other tab/window the session edit_id has been replaced with the last products I'd. If you hit save, you replace product b's details with product a. Now you have 2 product a's with different Id's.
If you was passing the product Id via post vars instead of the session, it wouldn't happen.
There are ways around this without passing everything via get/post parameters. A combination of session and post vars ensures good security/usability provided you check what is being sent via post matches what you are expecting compared wi the session.
I take the approach of using a unique form Id and storing all session vars relating to that form under that id and passing the form Id via post.
phpSiteMinder - website backup and file integrity monitoring.
Been hacked? phpSiteScanner can help you clean your site up.
Posting Permissions
Reply With Quote
Bookmarks