Thanks
🔒 Locked
[web] Javascript & PHP
Advertisement
Original Post
I was looking at making a game using javascript for the client side of the game and PHP for the server side. The question is, can I do this without creating vulnerabilities? I keep thinking about the update side of it, if I have javascript sending a value to PHP and then to a DB, it looks like a bad idea because it seems everything can altered by the user in javascript. If this is indeed a no go, are there any good (free) alternatives I could use to develop in instead?
Thanks
Thanks
Javascript is inherently insecure. That said you can implement some schemes to mitigate its insecurities such as having your script make a call for a decryption key that expires very soon (like 5 seconds) or even is only good for one use but that could take some more algorithmic math than you may have. The only way to be able to "secure" your app is to use a browser plug in that incorporates encrypted communication like Java. I'm not sure about Flash but I would think they'd have something like that built in. No matter what though, you should NEVER take input received by the server from the client and pass it directly to your database. The best way to secure your database is to thoroughly scrub and verify the data you pass into your database. I would argue that this single task will take about as long to develop the game mechanics themselves. Best of luck to you.
I wonder if using something like java would be a good option. Seems like that would replace both PHP and javascript usage right?
It really doesn't make any difference, security doesn't depend on the language you use.
The client can always send any data it wants to your server , regardless of what language you use, never make any assumptions about the data you recieve, always verify that the data you get from the client is in the correct format before passing it on to for example a database.
If the data is sensitive you should always use encryption to protect the user (SSL is highly recommended for login data for example).
You can always alter session variables with javascript as a user. So that may not work.
I think i might have found a good solution. How about using session variables to keep the user from modifying the stuff I am worried about.
You can use session variables in php if you want, the user can't modify those directly unless you let them, they can modify their session though. (But if you do things right changing session should cause them to get logged out aswell)
just remember to:
1) Not have register globals enabled.
2) Don't trust data the user sends you. (with session variables the user essentially only sends you his session id, and the server uses that id to determine which set of session variables to use)
For the game I figured I would stored the players ID in a session, then I can use that to pull from the database and do all calculations server side. The only thing I would accept from the client are the actions like : Attack, move, and stuff like that and those are all predetermined command on the server, if they don't match it will kick back an error.
For the game I figured I would stored the players ID in a session, then I can use that to pull from the database and do all calculations server side. The only thing I would accept from the client are the actions like : Attack, move, and stuff like that and those are all predetermined command on the server, if they don't match it will kick back an error.
yeah that should be good, just remember to be careful about login data etc aswell, simply doing:
$query = "SELECT * FROM users WHERE username='".$_POST["username"]."' AND password='".$_POST["password"]."'";
$result = mysql_query($query);
$userData = mysql_fetch_array($result);
is very dangerous. (sending a string like: ' OR ''=' as the user name would automatically pass the login check and log the user in as the first user in the database (which is possibly the admin account, a bit more clever injections could cause severe damage aswell).
You can send the values to the database if you correctly protect the untrusted data, e.g. use prepared statments or a function which escapes SQL expressions.
Pulling all the data from the DB into your application to search it is defeating the purpose of using a database in one place (the database is more efficient at searching), and doesn't solve the problem completely (you'll eventually need to store untrusted data).
Pulling all the data from the DB into your application to search it is defeating the purpose of using a database in one place (the database is more efficient at searching), and doesn't solve the problem completely (you'll eventually need to store untrusted data).
I'm not saying this is solid, but I am working on a browser game using javascript on the front end for reading JSON data returned by the server, and creating the interface with it, primarily using Raphael JS. The only thing I send to a server however is what a user does. So if they click on a target, and what action they choose. The server calculates out all the math and handles that appropriately. Now, I'm sure there are still some vulnerabilities with that, and someone savvy could potentially cheat. Those are things I know I'll have to test and improve over time. But reducing the scope of what data I'll accept and trust helps tremendously.
You can send the values to the database if you correctly protect the untrusted data, e.g. use prepared statments or a function which escapes SQL expressions.
Pulling all the data from the DB into your application to search it is defeating the purpose of using a database in one place (the database is more efficient at searching), and doesn't solve the problem completely (you'll eventually need to store untrusted data).
Mind linking me a good article on protecting against untrusted data?
Thanks
[quote name='rip-off' timestamp='1315235928' post='4857856']
You can send the values to the database if you correctly protect the untrusted data, e.g. use prepared statments or a function which escapes SQL expressions.
Pulling all the data from the DB into your application to search it is defeating the purpose of using a database in one place (the database is more efficient at searching), and doesn't solve the problem completely (you'll eventually need to store untrusted data).
Mind linking me a good article on protecting against untrusted data?
Thanks
[/quote]
Its not really that difficult, you just have to make sure any data sent to you from the client is the expected format BEFORE you use it in a query.
With php and mysql you can do it quite easily by using the mysql_real_escape_string function for any text data entered by the user.
Just remember to always pass the sql connection you will use to the function aswell to ensure that the correct encoding is used.
for numerical data you can just do an implicit typecast by adding 0 to them.
if you use mysql_real_escape_string on a numerical value instead of typecasting it you have to add single quotes to it aswell to be safe.
The other method is to use prepared statements. (requires php5 or newer)
quick tutorial: http://www.ultramega...tements-in-php/
Its a bit more work and performance is slightly lower for queries that are only used once, (But its higher when you re-use the same query alot with a different set of parameters), its also alot harder to screw up (i can't think of any way to screw it up without causing an error while with escaping and typecasting you'll get a security flaw if you forget to escape a string or if you escape a number but forget to add quotes to it).
On top of SQL injections there are other security flaws you can get if you make assumption on user data.
One common example is pages that do things like this:
index.php
//html to draw a menu
<?php
include($_GET["page"].php);
This type of code used to be far too common a few years ago since it was a simple way to get frame like behaviour without using frames, (entering the url : http://somesite.com/...?page=downloads would put the content of downloads.php under the menu which was nice, having a user enter "http://someothersite.com/maliciouscode.php" could potentially allow an attacker to cause significant damage, along with local priviledge escalation exploits for the OS they could even completely take over the server).
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement