I agree with John Holmes. It's all the matter of obfuscating in this case. The real deal & structure is to have a set of permission checking! This is where ACL comes into play. But I asume ur app is not that of a big one for u to make a set of permissions based actions and gui's. So staticaly just check if the user is the same user or have access to a certain record. Again as John Holmes mentioned, Hiding or encrypting ur data is just a way of making it tough to break in. But the points I mentioned earlier about checking and securing ur code before hitting a trip to ur DB. Checking ur datatypes... n integrity... will save u time instead of thinking how to hide it, think of how to secure it even if it's open! so ACL comes into play. That's my opinion. On Tue, 21 Sep 2004 09:27:26 -0400, Bastien Koert <bastien_k@xxxxxxxxxxx> wrote: > Hi Guys > > Just to jump in here. I really need to disagree with any method of hiding > the 'record id' > > How is hiding the record ID in the hidden input any safer than in the > URL...simple answer: it isn't...it will prevent the unsophisticated user > from changing the value, but its not even challenge to a seasoned user. Same > goes for cookies. > > 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. > > 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' > > 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) 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. > > Designing this is tricky and its a lot of work, but when complete, its > portable (you can use the framework in many applications) and its secure. > Basically you build an admin area, whereby some trusted users have admin > privileges and assign those to various users. The permissions themselves are > simply yes/no fields, assigned with checkboxes or radio buttons. > > Bastien Koert > > >From: M Saleh EG <m.saleh.eg@xxxxxxxxx> > >Reply-To: M Saleh EG <m.saleh.eg@xxxxxxxxx> > >To: Stuart Felenstein <stuart4m@xxxxxxxxx> > >CC: Jasper Howard <jasper@xxxxxxxxxxxxx>, php-db@xxxxxxxxxxxxx > >Subject: Re: 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@xxxxxxxxx> wrote: > > > See my response interspersed: > > > > > > --- M Saleh EG <m.saleh.eg@xxxxxxxxx> 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 > > > > > > > > > > > > On Mon, 20 Sep 2004 15:32:07 -0700, Jasper Howard > > > > <jasper@xxxxxxxxxxxxx> wrote: > > > > > When I created a business management script for > > > > the business I work for, it > > > > > was important that ids in url's were encrypted. > > > > What I did was create a code > > > > > for each item that needed one. My encryption table > > > > fields looked something > > > > > like: enc_id, encryption, table, id where enc_id > > > > was the unique identifier > > > > > in this table, encryption was the 14 character > > > > code, table was the table > > > > > that the encrypted data was stored in, and id was > > > > the id of the encrypted > > > > > data. That was you can pass the 14 digit code in > > > > the html, then when you > > > > > need to use it in a php script you can just make a > > > > function that returns the > > > > > data from the database from the encryption code. > > > > For extra security (since > > > > > someone could just remember the encryption code) I > > > > added a cron job script > > > > > that changed the encryptions every midnight. If > > > > anyone thinks something like > > > > > this would work for them, some thing to remember > > > > is that you need to make > > > > > sure that when you add an item to the encryption > > > > table in the db that each > > > > > code is unique. > > > > > > > > > > -- > > > > > > > > > > > > > > > > > -------------------------------------------------------------->> > > > > > Jasper Howard :: Database Administration > > > > > ApexEleven Web Design > > > > > 1.530.559.0107 > > > > > http://www.ApexEleven.com/ > > > > > > > > > > > > <<-------------------------------------------------------------- > > > > > "Stuart Felenstein" <stuart4m@xxxxxxxxx> wrote in > > > > message > > > > > > > > > > > > news:20040920221627.4201.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > > > > > > > > > I'm restarting this post. I thought I was out > > > > of the > > > > > > woods, but not. > > > > > > Here situation, in most of my update forms which > > > > > > involve 1 record, passing a session variable , > > > > usually > > > > > > the users ID is enough. No URL param passing. > > > > > > > > > > > > Not so in two update forms I have where there > > > > are > > > > > > multiple records for each user. If I pass a > > > > session > > > > > > variable it only brings up the first record. So > > > > > > unless I am missing something, I must pass the > > > > record > > > > > > ID via a URL parameter. That works just great, > > > > but > > > > > > the problems lies in the fact, that all anyone > > > > would > > > > > > need to do is change recordID=1 to recordID=2 > > > > and they > > > > > > can see someone elses record, which is supposed > > > > to > > > > > > confidential. > > > > > > > > > > > > Now I've looked at sights like Monster, Amazon, > > > > Ebay, > > > > > > and tried changing the recordID in the URL area, > > > > but > > > > > > it either ignores my change or kicked back an > > > > invalid > > > > > > ID. > > > > > > This is even if I remove the other ID's from the > > > > line. > > > > > > > > > > > > > > > > > > So, I'm sure this has been dealt with more, I > > > > don't > > > > > > have the foggiest clue yet though how I can > > > > implement > > > > > > something that either hides, or prevents a user > > > > from > > > > > > going through records in the database by > > > > changing the > > > > > > id number. > > > > > > > > > > > > Appreciate any suggestions or ideas. > > > > > > > > > > > > Thank you, > > > > > > Stuart > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- Stuart Felenstein <stuart4m@xxxxxxxxx> > > > > wrote: > > > > > > > > > > > > > Turned out "hiding" the id wasn't necessary as > > > > the > > > > > > > awaiting update page can grab the session ID. > > > > > > > I wasn't thinking. Sorry > > > > > > > Stuart > > > > > > > --- John Holmes <holmes072000@xxxxxxxxxxx> > > > > wrote: > > > > > > > > > > > > > > > Stuart Felenstein wrote: > > > > > > > > > I'm still confused over one aspect of URL > > > > > > > > parameters. > > > > > > > > > As far as a form passing data back to the > > > > > > > server, > > > > > > > > I > > > > > > > > > understand about get, post and replace. > > > > > > > > > > > > > > > > > > Here is my problem. > > > > > > > > > I have an update form. User is logged in > > > > to the > > > > > > > > > system and needs to update whatever > > > > information. > > > > > > > > > Right now I'm including in the link the > > > > user's > > > > > > > ID, > > > > > > > > so > > > > > > > > > when they arrive at the update page, their > > > > > > > record > > > > > > > > will > > > > > > > > > be displayed. > > > > > > > > > The problem is all one has to do is change > > > > the > > > > > > > ID > > > > > > > > > number in the URL parameter in the update > > > > page > > > > > > > and > > > > > > > > you > > > > > > > > > can go to someone else's record. > > > > > > > > > > > > > > > > > > How do programmers generally get around > > > > this ? I > > > > > > > > must > > > > > > > > > be missing something. > > > > > > > > > > > > > > > > How do you identify the user once they are > > > > logged > > > > > > > > in? There should be > > > > > > > > some way to relate the logged in user to > > > > valid > > > > > > > > records they can see. > > > > > > > > Then, if they request an invalid record, you > > > > can > > > > > > > > show them an error > > > > > > > > page. Hiding the ID isn't going to fix > > > > anything. > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > ---John Holmes... > > > > > > > > > > > > > > > > Amazon Wishlist: > > > > > > > > www.amazon.com/o/registry/3BEXC84AB3A5E/ > > > > > > > > > > > > > > > > php|architect: The Magazine for PHP > > > > Professionals > > > > > > > - > > > > > > > > www.phparch.com > > > > > > > === message truncated === > > > > > > > > > >-- > >PHP Database Mailing List (http://www.php.net/) > >To unsubscribe, visit: http://www.php.net/unsub.php > > > > _________________________________________________________________ > 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*. > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
