Reputation: 23
Is there any way a user can change the vaules of your code in php? Let's assume they have a full source code of my webpage.
// make the connection
$dbhost = 'localhost';
$dbuser = 'user';
$dbpass = 'password';
$db = "db";
$conn = new PDO("mysql:host=$dbhost;dbname=$db", $dbuser, $dbpass);
// set errors
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
// get the data
$stmt = $conn->prepare("select username from usernames where " . $number . " = '$session'");
$stmt->execute();
$row = $stmt->fetch();
$username = $row[0];
if ($username == "superuser") {
// code to view secure information and make changes to people accounts
}
Is there any way they can change their username to the "superuser"?
I am planning on being able to quickly view and edit people's account details for customer service options in the secure code part, so I don't want some random user being able to view and edit other users data.
Thanks
Upvotes: 1
Views: 1380
Reputation: 21671
Id really suggest fixing your sql, just using PDO does not guarantee security, any use of php variables in the body of the sql should be avoided
"select username from usernames where " . $number . " = '$session'"
This is not secure either
"select username from usernames where " . $number . " = :session"
What happens if $number
becomes username = 'superuser' --
"select username from usernames where username='superuser' -- = :session"
Anything after the --
is a comment in sql much like //
in php. And suddenly I am a supperuser. Yea me, it can and does happen that easily.
This is the correct way,
"select username from usernames where session_id = :session"
Not sure what $number
is, the point is no php variable interpolation in the sql body. I hate to rail on ( no secretly I love it ) but it's essential to use PDO properly. I see code with the order by 'ASC' 'DESC' posted from a webpage and injected with no thought into PDO, and it's no more secure then MySQL old style, less even because they thought it was secure.
for example
"select username from usernames where username=1 order by $order"
Think what happens if order is this
"Desc; Drop table usernames;"
You could filter the data with like an if then for example
if( strtoupper($_POST['order']) == 'DESC' ){
$order = 'DESC';
}else{
$order = 'ASC';
}
But you have to be Extremely careful whenever you use a php variable in any form of sql. And it's generally best avoided. You'll notice in the above the user data never gets put in the sql, it is used only when evaluating the if condition.
Ok as for the actual problem at hand, I would separate the admin section completely, separate user table, separate session data, separate everything. There are a few reasons here, Most importantly is that you don't have to worry about admin functionality leaking over to a normal user account. It would be easier to be logged in as both an admin and a user if the login sessions are stored separately. You could make an admin link login as ( user ) for example without knowing their password. You can log admin actions without getting it polluted with user's data. You could have various levels of admin users, again with no worry that a normal user will gain access to this ability because they are separate. It's a big job to do it right.
or can I legitly build the superuser account so I can access the data from a account inside of my website
This doesn't mean to store their credit card numbers and then peek at them, but it's your site ( you can make it however you want ), so that is implied, there are limits of course, like someone comes over to your house you cant rob them or sell their personal information without them knowing etc.... They have a certain expectation of security, a certain expectation on how you handle purchase and billing information for example. But if it's for support or legitimate business reasons, that's just good customer support to see what they do ( with log in as type ability ). Now logging in as them and running their bill up is generally going to be frowned on, but you get the idea.
Upvotes: 9
Reputation: 13
you could use filter_values() before passing the data to SQL statement.
Upvotes: 1