a link to delete an entry (was "Can I please get some help!")

[BJ Duncan]

Hey troops,

Oh man I am getting so frustated with this issue I have

I have been trying to make a link that will delete an entry to a database. I can get it working with a $_GET method, but I would like to do it via $_POST as I don't want the id number displayed in the url as it would be vulnerable for the others to be deleted too.

Here is what I have at the moment:

in the body:

if(isset($message)) {
   echo '<p class="error">', $message,'</p>';
}

$i = 0;
$value = array(2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70);
while ($row = mysql_fetch_array($result)) {
   echo "<td>".$row['jobCategoryName']."&nbsp;<a href='".$_SERVER['PHP_SELF']."?jobCategoryId=".$row['jobCategoryId']."'>Delete</a></td>";
   $i++;
   if (in_array($i,$value)) {
      echo "</tr><tr>";
   }
} 

This is the validation:

if(isset($_GET['jobCategoryId'])) {
   @include ('../../signup.php'); # db signup
   $jobId = $_GET['jobCategoryId'];
   $query = "SELECT jobCategoryName FROM jobCategory WHERE jobCategoryId = '$jobId' LIMIT 1";
   $result = mysql_query($query);
   if ($result) {
      while ($row = mysql_fetch_array($result)) {
         $jobName = $row['jobCategoryName'];
      }
   }
   $delete = "DELETE FROM jobCategory WHERE jobCategoryId = '$jobId'";
   $resultdelete = mysql_query($delete);
   if(!$resultdelete) {
      $message .= "That didn't work!";
   } else {
      $message .= "You have just deleted ".$jobName." from the database.";
   }
} 

How do I get it so it doesn't show in the url?

Any help would be so much appreciated!

[march]

I might be missing something but regardless of what you're trying to do with the form variables you can just change the method of the form like this:
<form action="" method="POST">
<form action="" method="GET">
Then your variables will be available with $_GET[] and $_POST[].

Hope that helps.
MH

[bluefrogx]

Hiding it as POST won't do much good, you'd best just set user permissions. Security via obscurity is a terrible mantra to follow :P

[MikeBigg]

When I do this (delete a record based on a id in a post variable) I include an additional post variable.

The additional field must somehow match the id before the delete is attempted.

I have done this in a few different ways - for example:

o create and save a random string and store it in the db with the id;
o concatante several fields (id+name+emailaddr) then encrypt.

Mike

[ruby-lang]

From a high-level design standpoint, leaving GET for queries is a best practice. Among other things, it prevents spiders and web accelerators from trying to fetch the delete page and accidentally deleting the entry.

One way to implement it is with Javascript:

...
 
echo "<td>".$row['jobCategoryName']."&nbsp;<a href='#' onclick="delete('".$row['jobCategoryId']."')">Delete</a></td>";
 
...
 
<script>
function delete(id) {
  var form = document.getElementById('deleteForm');
  form.jobCategoryId.value = id;
  form.submit();
}
</script>
 
...
 
<form id='deleteForm' action ='<?=$_SERVER['PHP_SELF']?>' method='POST'>
<input type='hidden' name='jobCategoryId' >
</form>

[tbakerisageek]

I like to create a token to send along with it. I have 2 functions I've created

function make_token($input){
		return md5($input.date('mdY').'BIGLONGSCARYSALTTHATCANTBEGUESSED');
 
	}
 
	function check_token($input,$token){
		if(md5($input.date('mdY').'BIGLONGSCARYSALTTHATCANTBEGUESSED') == $token){
			return TRUE;
		}else{
			return FALSE;
		}
 
 
	}

I use this token along with the ID. This way you don't have to store a hashed value in a database. if you do store it in a DB you have to worry about cleaning them up later which is no fun. The Hashed value changes for a given ID on a daily basis so there is no worry that it will be used again.

for the value of BIGLONGSCARYSALTTHATCANTBEGUESSED, I suggest using https://www.grc.com/passwords

[Dan Grossman]

By displaying a list of items that can be deleted, I assume there was some logic in choosing that list out of all possible items. Use the same logic when receiving the form or URL for a delete to ensure the ID is one the user is allowed to delete. That permission shouldn't be handled by obscurity or randomness if it can be enforced directly...

[tbakerisageek]

Dan,
Thats the wonderful part of how I do it. Even if I choose to put the ID to be deleted clear as day in the URL, the associated token that is created can only be created from a page that displays items that the current user is ALLOWED to delete. I do use a permissions system to ensure that the current user is allowed to generate the current page. This means that the ID/token combination should only be available to someone who is allowed to see it.

They can attempt to change the ID in the url but then the token will not match. If you try to reverse engineer the token, it will take you longer than when the token will change by!!

[Dan Grossman]

But...WHY?

If you have a way to know which IDs a user can delete to display them, you already have a way to know which the user can delete when they try to do so. Why create a whole second system?

For example, if the list of jobs you determined you should show a DELETE button for are those whose creator_id is equal to the user's ID, then when you DELETE, you just append the ID to the WHERE clause...

DELETE FROM jobs WHERE id = $_GET['id'] AND creator_id = $_SESSION['user_id']

...and the user's ability to delete only jobs he created is enforced without any secondary system.

[BJ Duncan]

Thanks to all for your valueable input. It is very much appreciated guys, thanks heaps.

[BJ Duncan]

And happy birthday Dan!

[tbakerisageek]

But...WHY?

If you have a way to know which IDs a user can delete to display them, you already have a way to know which the user can delete when they try to do so. Why create a whole second system?

For example, if the list of jobs you determined you should show a DELETE button for are those whose creator_id is equal to the user's ID, then when you DELETE, you just append the ID to the WHERE clause...

DELETE FROM jobs WHERE id = $_GET['id'] AND creator_id = $_SESSION['user_id']

...and the user's ability to delete only jobs he created is enforced without any secondary system.

It's not always going to be the case that the item is being deleted. Nor is it always the case that the creator is the one deleting (Or modifying, selecting, updating, validating, selecting,... You get the idea) the item. It may be a manager, co-worker, subordinate or someone else who for some reason or another has access to *use* the item. The item will not be available on screen unless the user has access to *use* it, thus no token is created.

[Dan Grossman]

And whatever rule allowed that manager, co-worker, subordinate or someone else who has access to the item to see it in their list can be applied to letting them delete it without a secondary token system.

There is no case where a program can determine when it's authorized to show a delete button but can't determine when it's authorized to process that delete button's submission... the user either had the delete permission or not, and the same lookup, however simple or complex, just has to be applied twice.

[tbakerisageek]

How about activating a user account via email. No State can be Session'ed there?

[Dan Grossman]

That's an unrelated problem. You're not verifying access to part of the application, you're verifying outside data the application doesn't have access to.