tags:

views:

85

answers:

3

I want to allow users as well as me(the admin) to delete data in mysql. I used to have remove.php that would get $_GETs from whatever that needed to be deleted such as... remove.php?action=post&posting_id=2. But I learned that anyone can simply abuse it and delete all my data.

So what's the safest way for users and me to delete information without getting all crazy and hard? I am only a beginner :) I'm not sure if I can use POSTs because there is no forms and the data isn't changing. Is sessions good? Or would there be too many with postings, user information, comments, etc.

Ex: James wants to delete one of his postings(it is posting_id=5). So he clicks the remove link and that takes him to remove.php?action=post&posting_id=5.

EDIT: Alright, so now I am a little confused. While I can't be 100% secure, how do I do this with $_POSTs? SOO I should use GETs to get all the data to remove.php, THEN have a confirmation submit button and when users click on it, it put all the data into POSTs and delete from the dbc?

+6  A: 

Deleting records is a kind of a scary practice. If you or someone makes a mistake there's no real recourse to resolve the issue. Expunged records are very hard to resurrect.

Instead of deleting records, you could add an "active" bit (e.g. Boolean) column that is toggled off when users "delete" records. Essentially your users would be suspending records by toggling them off and the records would be saved in case mistakes or abuse but appear "deleted" to the user. To make this work with your other queries, just add a where clause of active = 1.

You could then have a utility script that's run at some specific date interval that would clean out deprecated, past dated records. You'd also need some type of timestamp for this type of maintenance.

Just a thought. Take if for what it's worth.

gurun8
Not a bad idea! I think I'll do this for important stuff such as deleting users and stuff. thank you
ggfan
A: 

Well you have to start by authenticating the users with a login script.

If you want the simplest solution possible, then I'd suggest protecting the directory in which you have remove.php with a simple .htaccess username and password.

If different users have different rights for deleting database entries, then you probably should create a PHP login script and use PHP session.

Bonk me if I'm stupid, but I searched for quite some time for a simple PHP login tutorial that could be placed on a real site (doesn't use session_register(), uses mysql_real_escape_string(), htmlspecialchars() etc) and I simply couldn't find one!

Probably this one comes the closest, you just have to replace session_register() variables with $_SESSION ones for it to work without register_globals (default in PHP5).

Indrek
Mark
I meant using $_SESSION variable for storing session data, no session_register() as it is disabled with register_globals = off in PHP5.
Indrek
+2  A: 

I'll echo gurun8 in preferring to 'mark' records as deleted, instead of actually removing data. And then obviously, you'll need to check that the authenticated user has permission to delete the post.

However, it seems very important to mention that $_GET is not safe even with authentication because of cross-site request forgery.

Imagine if Amazon adding things to your cart based on a GET request. All I'd have to do is put an image on my page with that URL, and everyone who visited that page and logged into Amazon will have products added automatically.

To match your example, I don't like Jame's post, so i put an image on my site like this:

<img src='http://example.com/remove.php?action=post&amp;posting_id=5'&gt;

And I send him a link to my page, and ask him to check it out, hoping that at the time he's logged in to your site. Because, of course, he clicked that little 'keep me logged in' button.

So you are right to be concerned about using GET. If you don't want to litter pages with forms, then confirm the action by POST.

Tim Lytle
But how exactly do I use it with POSTS? because the data isn't being changed in a form. Users are simply clicking on a remove link.
ggfan
@ggfan If 'delete' is just a link, have that link lead to a page where they have to submit (via POST) a confirmation that yes they want to delete something. Which is a good step anyway. Or use a nice image instead of a text link (images can be submit buttons, submitting hidden fields). Or use some kind of JavaScript to POST the data when clicking the link.
Tim Lytle
@Tim. But say remove.php?posting_id=5 takes them to a confirmation page and they have to click submit. But how is this different then not having a submit button because if someone wanted to hack, couldn't they just click submit? I'm confused x]
ggfan
@ggfan, CSRF (cross-site request forgery) happens when a 3rd party site 'tricks' the browser into making a GET request. However, if that request is to a confirmation page (which needs to be POSTed), there's no way to trick the browser into clicking submit on behalf of the user.
Tim Lytle
@Tim. thank you! Understand it much better.
ggfan
@Tim: Darn. I've heard of these image tricks before, but I thought the 'check if logged in' thing would fix that... I guess not. I suppose referrer checks aren't reliable either... you could still use some kind of session key in the URL though, no?
Mark
@Mark Yes, a session key would help obfuscate the link; but I'd guess there can be exploits even then (too late for me to recall). I'd just stick with POST.
Tim Lytle