PHP More Secure Way To Redirect - php

Question

I have a php page which does an insert and then does a redirect to a "success" page which displays the order details. I am redirecting by using a variable, but I am thinking this is not so secure:
header("location:success.php?id=$orderid");
This generates a url like this: success.php?id=22
I am then using the URL to obtain the order ID number and doing a query based off of that to present the order details:
$getName = explode('?id=', $_SERVER['REQUEST_URI']);
$id = $getName[1];
$query = <<<SQL
SELECT * FROM `order` WHERE `orderid` = ?;
SQL;
$request = $mysqli->prepare($query);
$request->bind_param("i", $id);
$request->execute();
The obvious issue is that anyone could simply change the URL id number to get the details of a different order number. I'm not too terribly concerned as this is strictly an internal site, but I'd still like to fix this behavior. Is there a better, more secure way to do this?

Answer 1

Here is an easier solution: Store orderid in the session like this $_SESSION['orderid'] = $orderid.
And on redirect you'll get it's value as below:
$getName = explode('?id=', $_SERVER['REQUEST_URI']);
$id = $_SESSION['orderid'];
$query = <<<SQL
SELECT * FROM `order` WHERE `orderid` = ?;
SQL;
$request = $mysqli->prepare($query);
$request->bind_param("i", $id);
$request->execute();

Answer 2

In general, the problem of allowing a customer to view a past order while not allowing others to view this order has two steps.
Set authorization policy: Determine which users are allowed to view which order numbers. This ought to include the ability to come back in a later session and view the status of an order.
Back it with an authentication method: Store and retrieve enough information to identify the user.
Authorization policies to consider include the following:
The user who just placed an order is allowed to view it in the same session. This is the policy you describe in your question.
Placing an order creates a unique ID. Anyone with this ID is allowed to view it.
Someone who creates a user account, provides an e-mail address and verifies ability to receive mail at that address is allowed to list orders associated with that billing e-mail and view them.
Someone who provides the correct order ID and shipping postal code (or other PII needed for order processing) is allowed to view that order, but not list any, and this is rate limited in some manner for each IP address. (Users behind a big NAT have the other three choices.)
To implement policy 1 (same session), you can store the order ID in the session, whether in PHP's $_SESSION or in a separate session properties table, as soon as the order is marked as paid. Then when the user tries to view an order, you can allow it if the order ID matches the most recent for this session.
To implement policy 2 (unique ID), you can generate and store a suitably long random identifier, such as a version 4 UUID, and store it with the order. Warn the user: "Be careful: anyone who sees this order ID can view and change your order."
To implement policies 1 and 2 in one stroke, you can store the session ID with each order, display the session ID on the success page, and then let the user search for orders associated with a particular session.
To implement policy 3 (control of billing e-mail), you can add a user table including user ID, password hash, e-mail address, and (nullable) e-mail confirmation date. This would also give you a chance to add user-created product lists, which lets you add features such as an alert when a product comes back in stock.
To implement policy 4 (order ID and shipping info), you can make a table logging the IP address, date, and more information about each request, apply a heuristic to determine whether a scripted brute force attack is in progress, and then compare the shipping postal code provided by the user to that in the order.
Keep these policies and mechanisms in mind as you continue to develop your store application, as they are likely to increase its usability.

Answer 3

On your system I assumed your orders are related to you users.
For example order: 1234 has relation with user: 5
Check this relation on your success.php
If your scheme has not user-order relation I strongly recommend it. But if orders doing by anon users, hash order_id
basically like
select * from order where order_id = 1234 and userid =5
If this query returns a row, that user really has this order. Else something is wrong.
if($returnedRow == 1){
//Do something here
}else{
//access denied. You are not owner of this order.
}
As I said, count returned row, this is simple way. Also if you hash your order_id like dfljfk45498ds545 it can be less predictable. You can use uniqid() for this purpose.

Answer 4

use cookie or session to send "$orderid"
*session is better