1.11M Members

How To prevent URL 'ID's being changed.

 
0
 

Hi

I am a bit stuck on how to close a security issue.

Basically if someone is looking at their profile and wants to edit it the URL will show the id of the user.

Currently anyone can just change that number and have access to viewing and changing another persons profile.

I have tried the following code but what this is currently doing taking the user directly to the home page, but not actually allowng them to view or edit their own profile either.

<?php
// show if URL parameter != session variable
if (@$_GET['ID'] != (@$_SESSION['ID'])) {
?>
<meta http-equiv="Refresh" content="0; URL=http://xxxxxxxxx.com/index.php?user_id=<?php echo $_SESSION['ID']; ?>&id=<?php echo $_GET['ID']; ?>" />
<?php
}



    C<?php
// show if URL parameter != session variable
if (@$_GET['ID'] != (@$_SESSION['ID'])) {
?>
<meta http-equiv="Refresh" content="0; URL=http://xxxxxxxxx.com/index.php?user_id=<?php echo $_SESSION['ID']; ?>&id=<?php echo $_GET['ID']; ?>" />
<?php
}



If anyone has any ideas about how to stop this kind of injection attack that would be great.

Many thanks
// end if
?>
 
0
 

Just check id with session id at the time of starting the page.

suppose $a id your id;

$a=$_SESSION['Memberid'];

if($a!=$Memberid)

{
 header("Location: index.php");
}

else
{
// Your following code
}
 
0
 

This is great thanks.
How about for a URL link that does not match the ID though.

For example the only other page I would want to protect is the my 'edit_property.php' page.

For example a user is in URL: /editprop/RecordID=15

How would you equate that RecordID (which is the property ID) with the logged in user to see if it is their own property?

Many thanks for any tips.

 
0
 

Hi,

You should use md5 for the RecordID, before using it on the url. For example

$id = base64_encode($row['id']);
## then your url will be llike this /editprop/RecordID=<?php echo $id;?>

## to parse this info. by way of $_GET['RecordID'], you need to decode it like so

$processed_id = base64_decode($_GET['RecordID'];

By using this simple method, at the least the 15 is encoded and not showing the true integer value. You can also add another item in the session just to double confirm.

To find out if the RecordID is the user's own ID, you must confirm it by sending a database query matching the username from the session, and then if it confirms , give the user the rigth to edit.

 
0
 

What I meant was base_64 not md5.

 
0
 

This is great thanks.
How about for a URL link that does not match the ID though.

For example the only other page I would want to protect is the my 'edit_property.php' page.

For example a user is in URL: /editprop/RecordID=15

How would you equate that RecordID (which is the property ID) with the logged in user to see if it is their own property?

Many thanks for any tips

I'd guess the property is linked to a user in some table?

do a quick lookup to check that the property is his to edit before letting him see the data, if it isn't show them nothing

 
0
 

Hi veedeoo

Thanks for the advice. I'll try it and let you know.

cheers

 
0
 

Back to my original one though:

<?php
// show if URL parameter != session variable
if (@$_GET['recordID'] != number_format(@$_SESSION['ID'],0,".",",")) {
?>
<meta http-equiv="Refresh" content="0; URL=http://xxxxxxxxxxxxxxxxxxxxxxxx.com/index.php?RecordID=<?php echo number_format($_SESSION['ID'],0,".",",")?> &ID=<?php echo $_GET     ['recordID']; ?>" />
<?php
}
// end if
?>

What I've noticed is the following:
1 If the user tries to edit the RecordID to another record - it successfully throws them out to the index.php page.
2.The legitimate user can stay on the page and edit and submit their editions.

However after they press submit and the code goes through the submission, instead of staying on the page to see their confirmation etc - they are also then thrown out to the index.php page.

I can't work out why this would be because even after the editions have been submitted it is still the same recordID and the same session ID

Any ideas?

many thanks

 
0
 

You have a mismatch between $_GET['recordID'] and index.php?RecordID=. Make sure they are identical.

 
0
 

Yes that is right. After you are directed to index.php the ID=.... it shows up as blank.

But I can't work out why this happens after the changes are submitted. Surely you are still the same person and the recordID is still the same record, as you still on the same page.

It is working fine if someone tries to tamper/change the ID in the URL, but if you want to edit your own profile it is good until you have made the changes.

After than the URL changes to:

http://xxxxxxxxxxxxxxxxxxxx.com/index.php?RecordID=1 &ID=
 
0
 

RecordID=<?php echo number_format($_SESSION['ID'],0,".",",")?> &ID=

Theres a space just before &ID

<?php
// show if URL parameter != session variable
if (@$_GET['recordID'] != number_format(@$_SESSION['ID'],0,".",",")) {
?>
<meta http-equiv="Refresh" content="0; URL=http://xxxxxxxxxxxxxxxxxxxxxxxx.com/index.php?RecordID=<?php echo number_format($_SESSION['ID'],0,".",",")?> &ID=<?php echo $_GET     ['recordID']; ?>" />
<?php
}
// end if
?>

You should probably use header() for logins cause a browser doesn't have to follow a meta refresh - or atleast kill the script afterwards.

Also for testing just turn off the redirect and print out the variables so you can see why it is redirecting:

<?php
// show if URL parameter != session variable
if (@$_GET['recordID'] != number_format(@$_SESSION['ID'],0,".",",")) {
    echo "redirecting user because they don't match<br/>\r\n";
    var_dump(@$_GET['recordID']);
    echo "<br/>\r\n";
    var_dump(@$_SESSION['ID']);
    echo "<br/>\r\n";
    var_dump(number_format(@$_SESSION['ID'],0,".",","));
    //header("Location: http://xxxxxxxxxxxxxxxxxxxxxxxx.com/index.php?RecordID=".number_format($_SESSION['ID'],0,".",",")."&ID={$_GET['recordID']}");
    //exit;
}else{
    echo "recordID and ID matched<br/>\r\n";
}
?>
You
This article has been dead for over six months: Start a new discussion instead
Post:
Start New Discussion
Tags Related to this Article