- Home /
Disable execute/write permissions on PHP files while maintaining the ability to execute them from Unity?
Greetings,
so I have a bunch of PHP scripts on the server that I run from Unity. I just create a new WWW object using a URL that contains the _GET parameters to the PHP script e.g. "http://webserver/path/to/script.php?name=Hello&data=World". The PHP would read in the 'Hello' and 'World' and does something with them accordingly.
The problem is I had to make the execute permissions on those files set to public otherwise I wouldn't be able to access them from Unity. But that's not safe cause now people can call my scripts with their own parameters and stuff.
My question: Is there anyway I can tell my PHP script from Unity "hey, I'm the owner of the script I have permission to execute" - That way I can disable public execute permissions and leave execute to the owner only.
My web/networking knowledge is basic, so I'm using $_GET on the server side and WWW on Unity. I've never used POST and WWWForm. I wonder if those help too or work better than $_GET?
Thanks.
i'm not an expert at this stuff, but i think the only way you can do this rigorously is to have accounts and stuff. but you could get somewhere by using HTTPS, which hides all the GET parameters, and then including a shared secret in your unity client. eg "password=its_cool_go_ahead_and_trust_me". however, if your server or client source code leaks, or if somebody cracks your client, then you're wide open again. it's up to you to evaluate the risk. if you only have HTTP available, you could have the server first provide a random string, then the client appends the password to that string and does an $$anonymous$$D5 hash of it and sends that back, and the server can check that it gets the same answer.
Thanks for the comment. How do I set this password you speak of? And if it has to be checked on the server side, that means if somebody could download my server scripts they know what the password is. Which brings us back to the file permissions.
you should definitely figure out how to set those permissions to 550 or something. read up on file permissions, users and groups, and PHP and whatever web server you're using (eg Apache). the permissions do not need to allow the whole wide internet to read the file - just the user the web server is running as needs to be able to read the file.
the password thing i was thinking of is something you would write from scratch. just send up another GET param that's a password, then check that password in your PHP fn's. but yes, this strongly relies on the password staying reasonably secret. they'll be able to get it out of your client if they try hard enough. as i mentioned, i think the only way to do this very robustly is to authenticate the client w/ a user/password.
Answer by phil_me_up · Mar 29, 2016 at 09:23 AM
You need to make sure that you setup Apache (or whatever server you're running) so that it has has the correct permissions to run the PHP scripts. Make sure that you don't give these permissions to your root user as this is a obvious security flaw. It's really a good idea to read a few "getting started with apache" guides to understand the basics of this stuff.
When unity calls the URL, it can't say "hey I'm unity so execute this script under my control", as Unity isn't a user on your machine. Even if it was it wouldn't make a difference as the php script is executed under the control of the apache user. Whenever you call the script, it should execute it as the apache user (or as you've configured otherwise) and not as something else.
As far as your server is concerned, it doesn't know the difference between Unity calling a URL or just someone typing the URL into the browser. There are some things you can do though.
Use POST instead of GET. It makes it a little harder for people to send fake data, but it's still relativly trivial. Using SSL helps this further though as it stops people snooping for parameters sent.
Get some sort of authentication token or cookie for the device as a 'login' and pass that when making future requests to post scores etc. This means people need to work out how to get and use the authentication token before they can manipulate the data. Using systems like OAuth or Facebook logins can add a level of security with relative ease (compared to setting up your own authentication system)
Encrypt what your sending and decrypt on the server side. It's slow, but adds security
Validation. Always, always check what is being sent / received and make sure it makes sense. Don't just accept any old parameters when passing to the server, and don't just accept any old data when receiving from the server.
Checksums can be written to make sure the data hasn't been manipulated
Changing ports. Again won't really fool anyone but might stop or slowdown a casual hacker.
In terms of someone downloading your scripts, again look at file permissions. You shouldn't allow the world to read and write these things and the only way they should be exposed is through URL access, which will call apache to execute the script, not to simply display in the browser.
Your answer
Follow this Question
Related Questions
Sending variables to HTML 1 Answer
After updating to v2017.1, a www call returns "406 not acceptable" 2 Answers
WWWForm problem 1 Answer