url protection

[cluelessPHP]

So this would work however even if the someone can't see the url they could still get the ID of it and run the query, what should I read to prevent this?

if(isset($_GET['del'])){
		try{

		$stat_id = htmlspecialchars($_GET['del'], ENT_QUOTES);
				require'connection.php';
				$sql = "DELET3 FROM status  WHERE stat_id = :stat_id"; 
				$stmt = $db->prepare($sql);
				$stmt->bindParam(':stat_id',  $stat_id);
				$stmt->execute();

				header("location:index.php");
		}
			catch(Exception $e ) 
			{
				echo $e->getMessage();
				die();
			}
}

[cluelessPHP]

if ($userRows->user_id === $sessionUsername)
		{ ?>
							<li class="delete"><a href="delete.php?del=<?php echo $userRows->stat_id; ?>"> Delete</a>
							<span class="success"></span>		
							<span class="fail"></span>
							<span class="error"></span>
							</li>	
							<?php
		} ?>

[dalecosp]

OK, but that will only keep unauthorized users for SEEING the link. You should also do a check on the processing instruction, and refuse to run it if the user isn't authorized.

[pbismad]

You need to apply your user permission system to ALL requests.

For the delete processing code, is the current visitor logged in, does that logged in user have permission to be deleting things at all, does that user have ownership of the specific id/data being deleted? If your code isn't checking all of these conditions, anyone can delete any data belonging to anyone.

Also, you should NOT use a get request to modify data on the server. You should use a post method form when altering data on the server.

And, htmlspecialchars() is an output function. It is used when you output content to the browser. It is not an input function and should not be used on any data being supplied to a sql query statement.

[cluelessPHP]

<?php

session_start();	
if (isset($_SESSION['user_id']))
{

$sessionUsername = $_SESSION['user_id'];	
	if()
		if(isset($_GET['del']))
		{
			try{

			$stat_id = $_GET['del'];
					require'connection.php';
					$sql = "DELET3 FROM status  WHERE stat_id = :stat_id AND user_id = :sessionUsername"; 
					$stmt = $db->prepare($sql);
					$stmt->bindValue(':stat_id',  $stat_id);
					$stmt->bindValue(':sessionUsername',  $sessionUsername);
					$stmt->execute();

					header("location:index.php");
			}
				catch(Exception $e ) 
				{
					echo $e->getMessage();
					die();
				}
	}
}
else{
	  header('location:index.php');
}	

 $(".delete").click(function(){
   var del_id = $(this).attr('id');
   $.ajax({
      type:'POST',
      url:'delet3.php',
      data:'delet3_id='+del_id,
      success:function(data) {
        if(data) {   // DO SOMETHING
		window.location.href = 'index.php';
        } 
	  }
   });
 });

Something closer to this? Since this is going to be row repeated on one page it was the only way I could think to uniquely identify them also this seems wrong if I wanted to make an admin account this would be wrong, I guess I could add an OR but that seems sort of a kludge way

[[deleted]]

(( Posting this response for another member ))

The typical way I've seen this done is to set up an actual Access Control List (ACL) and then before each request, check to see if they have access to complete the request they want. So instead of storing a unique username to an item in the database, after login, you would just set an access level or cache their ACL paths. Then upon each subsequent request where the session is active, you can quickly check the ACL for that permission. So it might look something like:

<?php if ($aclObject->hasPermission('my_model_name/delete'): ?>
<li class="delete"><a href="delete.php?id=<?php echo "<my_model_entry_id>"; ?>">Delete</a></li>
<?php endif; ?>

<?php
if ($aclObject->hasPermission('my_model_name/delete')) {
    // Attempt to delete the row from the database
}

It's a bit of a burden to build the ACL; however, it provides you greater flexibility in how you deal with permissions. You can be as strict as you want going down to the row level, or you can be as loose as you want and just say "They can do whatever they want within <my_model_name>".

[[deleted]]

(( Posting this response for another member ))

The typical way I've seen this done is to set up an actual Access Control List (ACL) and then before each request, check to see if they have access to complete the request they want. So instead of storing a unique username to an item in the database, after login, you would just set an access level or cache their ACL paths. Then upon each subsequent request where the session is active, you can quickly check the ACL for that permission. So it might look something like:

<? php if ($aclObject->hasPermission('my_model_name/delete'): ?>
<li class="delete"><a href="delete.php?id=<?php echo "<my_model_entry_id>"; ?>">Delete</a></li>
<?php endif; ?>

<?php
if ($aclObject->hasPermission('my_model_name/delete')) {
    // Attempt to delete the row from the database
}

It's a bit of a burden to build the ACL; however, it provides you greater flexibility in how you deal with permissions. You can be as strict as you want going down to the row level, or you can be as loose as you want and just say "They can do whatever they want within <my_model_name>".

[[deleted]]

(( Posting this response for another member ))

The typical way I've seen this done is to set up an actual Access Control List (ACL) and then before each request, check to see if they have access to complete the request they want. So instead of storing a unique username to an item in the database, after login, you would just set an access level or cache their ACL paths. Then upon each subsequent request where the session is active, you can quickly check the ACL for that permission. So it might look something like:

<?php if ($aclObject->hasPermission('my_model_name/delete'): ?>
<li class="delete"><a href="delete. php?id=<?php echo "<my_model_entry_id>"; ?>">Delete</a></li>
<?php endif; ?>

<?php
if ($aclObject->hasPermission('my_model_name/delete')) {
    // Attempt to delete the row from the database
}

It's a bit of a burden to build the ACL; however, it provides you greater flexibility in how you deal with permissions. You can be as strict as you want going down to the row level, or you can be as loose as you want and just say "They can do whatever they want within <my_model_name>".

[cluelessPHP]

oh so maybe it could be done via accounts? In example

if($accountType->4){
// do something clever here
}

I remember watching a video awhile ago using this idea

[maxxd]

Even after you switch to using $_POST and your server-side checks on user permissions, access, ownership, etc., you should be creating and validating a nonce, especially when dealing with database update/delete operations.