Security Problem With Using $_GET

[JustinK101]

Hello all,

I need help with a security problem. I have a list of various items which I grab from a database and display in a table. Something like:

View | Delete { item 1 }
View | Delete { item 2 }

Certain users can only see certain items though. The 'Delete' link simply links to a page called delete.php?id=id_of_item_to_delete_here

Then in my delete.php I simple do the mysql querry delete row where id = $_GET['id'].

[b]PROBLEM:[/b] Users who are savey can manually put ids into the address bar and refresh the page and delete items they should'nt even be able to view, let alone delete. Even worse they could just start plugging and chugging ids and manage to take out a large portion of items.

How do I fix this? Thanks!

[kenrbnsn]

Two methods come to mind.

The first, you should be doing anyway. In the code that deletes the records, you should always check the credentials of the user before doing the delete. If they came in properly, there should be no problem. If they didn't, then you would catch the error and issue an error message. Keep a record of the culprits and if there is repeat attempts do something about them.

The second way is to turn the selection into a form with method="POST" which would get the information off of the URL.

If you post some of your code, we could help you.

Ken

[JustinK101]

Hello Ken,

OK, I think I will do just that, I have to use $_GET still because acutally I don't even use a form when sending the id, I just append it directly to the url, but once they arrive at the delete.php page I will check their $_SESSION['username'] and $_SESSION['password'] against what is stored in the db.


Which brings me to my last question. On their page to edit their account I don't check the username and password against the db, I simply check the $_SESSION['id'] and grab that and update that account_id. HOw safe are sessions from users changing the id manually? Is that even possible? I suppose if I want to be 100% secure I should always check the username and password, but I just wonder if its even possible to manunally edit sessions. If it's not possible, then I should be ok not checking the username and password in this case.

[ToonMariner]

Only serverside scripts can do anything to session variables. I would NOT store anyones username or password in a session variable. The session should only be set if their credentials check out, once the session is set then it is fairly certain they are who their session id says tehy are.

[JustinK101]

Toon--

Thanks for your input.

It is my understanding that session are like cookies, in that they reside on disk locally in temp as a text file, I assume. The difference is that sessions expire much quicker and expire when the broswer is closed unlike cookies. So would it then be possible to find an active session file, assuming you could locate it, and edit it, or in fact create a session yourself on disk via a texteditor?

Inst is common practice to store usernames and passwords in sessions? How else are you going to verify the identity of a user without storing this information? What I did though was encrypt the session password, so that increases security. Then when I need to verify the identity I decrypt and compare to the password in the db.

I am curious though if anybody knows the aswer to my second paragraph.

[ToonMariner]

Have a read...

[a href=\"http://uk.php.net/manual/en/ref.session.php\" target=\"_blank\"]php sessions[/a]

The reason you should never store someones username and password is that they can be accessed. Sessions are good but still viewable by others so storing senstitive info is a big no-no in my(and many others) book.

Think, a session where just the users unique id is used to identify them can't really do any harm unless you don't manage it properly. Ok someone may do some not nice stuff like post unpleasant threads on a forum and such forth BUT you can control that.

Say they edited the users profile. if you had to enter the old password to affect any changes they could do that. If you only have the userid in the session they won't know such info. At the very least protect your users fom being hi-jacked permanently.

This is all a timescale thing, in most cases, by the time a hack is in place the session will probably have been destroyed

[JustinK101]

Toon-

But, in my circumstance I require the username and password to be stored in a session when a user logs in, so that I can then verify when they are preforming actions that their session username and pasword is equal to the username and password in the db.

Why you may ask? Because the way I have some actions setup is that for example deleting a note in a users profile is a simpe link in the form of:

[a href=\"http://mydomain.com/delete_note.php?id=some_id\" target=\"_blank\"]http://mydomain.com/delete_note.php?id=some_id[/a]

And then the delete_note.php page simply gets the some_id and deletes that value, but I first must make sure the logged in user has rights to that note, which requires I store the username and password. See what I mean? If I didnt do this check, somebody could manually edit the id and put values there and delete other notes.

I am sure there is a better way of doing what I am currently doing though.

Thanks for the help.

[kenrbnsn]

Here's a better idea than storing a clear text username & password in the session. Store an encryption of the username & password in the session, then when you need to check, apply the same encryption to the username & password in the db. If they match, you should be ok.

Ken