Re: Passing URL parameters, how to hide

From: Date: Tue, 21 Sep 2004 14:05:09 +0000
Subject: Re: Passing URL parameters, how to hide
Groups: php.db 
Request: Send a blank email to php-db+get-36300@lists.php.net to get a copy of this message
Ok, so you can't store the record id in the session, no problem. Assuming you store the userid in a session, you can pass the record id in the hidden field. Then when retreiving the data, after validating the record_num How to validate: If you know that the record_is id only numeric, then check for that, if its alpha and of a certain length, check for that, if there is a pattern to the record_id (like AA-123) then use regex to check the data. You can also validate the IP of the user for the session. Since many people are still on dialup, they do not have a static IP and therefore its of little value to store...but it should remain the same for the session. $sql = 'select * from tableName where record_id = $record_id and user_id = {$_SESSION['user_id']}'; $result = mysql_query($sql); if (mysql_num_rows($result)!= 1){ //either more than 1 row or no rows so present the user with an error message and the form / page to choose their record again }else{ //data retreived is ok...so pass the results to the user in form or whatever }//end if As for the design/build of the security system, its up to you. But the one thing that is useful is that you can use over and over if its well designed, Bastien
From: Stuart Felenstein <stuart4m@yahoo.com> To: Bastien Koert <bastien_k@hotmail.com>, m.saleh.eg@gmail.com CC: jasper@velocity7.com, php-db@lists.php.net Subject: Re: [PHP-DB] Passing URL parameters, how to hide Date: Tue, 21 Sep 2004 06:45:48 -0700 (PDT) See response interspersed: --- Bastien Koert <bastien_k@hotmail.com> wrote: To be entirely honest, there is no real reason not to use the url to pass data, IF the data is not sensitive. For sensitive data, sessions are the best thing to use. HIdden fields are good only to keep the users from accidently changing the id to something. For whatever reason I can not use session only here. It does not return the correct record from the table. Maybe that doesn't make anysense. In the listing of recods where the user would click to go update, there is a repeat region SQL statement that shows all records from table under session ID. e.g. Record_Table
recordID   userID     info1name     info1details
   1         3         somename        sos
   2         4         somename        sos
   3         3         somename        sos
   4         4         somename        sos
   5         3         somename        sos
   6         5         somename        sos
This doesn't negate the need to validate the incoming data, ALL incoming data needs to be validated and exceptions need to be handled. So if the user changes the id number to something else, then a message should appear saying 'no record found' This sounds fine and from what I've seen the common method. So what form of validation does one use to do this ? A better approach to securing sensitive data is to use the database and to develop a system whereby usiers can only access their own limited data. There is a little more data involved here (like storing a user_id with the row) See above, user_id is stored in row This user_id can then be associated with users record > (profile) and that profile could be used to determine > whether the user can view/edit/access the particular > record. The user's profile is stored in a session (or it could be validated every time there is db interaction) and those values determine exactly > which records the user can do anything with. You can build profiles that could llimit the access to data belonging to a particular group of users, a particular region of the country or to a single location, depending on the structure of the compnay and the desired goals of the system. In my system, users cant' just change data anywhere. The are forms to insert in particular tables, and update forms when the need to change info arises. I am not sure that what you speak about here is practicle or necessary for this application Stuart Bastien Koert
From: M Saleh EG <m.saleh.eg@gmail.com> Reply-To: M Saleh EG <m.saleh.eg@gmail.com> To: Stuart Felenstein <stuart4m@yahoo.com> CC: Jasper Howard <jasper@velocity7.com>,
php-db@lists.php.net
Subject: Re: [PHP-DB] Passing URL parameters, how
to hide
Date: Tue, 21 Sep 2004 15:19:32 +0400 1-So I'm going to ask, how does PHP stop a URL from being changed ? Are there specific functions that block that type of activity ? I said :" I personaly dont recommand using url
parameters for
passing record ids, i'd rather use hidden inputs, sessions, or even cookies but never URI querystrings for record ids. " 2-Stuart Felenstein askes : "Can you explain a bit
further how an hidden
input might work ?" I'll answer ur first question here. The addresses
on the browsers are
in control of the users. you cant control that.
wat's on the client
side is only controlled by the client which is the
browser. So u cant
stop changing the address,( the work around is
using a popup that
wouldnt show the address but still a person with
abit of knowledge
would figure out openning a new window hisself n
entering the address
so it aint practical). Instead you can validate the
ID that is comming
from the URI. How's that? alright, Your check the
ID weather with
encryption or not if it matches with the ID of the
user logged in show
the form if not that's it show the error page. Ur 2nd question.. Okay .. how would u use the
hidden inputs? with
hidden inputs.. I mean the form hidden elements
(<input type="hidden"
name="id" value="recordID" />) so instead of having
hyperlinks
pointing to the form page use a form with submit
btns that post the
hidden id to the page that shows the user forms.
That is by fetching
the recordID by post. Hope it's useful. On Tue, 21 Sep 2004 01:20:42 -0700 (PDT), Stuart
Felenstein
<stuart4m@yahoo.com> wrote:
See my response interspersed: --- M Saleh EG <m.saleh.eg@gmail.com> wrote:
You should always avoid passing Record IDs
through
URL parameters. Use form Hidden fields instead!
I agree. Even as someone with limited
experience.
That is why I'm trying to figure out the right
way to
do it. The record ID is hidden in form itself. The way to get to the update form for that
record is
via a hyperlink. I'm not sure how to get the
user to
the update form without the hyperlink or how to
hide
the id part of the url parameter in the link.
In your case, when ur selecting the users form
data
from the record check if it's the same user if
not
then if he tries to change the ID from the URI Parameter just block it.
Yes, I think this is the way to go. And I'm
halfway
there, in that , if someone changed the id and
brought
up another users record, and they attempted to
make
changes the update would fail. So I'm going to ask, how does PHP stop a URL
from
being changed ? Are there specific functions
that
block that type of activity ?
I personaly dont recommand using url
parameters for
passing record ids, i'd rather use hidden
inputs,
sessions, or even cookies but never URI
querystrings > for record ids. Can you explain a bit further how an hidden
input
might work ?
Better use of URI querystrings would be for
logic,
section, category, decision, options rather than important data
such as
ur table primary keys!
Agreed!
Hope this is useful.
Very useful, thank you! Stuart
=== message truncated ===
_________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

« previous php.db (#36300) next »