BTW u might expose n get ur database hacked if u dont do some sort of validation while using the ID from the URI parameter !!!! example: http://domain/?show=records&id=4 if someone changes id to 4;use mysql; update user set password=md5("hello") where user='root'; imagine wat would happen??? ur mySQL root password is changed u should always avoid or protect urself.... one way is to keep "--" after ur db queries because MySQL takes "--" as comment so it will remark the rest of the queries. 1-always check for the datatype as well use the === instead of == to check if the data type holds or now when ur comparing or use is_int, is_string,....n the rest .... 2-always check if the parameter ur getting is of the same type u have in ur database 3-Try to convert or trancate the datatype to the one u need check against in ur DB for example: $recordID=is_int($_GET['id'])?$_GET['id']:-1; 4-Never expose ur column names, fieled names, or table names!! Never 5-Always protect ur DB queries by ur own error-handling and never show DB errors on ur pages... it exposes alot of data about ur database! I think ur problem is that u started coding before thinking of a logic n drawing ur algorithm... while it's simple, lack of these plannings makes ur work harder. On Tue, 21 Sep 2004 05:29:30 +0400, M Saleh EG <m.saleh.eg@xxxxxxxxx> wrote: > You should always avoid passing Record IDs through URL parameters. > Use form Hidden fields instead! > > 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. Or u better MD5 every logged in > user's record ID and hold it in ur sessions then check against it and > show the proper form or just show an error page or a page saying > Access Denied! . > > 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. > > Better use of URI querystrings would be for logic, section, category, > decision, options rather than important data such as ur table primary > keys! > > Hope this is useful. > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > -- > > > > PHP Database Mailing List (http://www.php.net/) > > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > -- > > PHP Database Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
