0

Assume we have a client-server application communicating over the net, with client side written in javascript (so pretty much opensource). Let's say for example that we want to run multiplayer in-browser game and gather some revenue from ads. We want to stay in business, so we keep secured the server part, which handles most of the logic, and we accept that frontend/UI handling client is thrown into the wild and might be messed with by anyone.

Question is: how to detect and prevent the situation where someone copies all public facing content of web app, including JS client, puts it on his/her own server with his/her own advertisements, potentially malware etc, while the 'hijacked' client still talks to our original server?

Or perhaps that's just silly and there is some obvious reason why such behaviour would not work (that might be why I haven't found anyone mentioning it)? I'm feeling like I'm missing something there, but nothing in my experience so far tells me that hypothetical situation from the paragraph above would not be possible or even profitable for a highjacker.

zencodism
  • 442
  • 4
  • 9
  • Look at where the requests are coming from... – epascarello Jan 28 '14 at 15:35
  • How does the client talk to the server? For most cases the Same Origin Policy would already prevent JS on `other-domain.com` from talking to your server anyway, unless you've worked around that deliberately (CORS, JSONP...) – bobince Jan 29 '14 at 07:45

2 Answers2

2

You can't really prevent people from using your client to connect to their own server. It's been done with MMORPGS for a long time, even when they have compiled fat clients. Of course, in those cases, people had to re-write the server code from scratch.

To prevent people from blocking your ads, you could set a timestamp per client whenever you serve an ad. If the client is still connected but hasn't requested a new ad from the server for some time, all kinds of things could go wrong - for example, your server might modify dice rolls against that player so he'd die a horrible death on all but the easiest monsters. This is in your server code, so can't be messed with, and the guy who copied your code would run out of a playerbase quite quickly.

The important thing about this approach is to NOT give the client a clue that and why it's on the rogue list. Not knowing what to fix makes it much harder for the attacker to "fix" the changed code.

Guntram Blohm
  • 9,667
  • 2
  • 24
  • 31
  • So what prevents them from just hiding the ad. ;) – epascarello Jan 28 '14 at 15:46
  • If they just remove the ad, like an ad blocker would do, or change the ad code to read the ad from somewhere else, the original server won't get eequests anymore. Moving it offscreen would work better, but the attacker has much less to gain from "moving the ad offscreen" than from "showing his own ad". You can't really prevent a determined attacker from figuring everything out, but you can try to decrease his frustration/gain ratio. – Guntram Blohm Jan 28 '14 at 15:53
  • Few nice ideas, but you are considering different problem: someone re-writing the server itself instead of using mine from other source. Upvote for the lore though :) – zencodism Jan 29 '14 at 12:40
0

I will turn my comment into an answer. The request has a referrer, you validate against the referrer. That is what happens when you request api keys from different services.

Community
  • 1
  • 1
epascarello
  • 204,599
  • 20
  • 195
  • 236
  • Good point. Then, how big a problem referrer spoofing would be? http://en.wikipedia.org/wiki/Referrer_spoofing – zencodism Jan 28 '14 at 16:18
  • If the user pushes the requests through their server and changes the referrer than there is nothing you can do about that. There are a bunch of other "hacks" you can implement in your code, but if the person wants to get around your stuff they will. – epascarello Jan 28 '14 at 16:25
  • I guess that's as good as it gets, no magic silver bullets :) – zencodism Jan 29 '14 at 12:41