I'm making a simple game with Java / .net as client and using php webserver.
Now when someone finishes the level, quit or starts a new game the client sends information on a php Page that stores them in a mysql database.
Now i wouldnt that the users cheat.
To use the game client you need a username and password.
The client sends the number of times that they played the game, which player has defeated, how much points earned. So if i send clear information someone with a sniffer could see which php page I call and copy the information a send to the webserver.
So what's the best security/check system in this case?
I was thinking about use any crypt system that i usable in java vb.net c# and php (like des , md5) but I would like to know if this is the better solution or not.
Update The clients dont use The Web Browser to comunicate with the WebServer. It's WinForm application for example that call php pages to get information and to update data on Mysql DB
Thanks a lot
Some things you should know before continuing:
Everything that is on the client browser can be inspected. This includes all calls you make back to your database server. Encryption doesn't matter for this because, obviously, your javascript code will be the part encrypting/decrypting the data. Javascript can easily be looked at to get the keys.
Even Flash etc can be decompiled by those willing to spend the few minutes working it out.
Don't wait until they have completed all of their games to send info to your database. Do so as the actions occur.
You can only make it a little hard, not impossible, to cheat when using javascript as the game engine in your browser. By "a little hard" I mean it might take an hour for someone with even halfway decent programming skills to defeat... most likely much less.
Regarding sniffers. It doesn't matter if your site is SSL enabled or not. This only protects the information once it leaves the computer. It is not going to do anything about a sniffer located on the client machine.
To sum up: your only real defense here is to make cheating something that is not worth anyone's time to do.
The best option would be to have the application use a webservice and the Client application encrypts the message before sending, but unless you put in some aditional salted data (such as a timestamp to try and mitigate any replay attacks) then you'll still be open to people being able to 'easily' cheat.
.Net has some good WCF service options, and although I've never used WCF with a php endpoint the idea of WCF is to allow cross technology communication, the best bet would be to do some research into that field.
Also to note, MD5 is not an encryption method, it's a Hashing algorithm, meaning that once the data is hashed it can't be recovered.
Related
I'm trying to figure out a way for users of a website (say a student and teacher) to share a secure connection where real time updates on one page are viewed by both of them.
From research I've concluded that some of the real time updates could be performed using ajax and javascript.
But I'm stumped as to how users could share a connection where only the two users would be viewing the updates that take place on the website (such as flash animations of a drawing board.) I'm also confused how you would even begin to set up a connection like this.
I've looked intp php sessions and cookies but I'm not sure I'm doing the right research.
Any pointers as to how two specific users could share a secure connection where real time updates are viewed by the both of them only. I don't want a terse response please. I'm looking for specific details like functions and syntax specific to php. I appreciate the help and will rate you up if you give me good answers!
You cannot share a secure connection (e.g. HTTPS) its one client to one server.
If both clients are logged in and have a background AJAX task running in the browser, is it acceptable to have each client "pull" every few seconds the same data to display for both users?
This would require the "drawing board" updates to also be sent continuously back to the server to share the updated data with the other client. I'm sure there will be an event you can use to trigger the post of data (e.g. on mouse up).
If performance is an issue, you'd want to use a better server technology like Java that is able to keep session state between requests without having to persist to a database.
You can look at ajax push techniques. I used comet once where an administrator posted messages and everybody who was logged in saw that message appear on their screen. I don't know if comet supports PHP. I only used it with JSP. Just search for "ajax push" in Google.
Flash allows for connections between users, I think they refer to them as sockets.
If you want to use Ajax, et al, you need a server side technology that supports push.
Node is the standard in this regard, and you can set up a Heroku instance for free.
There are others, and you need to learn tools before even beginning to learn application.
Among the many overviews, this might interest you:
http://arstechnica.com/business/2012/05/say-hello-to-the-real-real-time-web/?1
A few good examples where this is happening:
Google Docs
Etherpad
HTML5 Games: Multi player
Techniques you can use (with varying browser support)
HTML5 WebSockets (Wikipedia; MDN; HTML5 Demo)
Comet (Wikipedia)
Really pushing data to a web browser client from a server (which would do that when it receives something from another client) is only possible with WebSockets as far as I know. Other mechanism would either require browser plugins or a stand-alone application.
However with Comet (through AJAX) you can get really close to pushing data by polling the server periodically for data. However contrary to traditional polling (e.g. where a clients asks for data every 5 seconds), with the Comet principle the server will hold that periodic request hostage for, say, up to 30 seconds. The server will not send back data until either it has data or the time out is reached. That way, during those 30 seconds, any data that the server receives can be instantly pushed back to the other clients. And right after that the client starts a new 30 second session, and so forth.
Although both Comet and WebSockets should work with a PHP backend served by Apache. I'd recommend looking into NodeJS (as server technology) for this.
There is a lot of information regarding Comet on the internet, I suggest you google it, maybe start at Wikipedia.
The great thing about Comet is that it is more a principle than a technology. It uses what we already have (simple HTTP requests with AJAX), so browser support is very wide.
You could also do a combination, where you use sockets if supported and fallback to Comet.
I'm sure you have looked into this. The opinion that this can be done via ajax is misleading to believe that two users of a website can communicate via javascript.
As you are aware, javascript happens on the client and ajax is essentially 'talking to the server without a page change or refresh'.
The communication between two users of the website has to happen via the server - php and some chosen datastore.
Hope that wasn't terse.
cheers, Rob
I am an iOS developer & developed a web services app which has been live on App Store for a year. Now I decided to make this app available cross-platform - beginning with Android, for which I hired an Android Developer.
Until this hire, all the web related code & data (PHP / MySQL / XML) was managed & fetched by me alone - so I did not worry much about the security. But now, with addition of another developer I have following concern:
The app sends POST request which includes how many rows to fetch - then a PHP script gets that many rows from MySQL & returns them in a well formatted XML. My concern is that now the employee will also know about the whole process & although he will not have direct access to PHP scripts OR MySQL database, he can still misuse it in a number of ways. For example, he can create a URL on web browser with a POST request for 100000 rows even - which will let him have all the data in an XML.
What measures should be taken to counter this? (Yes, I can force a hard limit of 40 in above particular case, but it is not an ideal or generalized solution.)
BTW, I did an extensive google research on this topic & to my understanding, the above problem is known as "Semantic URL attack". But I was not able to figure out the right solution for it. Using "Sessions" is suggested, but according to my understanding "Sessions" is only helpful if we have password based user authentication - which is not the feature of my app.
Any help would be highly appreciated.
First you must be aware that if you have no protection and allow just anything, people will be able to do anything, as simple as that. So as I understand, you don't want to use the standard protections: i.e. users having login credentials, and using per-case defensive programming.
Okay, then one partial solution would be to compute a hash:
you want to query the server with the parameters P
you compute H=hash(P)
you send ?p=P&h=H to the server
your server receives ?p=P&h=H and computes H'=hash(P)
if H' != H, then the server denies an answer
You would have to compute the same deterministic hash function in php and in your mobile app, preferably a very complex one, mixing your own dark encrypting algorithms with md5, sha1, synchronized threads, etc.
If you worry about the attacker to repeat an old query with the right hash, you can make a more complex handshake: first send to the client a random number, which will be a part of the hash to compute. Or something based on the datetime, the ip, or whatever.
Of course if the attacker reverse engineers your code, he can find out the hash function, but it would take him some work at least. You can obfuscate your client's code if you want to make his job harder.
As a testimony, I have used this sort of technique against lame attackers on services which didn't require a registration. Unless the attacker is a pro and badly wants your private data, it works.
I am planning on making a game with actionscript 3.0 (flash). However, I am having some security issues on saving user points.
To be more specific, read below and you'll understand what's the exact problem.
You are starting my flash application. PHP creates a session for your username. Playing for few minutes and reaching 750 points.
You click on "Save my points" button.
It connects "game.php?points=[]" with your point amount, hence, game.php?points=750.
PHP connects to MySQL and does an update/insert query with the username you entered when opening application, and gets the points with $_GET['points'] as you can see on 3.
The issue is,
Anyone who could directly browse "game.php?points=999999999999" would have his points saved in the database.
I thought about encrypting the points, however, Flash is a client-side application and anyone could change the "points" value with an application like "Cheat Engine". Once they change the points, encrypted points will automatically be generated by Flash.
I also thought about creating a private key for each player on their signup and encrypt accordingly, but it also won't work because once an user change his points with Cheat Engine, flash will automatically encrypt the points with given private key, hence, another useless theory...
Some people suggested me to use SSL, just because popular companies like Zynga uses it, but I am looking for other theories here.
Any ideas on this case, except using SSL?
Ps. The game will be a MMO, so securing data transaction is an essential.
For a real secure approach you need to move your game's logic to the server as much as possible and ideally make the flash movie just an interface to show the game's current state to the user.
Check out Yeldarb's post in this thread for a good explanation.
First of all SSL doesn't help you at all. It sounds like you have never heard of Tamperdata.
This is a classic CWE-602 violation. Cryptography does not address these problems because the attacker has more control over the application than you do. There is no place to hide a secret.
I am currently building a Flex 4 web app using PHP as my backend. I am using AMF to let the backend and flex application talk to each other.
How can I protect my AMF endpoint? Users can just decompile my flex application, find the URI to my endpoint and call methods. I need to ensure that all calls to the endpoint is done from within my application.
I would like to prevent somethig like this from happening: http://musicmachinery.com/2009/04/15/inside-the-precision-hack/
What are the best ways to achieve that?
Thanks :)
URLs aren't important. They're very easy to find out from any web application, and yet you still need it to have public access to them. There are a few things to do, first, if you're interested in the data security itself, you'll probably want to have your server running over https instead of http. If data security isn't crucial however (and it often isn't), you just need to have a quick and dirty authentication system.
I'm sure you can find many articles online or even frameworks made for authentication for php. In the past when I needed a very simple authentication, I would have my client send over a username and SHA1 password to an open authentication function on php, which would then create, store and return a session ID. That session ID would then be the first parameter of all the other php functions. Those functions would check the DB to see if the session ID is there or still valid (15 minute timestamp from the last time it was used) and if it is, go ahead with the function.
This is just a very simplistic way of doing things and will be good for a lot of small websites. If you need more security, send all of this over https to prevent sniffers to get the session id sent over the wire. After that, you're going into enterprise security which is probably overkill for what you want to do and will cost you an arm, a leg and your left testicle :P
I wrote a game in c++ using SDL. The game currently updates a highscore to my game site by making a post with curl if the user has logged in. The problem that I am having is that the post provides the url to the php file that receives the post on my server, and the variables that the post uses. Last night someone from china figured this out and created 5 accounts and then posted ridiculously high highscores to those users. Is there any way I can make this more secure?
Would ssl work? I've been reading about ssl all morning, and I got curl to verify that ssl is installed, but I honestly dont even know where to start with getting my php verification page communicating with my game using ssl. I'd really hate to take the whole hiscore feature down because I've already invested so much time into all of this.
At this point I am looking for the simplest solution to prevent someone from making a form and posting new hiscores to the php page.
Any help would be greatly appreciated.
You could add a small layer of security by passing not only the high score, but a hashed version that is validated on the PHP side.
e.g.
{hs:"2000";hash:'843ed7842a6bd864162022e48b84a668'}
Posted to your PHP script, that then checks,
if($hash==md5('secret'.$hs)){
//UPDATE HighScore
}else{
//Discard, flag spammer
}
The quickest solution would be to keep an eye on the high score list, delete impossible-looking scores, and blacklist known cheaters.
However, for a longer-term solution, could you possibly send a list of the players' timestamped "physical input" (mouse clicks, key presses, etc.) along with the high score?
The server could then perform some logic using the input (perhaps even running that input through a game client running on the server) to determine whether the high score is valid.
If your game uses random numbers, you'd have to send the initial random seed as well.
Once you manage to implement this, you could fairly easily create a replay system, too, which would allow players to share replays of their games with each other.
You can add salt to data, and only app on c++ knows it, and server
Or you can`t?
SSL itself won't be enough to stop people from posting high scores. There are a couple approaches I can think of to begin with:
Ship your code with a secret key that is used to encrypt the high score before sending it to the server. This has the downside that someone could reverse engineer your game to get the key. This is probably okay though, if you don't think someone would go through the trouble. Crypto++ is a C++ encryption library that you could use for this. You probably want to use symmetric-key encryption.
What I think some other games do is to use some aspect of the game along with just the raw high score value to make a submitted score invalid if it didn't contain the game state.