How safe is my encrypted query string?

[bill bratske]

I'm using the mcrypt function to encrypt some query strings that I'm using to pass data between pages.  What I am doing is taking an entire query string of 5 or 6 variables, in the form of "?id=x&this=y&that=98&otherthing=10" and using mcrypt to create a hash so that my query string passes the data as newpage.com?N0chRVcR0PwTHIpPqcgh+NccESacrhV4xecYJMcKMQhBEf1 to the next page, which decrypts the query string back to the variables and goes on processing the data.

 

I'm wondering how secure this is...  what types of attacks would this be vulnerable to?  Are there any huge security holes in doing things this way that are not evident to me?

 

Thank you.

[Zhadus]

How secure do you need it? If you can decrypt it, someone else can too.

[bill bratske]

How secure do you need it? If you can decrypt it, someone else can too.

 

I'm not passing financial data or anything that sensitive, but I don't want people tampering with my application's accounting feature.  I'm basically passing the information that dictates for which member gets credited for doing something, so I don't want people messing with it wouldn't be the end of the world if a determined individual messed with it.

 

How would they decrypt it?  Would they have to brute force my hidden hash variable, or is there another way that they'd be able to do it?

[Zhadus]

Well it certainly wouldn't be easy, but it does depend on the variables and how many of them would differ from time to time. If you make your hash variable related to the current time, it would be much more difficult to brute force/experiment.

[bill bratske]

Well it certainly wouldn't be easy, but it does depend on the variables and how many of them would differ from time to time. If you make your hash variable related to the current time, it would be much more difficult to brute force/experiment.

 

Hmmm, that sounds like a good idea to beef up security. 

 

How would I implement this?  It seems like if the current time was a part of my hash variable and the next page loaded slowly or something, that the current time would be different and the hash wouldn't be decoded.

 

My encryption function currently consists of:

 

function encrypt($data_input){     
    $key = "hidden_hash_variable";
    $td = mcrypt_module_open('cast-256', '', 'ecb', '');
    $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
    mcrypt_generic_init($td, $key, $iv);
    $encrypted_data = mcrypt_generic($td, $data_input);
    mcrypt_generic_deinit($td);
    mcrypt_module_close($td);
    $encoded_64=base64_encode($encrypted_data);
    return $encoded_64;
}  

 

Thanks a lot for your input.

[Zhadus]

You're right for a slow load. Could have it round to the closest 2 minute interval. Just as you said, it doesn't need to be completely secure, just so that the general script kiddy won't have access basically. Just manipulate the date() command to factor it with your hash variable.

[cringe]

I'm wondering how secure this is...

Why not use SSL? You seem to be reinventing the wheel.

 

 

[bill bratske]

I'm wondering how secure this is...

Why not use SSL? You seem to be reinventing the wheel.

 

If I just use SSL, all of my query string data will be automatically secured?  To implement SSL I just need a signed security certificate installed on my server?

 

Sorry I'm a new coder which is the reason for my new question...

 

Thanks

[Mchl]

Why do you pass sensitive data in query string? Why not use session?

[mattal999]

Why do you pass sensitive data in query string? Why not use session?

 

Well, sessions can be easily read, and if it is not encrypted in any way, that could be a bad thing. Another thing you could try:

 

1. Form > Action to same page > Check at top of page (very top) the post values and add them to a table giving the information an ID.

2. Redirect the user to another page with the ID as soon as info is inserted to DB, say result.php?id=12. Then grab the info.

 

This way, no encryption is needed, and nobody can mess with the data. There probably is a better way though.

[bill bratske]

Why do you pass sensitive data in query string? Why not use session?

 

I actually decided to use the query string because it seemed easier at the time as my application runs a loop that finds all of the items a user owns and assigns buttons like "Delete" and "Edit" to those items.  When the script is running the loop, as it's creating the menu for Item #1 it will put the ID for item #1 into the query string of the button so that when the button is clicked the application knows which item to process.

 

I guess I'm not sure how I would use sessions to do this...  How would my application know which button was clicked if I were to store the info in the session?  I'm sure there is a way to do it, and probably a recommended way, I just can't wrap my head around it.

 

For example, my script does something like this:

 

Say the query finds 5 items for a user...

 

It runs a script like: (obviously not the actual code, the script is kinda large but this is essentially what it does)

 

While $item != ''

{

echo "<a href='delete_item.php?itemid=1'>Delete</a>"

echo "<a href='edit_item.php?itemid=1'>Edit</a>

go to next item

}

 

How would I use sessions to do that?

 

[Psycho]

While $item != ''

{

echo "<a href='delete_item.php?itemid=1'>Delete</a>"

echo "<a href='edit_item.php?itemid=1'>Edit</a>

go to next item

}

 

How would I use sessions to do that?

 

 

You wouldn't. But, in my opinion, you are approaching this the wrong way. Instead of encrypting the parameters of the link to prevent unauthorized users from performing an action (e.g. delete a record) you should just leave the links in plain text (i.e. itemid=1) and then do a permission check on the processing page to ensure the user trying to perform the action has the appropriate rights to do so. That will also make debugging MUCH easier.

 

While the current approach would be very difficult for someone to break, it IS possible. Checking the user's permissions would be definitive.

[bill bratske]

While $item != ''

{

echo "<a href='delete_item.php?itemid=1'>Delete</a>"

echo "<a href='edit_item.php?itemid=1'>Edit</a>

go to next item

}

 

How would I use sessions to do that?

 

 

You wouldn't. But, in my opinion, you are approaching this the wrong way. Instead of encrypting the parameters of the link to prevent unauthorized users from performing an action (e.g. delete a record) you should just leave the links in plain text (i.e. itemid=1) and then do a permission check on the processing page to ensure the user trying to perform the action has the appropriate rights to do so. That will also make debugging MUCH easier.

 

While the current approach would be very difficult for someone to break, it IS possible. Checking the user's permissions would be definitive.

 

Oh ok, I am actually doing a permissions check in addition to encrypting the query strings.  The permissions check is basic but I think it gets the job done.  It basically just takes the Users logged in ID (stored in session data) and checks it against the database record of the item they are trying to access.  If the user is logged in as the ID that owns the resource, they are permitted to access it.

 

Is encrypting the query string just a waste of time in this scenario, or will my application be just slightly more secure since potential hackers will not know the variable names?  I'm kindof half done with encrpyting all the query strings right now...

 

Thanks!

[Daniel0]

Why do you pass sensitive data in query string? Why not use session?

 

Well, sessions can be easily read, and if it is not encrypted in any way, that could be a bad thing.

 

Sessions can only be read on server-side. Clients cannot access the session information stored for them.

[Psycho]

Oh ok, I am actually doing a permissions check in addition to encrypting the query strings.  The permissions check is basic but I think it gets the job done.  It basically just takes the Users logged in ID (stored in session data) and checks it against the database record of the item they are trying to access.  If the user is logged in as the ID that owns the resource, they are permitted to access it.

 

Is encrypting the query string just a waste of time in this scenario, or will my application be just slightly more secure since potential hackers will not know the variable names?  I'm kindof half done with encrpyting all the query strings right now...

 

Assuming your permission check is secure & comprehensive then, yes, I would say this is overkill. You wouldn't be displaying the links to unauthorized users and you wouldn't process the links from unauthorized users. So, I'm not sure what you are trying to prevent with the encrypted parameters on the URL

[mattal999]

Why do you pass sensitive data in query string? Why not use session?

 

Well, sessions can be easily read, and if it is not encrypted in any way, that could be a bad thing.

 

Sessions can only be read on server-side. Clients cannot access the session information stored for them.

 

Oh, my bad. You learn something new every day .

[radi8]

Here is a method of always setting session variables from form data. Many will definitely NOT like this type of form layout, but it works and I like it. Key elements on the form are:

 

1. ob_start() and associated ob_flush()

2. <form> tag, when form is submitted using a button, it reloads itself

3. php pre-processor is located BEFORE the <body> tag

4. There is a <input type="hidden" name="action" value="submitted" /> at the bottom which helps ensure that the pre-processor code ONLY triggers when the form is submitted.

 

<?php
   // start the output buffer, hold everything untill processing is complete
    ob_start();
    include ('config.inc');
    session_start();
    header("Cache-control: private"); // IE 6 Fix.
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<head>
<title>Test</title>
</head>
<body>
    <table width="80%" border="0" cellspacing="0" cellpadding="0">
          <tr>
          <!-- Place all PHP inside the following <td></td> tags -->
               <td>
                <?php
                // all of this will process before the body code, do any and all preprocessing here
                    // this is a hidden button which will automatically post when the form is submitted, ensures
                    // that the form will process only when the form does a post back on itself
                    $url = 'http://somewhere.com';
                    if (isset($_POST['action']) && $_POST['action'] == 'submitted') {
                        if(isset($_POST['btnGo'])&&$_POST['btnGo']=='GO'){
                            if ((isset($_POST['txtName']))&& strlen($_POST['txtName'])>0){
                                //do stuff like set massive amounts of $_SESSION variables here
                                // call another page if necessary also
                                header("Location: ".$url);
                                // exit so nothing else processes
                                exit;
                            }
                            else{}
                        }
                    }// end isset action btn
                      else{
                        if($_SERVER['HTTPS']=='on') $_SESSION['http']="HTTPS://";
                        else $_SESSION['http']="HTTP://";
                        $_SESSION['prevURL']= index.php;//$_SERVER['HTTP_REFERER'];
                    }
                ?>
                <h2 align="center"><strong><font size="+1" face="Georgia, Times New Roman, Times, serif">Test System</font></strong></h2>
                <form action= <?php echo 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']; ?>     name="frmTest" method="post">
                   <p> 
                        <input name="txtName" type="text" id="txtName" tabindex="0">
                        <input type="hidden" name="action" value="submitted" />
                        <input name="btnGo" type="submit" id="btnGo" value="GO">
                   </p>
                </form>
            </td>
        </tr>
    </table>
</body>
</html>
<?php
    ob_end_flush();
?>

[bill bratske]

Oh ok, I am actually doing a permissions check in addition to encrypting the query strings.  The permissions check is basic but I think it gets the job done.  It basically just takes the Users logged in ID (stored in session data) and checks it against the database record of the item they are trying to access.  If the user is logged in as the ID that owns the resource, they are permitted to access it.

 

Is encrypting the query string just a waste of time in this scenario, or will my application be just slightly more secure since potential hackers will not know the variable names?  I'm kindof half done with encrpyting all the query strings right now...

 

Assuming your permission check is secure & comprehensive then, yes, I would say this is overkill. You wouldn't be displaying the links to unauthorized users and you wouldn't process the links from unauthorized users. So, I'm not sure what you are trying to prevent with the encrypted parameters on the URL

 

Well I was thinking that anyone can sign up for free, so becoming an "authenticated" user is pretty easy for anybody to do anonymously.  I was thinking that somebody may authenticate, see the query strings in the application, and decide it might be fun to hack the site... 

 

I guess I'm just trying to make it harder for anyone to hack.  This is my first PHP application so I must be slightly paranoid since I'm already doing a permissions check and cleaning the GET data to prevent SQL injection...