OpenBracket

As a game developer myself, one of the biggest fears I have is that someone is going to end up hacking my game and ruining it for everyone else. So, seeing that I am a member of a PBBG game dev board (here), I posed the question to the community;

How do people cheat in web based games other than using bots? Do they manipulate URLs or text boxes? Or is it mainly exploiting bugs?

Not long after the question was asked, I received a reply from one known as Nerdmaster(site). Now, the following is not the end guide to securing your game, but it does a damn good job of outlining ares where common problems occur.

But before that I will tell you the best way to prevent hacking which will be re-enforced as you read the reply: Don’t trust user input. You must always make sure the player has supplied you with legtimate data.

As a long-time security hobbyist, I have learned a few minor tricks for exploiting web games, and I was very successful with Mobster World (as I already mentioned). The most important rule is NEVER trust anything user-submitted without validation. URL arguments, form arguments, cookies, etc are all *very* easy to manipulate.

In mobster world, for instance, there was a place to go and buy guns. The page would load up a form, and you’d choose the gun you wanted. It did something with hidden fields to where your URL would just hit something like /buyweapon.php, and I guess the admin thought that made it secure. But if you looked at the form, it was sending across a few values. One was itemcost=xxx and one was weaponid=xxx. You could set itemcost to 1, and get any weapon for a dollar. These hidden fields were the worst kind of exploit because they would be so easy to fix – don’t rely on the user to supply the price; look it up based on weaponid!

Another problem with that game stemmed in the messaging system. When you read a private message, it would generate a URL like this: “/messages.php?action=read&id=xxx”. You could read *anybody’s* messages this way, just by changing the id in the URL. This was a case where user-supplied input should have been validated (and eventually it was, but by then the game was being exploited so much, it was too little too late). A simple if block fixes this – if message id xxx doesn’t belong to the currently-logged-in player (via session data or whatever auth method you use), DON’T SHOW IT!

Then there’s the issues with things like pulling off jobs – when you went to the “big jobs” option, you usually had two options. One was going to be successful and one wasn’t. By viewing the form, however, you could always tell which job would be successful. NEVER put that kind of data in the forms – you want to make random decisions happen only *after* the user decides what to do, never before.

Another issue is with SQL injection. In PHP this can be a problem because a lot of the examples you’ll find on the internet don’t properly handle SQL code. PHP has some stuff for automatically escaping quotes and such, but you can’t always rely on the server settings for your app, so it’s something you need to at least be aware of. I don’t know enough about SQL injection, but in a lot of languages, you have access to special DB commands where you use a ‘?’ in place of arguments and they get scrubbed by the DB layer so you never have to worry. If you have cookies that don’t get auto-scrubbed by PHP, this kind of knowledge can be very important.

Another important tip is do *not* store simple information in cookies. For instance, say you want to know who is logged in but you obviously do not want the user to have to log in on every page. If you take the quick way out, you might have a cookie that holds the user’s id. Well, once a user realizes this, they just change the id and become anybody they want! Similar issues can arise with cookies that store session ids (since those map to the server-side data for logins), but generally it’s much much safer to use sessions for storing login credentials than using cookies.

A final tip is to be careful of XSS attacks. In Rails there is a function (I think it’s from a ruby library, not specific to rails, but I don’t recall which library) that auto-scrubs data to keep html out of user input. The issue here is that if your users can put in angled brackets (“<” and “>”), they can very effectively destroy the game for everybody else. In mobster world, I used this technique to create a private message that would add a button to the form that seemed to be the normal “Delete Message” button. But when clicked, it would take that user to the “shoot another player” action, with a specific player id of somebody I wanted to torment. I never actually used this cheat, as I started feeling bad, but I tested it with a friend, and by cleverly constructing emails I could force players to take actions of any kind within the game. More malicious hackers can do a lot worse, such as hijacking passwords for other sites. I’m not sure how that happens, but the point is that you need to find a library in your language of choice that you use to scrub html out of user data. If there is data ANYWHERE in the game that one user enters and other users see, it *must* be kept clean of HTML. You could theoretically allow only certain HTML, but with all the very clever uses of html that can exist, I think it’s safest to just not allow users to enter HTML. In my Rails game I use RedCloth (a Ruby library to the Textile markup system) to allow users to do formatting without having to worry about XSS attacks.

For an example of how easy it is to have dangerous XSS even when you think you’re safe, watch this. This site’s forums allow “safe” HTML. You cannot, for instance, do a <script> tag:

<script src=”http://www.nerdbucket.com/js/common.js” type=”text/javascript”></script>

But you can use some tags, such as bolding, as I just did. Well consider this – inside a bolded element you can specify onMouseOver behavior. Hover your mouse below and watch as I change the element text (only works in DOM-capable browsers):

or am I?’;” id=”foo” style=”font-size: 150%”>I’m a safe HTML tag.

If somebody more malicious wanted to, they could probably hijack cookies and passwords from this forum. (Obviously I’ll have to alert the admin).

Now, you have the basics of how some attacks are made, you may be wanting more specfic examples with more detail. Well you’re in luck (as was I).
Not long after I asked this questio, Nerdmaster wrote a much more detailed description using an example in his blog (here) If you want a rather more details and examples of how people hack web (PBBG) games, you best check that link.