Secure communication between Flash and PHP script - php

I have little knowledge of Flash but for a little Flash game I have to store score and successful tries of users in a database using PHP. Now the Flash runs locally on the users computer and connects to a remote server. How can I secure against manipulation of game scores. Is there any best practice for this use case?

You might want to check these other questions:
Q46415 Passing untampered data from Flash app to server?
Q73947 What is the best way to stop people hacking the PHP-based highscore table of a Flash game.
Q25999 Secure Online Highscore Lists for Non-Web Games

What you are asking is inherently impossible. The game runs on the client and is therefore completely at the user's mercy. Only way to be sure is running a real time simulation of the game on the server based on user's input (mouse movement, keypresses), which is absolutely ridiculous.

This topic has been covered here # stackoverflow, at least in part
What is the best way to stop people hacking the PHP-based highscore table of a Flash game

As ssddw pointed out, this is fundamentally impossible. The code to send the score is running on the user's computer, and they have control over it and everything that runs there.
The best you can do is to periodically alter the encryption mechanism so that it takes score-manipulators a while to figure it out again. You can only minimize the damage, never eliminate it, but on a site like the one I work for, if we've got only a hundred people sending fake scores, out of the hundreds of thousands we see every day, we consider that well within the realm of acceptable. (We still crush those we catch cheating, but we don't consider it much of a problem.)

You could at least throw out scores that are above some threshold that you would deem legitimate. It still leaves room for more subtle maniputaion of a high scores list, but will at least help relieve the obvious frustration of seeing an impossible to achieve score topping the charts.

Related

facebook/gmail alike web chatbox - what is a good way for nowadays chatapp to store text message?

I'm currently building a facebook alike chatbox, and I have encounter several considerations and problems along the way.
I had been googling useful resources all the time,like simple chatbox example or tutorial online.
My goal is to build one just like facebook/gmail chatbox and CometChat, I know it's hard and too much thing to scale behind the scene, but all I want to do is building it as simple as possible, and figuring out how facebook/gmail chatbox implement their chat functionality.
Progress:
I have finished facebook-like chatbox structure where I have sidebar at the right displaying online friends i can chat with, and popup chatbox at the bottom, and it is able to expand and minimize it.
I also have finished simple chatting based on MySQL database.
There's a table with 4 columns 'sender', 'receiver', 'message', 'time' for storing conversation.
My chatbox works this way:
1.The user send a message, and my front-end javascript will fetch the message the user type in and send the message to php file on the server via Ajax.
2. backend php file will store this message to MySQL.
3. The front-end will call the update function every 3 seconds to update the chatbox content if receiver send message to the sender, and show it out in frontend's chat.
I'm not sure this is a good way and long way to do, and I'm really concerned about it.
If users grow and grow, I have to think of ways to scale it well or my database and server will explode and frontend users might feel high latency in updating conversation.
Is BigTable a right way to do this if you have millions of users online?
How does facebook store their customer's text message or chat history in the backend well??
How does chat app like Whatapp store their text message?
Is it able to let the users chat directly to another user without storing state in server?
If I want to implement the chat history functionality in my chatbox, what is a good way to do ??
I am thinking server can create .txt file for each conversation in their file system, and it has a database table column to store the file path. Is this a good way and right way to do with chat history, I know its possible to do it this way, but im not sure if its a right way or good way.
I know this could be a huge, detailed application.
I'm asking not a detailed implementation but a big picture, concept of building it!
thank you!.
That's a good question and here's an attempt at answering it.
I believe you are thinking about scalability a bit too early. Your IM app might not reach the projected number of users for it to stop performing well. Consider enhancing your small product and scale as you go as much as is needed.
Disk I/O is one of the issues that you will face scaling your web application. Storing communication directly onto the disk with txt file might not be a reliable solution.
Push your technology stack to its limits before considering changing it or switching to something else. I assume you are using a relational database for your storage (since you mentioned columns and rows, which is not an ultimate indicator but still), there are other options out there that have good benchmarking results at the expense of multiple other compromises. (NoSQL: which you referred to as BigTable) is one option. Relational databases are great, they have been for quite a long time the industry standard but currently there are alternative solutions that are quite promising.
Look into NoSQL document based datastorage solutions such as MongoDB, CoucheDB or even Casandra and there are many others. There is a considerable amount of information about the performance of each, under specific circumstances and situations. Choose what is best for the problem at hand and not what is most fashionable or hipped.
Another option would be to outsource your scalability problems to a 3rd Party provider such as Firebase. In this situation all you have to worry about is your product and not what's happening under the hood.
Store only the data that you need and archive or dismiss what you don't.
With scalability there are generally 2 broad categories: Horizontal and Vertical scaling.
Horizontal: means adding more nodes to your system i.e. adding more server instances to handle the extra load. There are many cloud solution providers out there that make this genre of scaling very cheap and instantaneous.
Vertical: means adding more resources to the node you are currently running your app from in addition to use specific technologies that allow you to take full advantages of your resources. This optimization happens on the level of the instance resources (i.e. CPU, RAM, Disk Space etc...) and your data storage, programming language of choice, algorithms you are using etc... You might realize that php and mysql aren't the tools for this job, but that's arguable.
Read More about it here
Distributed Systems architects / programmers also take advantage of other (faster) programming languages at runtime (such as C, C++ or even Java) to speed up certain tasks. Look into how you can dissect your application into smaller decoupled modules / components that can run independently. (But i'm not sure if you will ever reach this stage with an IM client unless it becomes as popular as Whatsapp or Facebook chat).
I advise you to grab and read a couple of books about scaling web applications and leveraging cloud computing. Study scalable architectures and design your application depending on your business logic based on them.
This is a very broad and complex topic, I'm sure others might have additional interesting insight on the matter.

How do I make a post using libcurl from a game written in c++ to a php page on my server more secure?

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.

How to disable the same person to play my RPG game as two different persons?

Of course, I store all players' ip addresses in mysql and I can check if there is a person with the same ip address before he registers, but then, he can register to my page at school or wherever he wants. So, any suggestions?
The only way that proves particularly effective is to make people pay for accessing your game.
Looking behind the question:
Why do you want to stop the same person registering and playing twice?
What advantage will they have if they do?
If there's no (or only a minimal) advantage then don't waste your time and effort trying to solve a non-problem. Also putting up barriers to something will make some people more determined to break or circumvent them. This could make your problem worse.
If there is an advantage then you need to think of other, more creative, solutions to that problem.
You can't. There is no way to uniquely identify users over the internet. Don't use ip addresses because there could be many people using the same ip, or people using dynamic ip's.
Even if somehow you made them give you a piece of legal identification, you still wouldn't be absolutely sure that they were not registered on the site twice as two different accounts.
I would check the user's IP every time they log onto the game, then log users who come from the same IP and how much they interact. You may find that you get some users from the same IP (ie, roomates, spouses, who play together and are not actually the same person). You may just have to flag these users and monitor their interactions - for example, is there a chat service in the game? If they don't ever talk to each other, they're more than likely the same person, and review on an individual basis.
If its in a webrowser you could bring the information like OS or browser but this even makes it not save but still safer.
It would take the hackers only a little more time and You have to look for the possibility that some people could play on systems with the same OS and browser
The safest thing would be that people on the same IP cannot do things with each other like trading or like in the game PKR (poker game) that you cannot sit on the same table.
An other thing would be wise to do is to use captcha's, its very user unfriendly but it keeps a lot bots out
If it is a browser-based game, Flash cookies are a relatively resilient way to identify a computer. Or have them pay a minimal amount, and identify them by credit card number - that way, it still won't be hard to make multiple account (friends' & family members' cards), but it will be hard to make a lot of them. Depending on your target demographic, it might prohibit potential players from registering, though.
The best approach is probably not worrying much about it and setting the game balance in such a way that progress is proportional to time spent playing (and use a strong captcha to keep bots away). That way, using multiple accounts will offer no advantage.
There are far too many ways to circumvent any restrictions to limit to a single player. FAR too many.
Unless the additional player is causing some sort of problem it is not worth the attempt. You will spend most of your time chasing 'ghosts' instead of concentrating on improving the game and making more money.
IP bans do not work nor flash cookies as a control mechanism either.
Browser fingerprinting does not work either. People can easily use a second browser.
Even UUID's will not work as those too can be spoofed.
And if you actually did manage to discover and implement a working method, the user could simply use a second computer or laptop and what then?
People can also sandbox a browser so as to use the same browser twice thus defeating browser identification.
And then there are virtual machines....
We have an extreme amount of control freaks out there wanting to control every aspect of computing. And the losers are the people who do the computing.
Every tracking issue I ever had I can circumvent easily. Be it UUID's, mac addresses, ip addresses, fingerprinting, etc. And it is very easy to do too.
Best suggestion is to simply watch for any TOU violations and address the problem accordingly.

Pass information to php file from javascript while restricting user from doing it their self?

I am making a game where the battle system uses javascript to battle. At the end of the battle you either win or lose. If the user wins, I need to update the mysql database with the XP they earned.
The best way I can think of doing this is to have the javascript run an ajax function when the user wins that POSTs something like addxp.php?amount=235, but if I do that then the user can easilly look at the source and see that they can just enter in that page themself to update their xp without battling. But this is the only way I know how to do it?
Help please :-/
If you rely on the code running on the client's web browser to update the battle results, you do not have control over that code. Many javascript and flash games that have a high score board that depend on the browser sending in the high score registration are vulnerable to this. There is no real easy way around this.
You can try to obfuscate things somewhat, but someone who's interested enough is going to be able to fairly easily get around this.
As knoopx mentioned in his comments, the only sure-fire way to get around this is to do computations server-side. For example, the client browser sends user actions to the server, and the server is the one that determines the outcome of the battle, inserts the result into the mySQL db, and sends the result back to the client. This is obviously a major architectural change and you'll have to decide whether it's worth it.
This one is tricky and unfortunately there is no easy solution. I can give you some advice that helped me when I was creating a flash-game with a cash-prize. It worked quite well for me, but again - it was by no means full proof.
First of all do some thinking about the highest score it would be possible to achieve over a given time period. For example, you could say that the highest score you could reasonably get after playing for 1 minute is 200 points.
Each time someone starts playing the game, you do an AJAX call to your server to obtain a game ID. At set intervals (say 10 seconds), you make your game phone home with the game ID and the latest score. This way the only way to cheat would be to create a script that periodically contacts the server with a slowly incrementing score that falls under your maximum. Not a difficult thing to do, but at least now we're entering the territory where we've eliminated the casual louts with TamperData and a few minutes to kill boredom with.
Another thing you can do when you send back the current score is the current status of the gameboard. This isn't so useful for catching cheats live, but it's a very good tool you can use when awarding a prize to check that the high-score is a genuine one. This adds another layer of complexity to your system and hopefully make some of the more slightly-hard-core louts get bored and find something else to do.
My last suggestion is this - you in no way make your users immediately aware of what you're doing. That is to say, that if someone's score falls above your high-score/time threshold, you do nothing to let them know that they've tripped your cheat-detector. In the game I created, I even recorded their high-score along with their cookie. When getting the highscores from your database you SELECT * FROM scores WHERE cheated = FALSE OR cookie = userscookie. This way, unless they clear their cookie and check again, it will appear (only to them) that their hack attempt was successful.
Oh and one last thing; minify your javascript. This will obfuscate the code and make it very hard to read. Again, someone determined enough can easily circumvent this and look at your code, but it's all about making your system complex enough that people won't bother.
Unfortunately the web's strongest point can sometimes also be its weakest. It is the nature of the WWW that source code is open and available for anyone to read, which means that keeping secrets from your users is very hard if not impossible.

Thumbs system on Urban Dictionary

I was thinking of implementing a thumbs system, but mine would require a registration thus ruling out the possibility of people voting more than once unless they create a new account to do so. So I was wondering about Urban Dictionary's thumb system. How does it work? I would imagine that my IP would be stored in a database, so people would not be able to vote more than once however IPs do change pretty often and especially when you're on an iPhone. Probably a combination of cookies and IP checking. Can anyone give me a better insight? What would they check for to ensure you don't vote more than once?
The reason I ask is because I may want to make my a public system instead. Maybe even a hybrid, similar to SO where you can ask a question before creating an account and then have the two linked together. I am using PHP and MySQL.
Almost always it's done with cookies. As you say, IPs can't be used (naively) as they change, or cover too many people (i.e. everyone in a given office, etc).
But online polls not reliable anyway, so don't get too concerned about solving a problem no-one cares about. You can implement more 'intelligent' rules but then you need to ask what benefit you are getting for all your work.
Personally, I would go with:
Cookies
Forced signup voting
Some sort of analysis of voting patterns
Because it goes without saying that people can just sign up constantly, to submit more votes. It really depends on what benefit people get from voting, and how much you care (in terms of time, which is, obviously, money).
I know urban dictionary allows for more than one vote per day. Once every six hours to be exact.

Categories