PHP - making sure $_REQUEST is what I set it.

[jamesmorris86]

Hey guys,

I am using request to pass a variable to my code that I need to update my database. Its for a game, you click on the character to attack them.

<a href="?attackverify=yes&username={$row['username']}">

But at the moment anyone is free to simply change the url and enter a different username to attack someone else.

Is there any way to verify that the user hasn't tampered with the code? or maybe a different approach I cant think of?

 

[Frozennova]

Test against the current session variables (Assuming it's login based and you are using sessions) to validate the user is logged in and the attack is executed as the correct user

 

[jamesmorris86]

It does use sessions, but that link is actually to attack another player. It uses a foreach to display all the logged in users so the $row['username'] wont match the session thats created when they log in.

I'm thinking maybe I can atleast encrypt and decrypt the request data to make it slightly more secure.

 

[Frozennova]

Used a player id rather than a username in the request url?

 

[planty]

You could generate a guid for each user and use that instead of the username.

Another improvement would be to POST the request instead of using GET/links. In general, any action that alters data on the server should be POSTed.

 

[jamesmorris86]

I can change it from username to their I.d.

Posting the request sounds interesting. I know how to send post using a form but have never used it in this way before.

Is it possible to use <a href... to send data using post?

 

[planty]

If you're using an auto-increment ID it won't be hard for people to guess other IDs, that's why I suggested something a bit more obscure like a guid.

You can use javascript/jquery to post using an 'a' tag or a button.

 

[Etheco]

Just wondering, what are the requirements for them to attack someone? When you go to attack there should be server side checks to validate that the user is allowed to attack?

so checking they are within level or other checks like have they attacked within 5 mins or have the right allowance, never trust the user.

 

[sandeep]

1. When creating new users, have their primary key as a GUID - http://guid.us/GUID/PHP
2. Use $_SESSION to store the GUID and then check to see if $_REQUEST['USERID'] is equal to $_SESSION['USERID']

Also if you already have the USERID stored as a PHP Session variable then you won't even need to include the username in

<a href="?attackverify=yes&username={$row['username']}">

Simply just call ?attackverify=yes and in the next page retrieve the username through $_SESSION['username'] that way the user cannot change the flow and will need to stick with the username that they had initially signed in with.

 

[jamesmorris86]

Currently there are checks to make sure that the attacker/other players are not unconscious and there's also a time stamp check in place to stop attack flooding.

Thats about as far as I have got. I'm going to try the JavaScript post method when I get home which will hopefully resolve my original issue

 

[sandeep]

I'm going to try the JavaScript post method when I get home which will hopefully resolve my original issue

Bear in mind that anyone with access to the console can change the username in the javascript and post a different username. Server side is the only full proof method.

 

[visibleman]

As others have mentioned, you want to be checking server-side whether or not one specific user can 'attack' another based on x, y, z conditions.
POST data can be manipulated, so it isn't a solution to this.