Jump to content

Recommended Posts

No you wont be able to control what the user does in the address bar. This is where your validation/verification should come in. If you don't want users tampering with GET data then you'll have to find another method of sending data from page to page, such as cookies or sessions or go the long route and use POST (not recommended).

ANY data from the user must be validated. That includes GET, POST and COOKIE data.

 

There is nothing wrong with using GET data to drive your pages. You just need to validate. For example, if the page is looking for a product ID to display the product details you would first want to validate that the value is an integer. Then you would do a query using the ID (for text values you would also escape the value for SQL injection, but that's not needed if you validate that it is an int).

 

Now, if accessig that product description requires proper access then you would want to authenticate as well.

POST is by no means a secure way to send data between pages. A firefox plugin called 'Tamper Data' allows easy GUI modification of any post variables sent form the browser to the server.

 

You best method is to just sanitize your data properly. Use sessions if you absolutely must, but they really aren't designed for per-page transfer. You'd have to build functions just to pass variables/verify the data came from the right source and is meant for the current page, and probably still have to sanitize at some point because there would have to be a transfer of a user variable to the server.

MD5 is a hash, not an encryption. It is one way, and there's no point in using it to solve your problem outlined in the original post.

 

$res=md5(sha1(md5($email)));

That line of code makes me want to punch your mom.

try this for a flash idear mate......

 

<?php

$email_address="redarrow@redarrow.com";

$mail=md5(sha1(md5($email_address)));

$link="<a href='".$_SEVER['PHP_SELF']."?test=$mail'>link</a>";

if($_GET['test']==md5(sha1(md5($email_address)))){

echo $email_address;

}else{

echo $link;
}

?>

MD5 is a hash, not an encryption. It is one way, and there's no point in using it to solve your problem outlined in the original post.

 

$res=md5(sha1(md5($email)));

That line of code makes me want to punch your mom.

 

why you want to punch my mum hay m8 how that code wrong hay hay tell me?

updated with valadation mate............

<?php

$email_address="redarrow@redarrow.com";

if(eregi("^[a-z0-9\_\-]+@[a-z0-9].[a-z0-9\_\-]{3}",$email_address) &&
strlen($email_address) < 100){

$mail=md5(sha1(md5($email_address)));

$link="<a href='".$_SEVER['PHP_SELF']."?test=$mail'>link</a>";

if(eregi("^[a-z0-9]",$_GET['test'])&&($_GET['test']==md5
(sha1(md5($email_address))))){

echo $email_address;

}else{

echo $link;
}
}
?>

updated with valadation mate............

<?php

$email_address="redarrow@redarrow.com";

if(eregi("^[a-z0-9\_\-]+@[a-z0-9].[a-z0-9\_\-]{3}",$email_address) &&
strlen($email_address) < 100){

$mail=md5(sha1(md5($email_address)));

$link="<a href='".$_SEVER['PHP_SELF']."?test=$mail'>link</a>";

if(eregi("^[a-z0-9]",$_GET['test'])&&($_GET['test']==md5
(sha1(md5($email_address))))){

echo $email_address;

}else{

echo $link;
}
}
?>

 

It's all cool dude but I still have no idea how I could use this info to encrypt a link... for example, if I have this link on my site:

 

echo "<A HREF='muuta.php?kayttajatiedot=$admin[id]'>Change users info</A>";

 

and I want to ensure that the user really is entitled to change the info (i.e. is an admin) and is not just typing the url without privileges, how could the md5 hash prevent the person from doing that? I mean, I have a simple check for the user level based on $_SESSION variables but it all seems a bit "unstable", and I would like to opt for a little more professional way of doing it.

when a user joins the website the database needs to have a database field example prev and defualt as 1 and it a int ..............

 

You as the admin have controll off who does what via a page updating the priv in the database..

 

$sql="select * user where priv=1"; //normal user

 

$sql="select * user where priv=1 and priv=2"; // admin user

 

admin can delete everthink but user can not...

 

you restict the users privalages via the database setting 1 or 2 and

use mysql to show only what needed via there priv

 

so for example only priv 2 can see all the links but priv 1 can not......

hope you get me ok mate good luck....

 

priv in database users

 

1 meaning normal user.

2 meaning admin.

 

example only........

<?php session_start();

// database connection

$sql="select * from users where id=".$_SESSION['id']." ";

$mysql_result=mysql_query($sql)or die(mysql_error());

while($row=mysql_fetch_assoc($mysql_result)){

if($row['priv']==2){

$link= "<A HREF='muuta.php?kayttajatiedot=$_SESSION[id]'>Change users info</A>";

$link= "<A HREF='muuta.php?kayttajatiedot=$_SESSION[id]'>Delete users info</A>";

}else{

$link= "<A HREF='muuta.php?kayttajatiedot=$_SESSION[id]'>change your own pic</A>";

}

echo $link;
?>

You can't use MD5 on the link. As already stated MD5 is a one-way hash, not an encryption. So, you would have no way of knowing what value was "really" passed.

 

If you need additional security to "feel safer" then I would guess you are not to sure of your security to begin with. I would have absolutely no problem with someone putting whatever info they wanted on the URL even when I use GET data because I always validate.

 

For any admin pages the first thing you shoudl do even before grabbing the GET data would be to validate that the user should even be accessing the page to begin with. If not, kick them out to another page. Yes, there are situations where a person may be an admin but may not have rights to edit ALL records, just do that check before you do anything with their supplied data.

 

Validation and Error Handling

You can't use MD5 on the link. As already stated MD5 is a one-way hash, not an encryption. So, you would have no way of knowing what value was "really" passed.

 

If you need additional security to "feel safer" then I would guess you are not to sure of your security to begin with. I would have absolutely no problem with someone putting whatever info they wanted on the URL even when I use GET data because I always validate.

 

For any admin pages the first thing you shoudl do even before grabbing the GET data would be to validate that the user should even be accessing the page to begin with. If not, kick them out to another page. Yes, there are situations where a person may be an admin but may not have rights to edit ALL records, just do that check before you do anything with their supplied data.

 

Validation and Error Handling

 

I'm doing that already (validating the user in start of the pages)... but yeah, poor thinking led me into this situation. You see, I'm using the same php page for normal users to change their own info and for admins to change anyone's info... and that's what causes these problems. I guess I need to do a proper "user-cp" for regular users.

I'm doing that already (validating the user in start of the pages)... but yeah, poor thinking led me into this situation. You see, I'm using the same php page for normal users to change their own info and for admins to change anyone's info... and that's what causes these problems. I guess I need to do a proper "user-cp" for regular users.

 

I don't see anything inherently wrong with using the same page as long as you ensure the process prevents unauthorized process. Something like:

 

<?php

if ($edit_ID == $thisUser_ID || $thisUserAdmin == true) {
    //allow the edit
} else {
    //don't allow the edit

}
?>

 

Of course you need to make the same check on both the form page and the processing page.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.