13

Say there is a frontend mobile app and a backend server (let's call this service MyApp) which hosts an API for the mobile app to connect to. The backend server makes any needed requests to third party APIs and only send what's needed to the mobile app, and there is token based authorization so only what the user is allowed to see will be able to see it. Assume there is also a paywall for certain features so only certain users have access to certain endpoints and their data if they have paid.

The problem is this: there is nothing stopping a talented hacker from paying for a legitimate account on the mobile app and extracting the tokens regularly (even if expiry is a few days or so), and creating his own server where the server makes API calls to the MyApp backend using his account tokens: now his own server can save the responses and content, and redistribute the data to his own client that he can sell and monetize.

My question is, is there any way to prevent a hacker from redistributing data that he has access to on his legitimate account? If the data is "archivable", as in anything that is static like news articles, videos, images, statistics, etc can be fetched by his own server retrieving the archivable data from MyApp's backend servers at some intervals (technically his account has authorized access since he pays for the content).

This question comes close to "can I prevent piracy" essentially, but I would like to know if there actually is no way to prevent this in the examples I provided.

6
  • 25
    TOS and lawyers. Google Maps says you can't save map data you get from them to do things with later (maybe some exceptions, but it's unimportant for your context). Look for fishy behavior and cancel their API access. Commented Apr 22 at 14:00
  • 2
    @Michaelcomelately That sounds like the best course of action. Thank you.
    – Jiehfeng
    Commented Apr 22 at 16:05
  • 1
    This doesn't address your question as posed but it's a technology that you might be interested in: en.wikipedia.org/wiki/Homomorphic_encryption
    – JimmyJames
    Commented Apr 23 at 15:19
  • Note that one of the biggest tech company, Google, tried to enforce ads on YouTube. It didn't go well for them. It might be way more economically viable to simply let those bypass your paywall than to actively block it, unless your content is worth a LOT, then you can sue those that release it without permission more effectively than a technological solution. This "answer" isn't a security solution, so I don't feel it makes sense as an actual answer.
    – Nelson
    Commented Apr 24 at 8:55
  • 1
    @Michaelcomelately of course, that only works for businesses in developed countries friendly to the US. If someone hosts your stuff in China or Russia... good luck! Commented Apr 24 at 23:25

6 Answers 6

31

It's not something you can do with technology. As soon as the data leaves your server, it isn't your data anymore.

There are several ways a malicious user can extract data from your application:

  • decompile the application and extract the keys, using them to talk direct to your server

  • patch the application to send the data to another service or save to disk

  • patch the application to use an user-supplied certificate and use a proxy to capture network traffic

  • run the application on an emulator and inspect it remotely

  • run the unaltered application on a unaltered phone and use software like Scrcpy to do screen capture and OCR

You can prevent an user to capturing a large amount of data by employing rate-limiting, monitoring, and blocking abusive users. Instead of having an access token be valid for some number of days, you can make it valid for some number of requests, and start requiring a captcha after too many refresh tokens get issued in a short time.

This prevents the user from acquiring more data, but will not stop him from sharing the data they already got.

5
  • 1
    Right figured as much, thanks. I will be looking into rate limiting and whatnot, it is what it is I guess.
    – Jiehfeng
    Commented Apr 22 at 16:06
  • 3
    Two more possibilities: run the unaltered application on an unaltered phone while another camera is pointed at the phone's screen, or someone with really good memory might observe some information on the phone's screen, move out of sight of the phone's camera, and then transcribe the information onto a pad of paper.
    – supercat
    Commented Apr 22 at 22:01
  • 3
    You can also charge per request (instead of a single payment or for a time-limited access) and set the rate low enough that it doesn't hinder the legitimate users, but too expensive for bulk usage.
    – Trang Oul
    Commented Apr 23 at 10:32
  • 8
    @TrangOul most people are comfortable signing up to a flat rate of $x a month, but not a variable rate dependant on usage - less so b2b but especially true for consumer software. I'm sure you'd scare away a lot of users with such a model, even if technically it was cheaper. People like to know what they are spending upfront.
    – James T
    Commented Apr 23 at 13:15
  • * Use a MITM attack on their own end and capture the data as it's transmitted to the application. Commented Apr 25 at 13:02
21

This is a classical Digital Rights Management (DRM) problem.

There are no definite solutions, not even in your particular scenario. DRM techniques can make it more difficult to distribute data, but they're are never fully effective. Even worse, the more aggressive the techniques are, the more you affect perfectly legitimate use cases.

One option that might be relatively effective and not too intrusive is watermarking and fingerprinting. This allows you to pinpoint the user who has distributed your data illegally (assuming they haven't managed to detect and remove the watermark). You can then try to sue them. If your users know about the watermarks, this may also discourage sharing of data to some extent.

4
  • 3
    I agree, definitely do not want to inconvenience users in the battle, I've seen it happen with Denuvo in games for example. Watermarking is a good idea, but could it be used for textual data, maybe JSONs? Data sometimes that is sensitive is just text form, so not sure how it could be done. One idea I have is if some fields are unused, they could occasionally be changed to different values and be tracked to see if anyone has that version.
    – Jiehfeng
    Commented Apr 22 at 16:13
  • 7
    @Jiehfeng: Possibly. See e.g. en.wikipedia.org/wiki/Canary_trap and the various links therein. With JSON, you can e.g. permute the order of fields, change whitespace, etc. (With the risk somebody would normalize the data.) With textual data, you might modify the punctuation or spacing. (With some disturbance of the content.) Etc.
    – Mormegil
    Commented Apr 23 at 8:18
  • 4
    @Mormegil the risk that someone normalizes the data is fairly high, many JSON libraries either offer a "sorted" fields option, or just put the fields back in arbitrary order -- typically matching the order of iteration on the hash-table in which they store the fields. Text is different, but JSON may well be considered hopeless. Commented Apr 23 at 13:34
  • 1
    @Jiehfeng Yes, a canary trap (as mentioned by Mormegil) was used recently by a footballer's wife to work out who disclosed data from her friends-only instagram feed. en.wikipedia.org/wiki/Wagatha_Christie Commented Apr 23 at 18:45
4

While you can hardly prevent the user from reusing and retransmitting any such data, beyond the measures given in the other answers, one thing you can do is monitor usage patterns and/or limit usage.

This can take several forms:

  • Have rate limiting, so that a given user/token can only make so many requests per second/minute/hour/day/whatever. Beyond those limits requests are blocked, until the usage comes back within the limits. You need to find the right balance, so that you don't block legitimate requests, but block what seems to be way beyond a regular user's pattern. You would probably be on shorter periods (minutes, hours...) in this scenario.

  • Simply monitor patterns. Likewise, set thresholds, and when they are exceeded, either start investigating the user, or block them immediately. In this scenario the block would not be temporary, but either permanent or a long duration. You may trigger e-mails reminding them of ToS, etc. The periods here would probably be somewhat longer.

  • Have a pay-per-use model, possibly with multiple tiers.

You indicate the backend server makes requests to third-party APIs. Check what they do. In many cases the limits are there more to avoid using too many ressources (CPU, network...), but sometimes there is also an implied or explicit goal of limiting the overall number of requests to avoid copy and redistribution.

1
  • 1
    I would add that rate-limits can (and should) include multiple periods. Allow for short bursts (30/min) but then prevent continuously bursting (120/hour, 240/day, etc...). Commented Apr 23 at 13:38
1

As other answers have already stated, there is no perfect solution to this problem... but you can make life more difficult for someone trying to fetch all of your data programmatically. At some point, the effort to steal the data will become too much for the reward of having the data.

My first thought is to encrypt the responses sent by the server and decrypt them within the client using a pre-shared key. This should be enough of a barrier for most would-be thieves. Don't store the key as a file that can be easily pulled out of your app's bundle. Rotate the keys frequently and issue them per-client.

If your data is of utmost value, someone will put in the effort to get it anyway.

1
  • Encryption is covered by another answer
    – schroeder
    Commented Apr 24 at 19:03
0

Another possibility you would need to worry about is the account being shared with many others -- think password sharing & Netflix.

Typically, the token should identify an account, possibly an account on a specific device. A user may legitimately use their account from both, say, mobile and tablet at the same time, but they shouldn't be using it from 100 devices scattered around the world.

Detecting the device is complicated: whichever fingerprinting method you'd attempt to use can be emulated.

Detecting the IP or location however is feasible.

If you make the token relatively short-lived, then you can move all the IP/location checking into the token-renewal service, which is typically less latency-sensitive.

And there you can:

  • Rate-limit the amount of IPs the token was seen from, even with a proxy / mobile user, you should be able to find an alert threshold which works.
  • Check that locations make sense (roughly). It's normal for a moving user to change location, but they shouldn't be bouncing between cities.

When a user account clearly exceeds the thresholds, you may want to suspend it.

4
  • 2
    Binding a token to an IP can be problematic: many people (in corporate environments, or on mobile networks) go through proxies or CGNAT devices which may use a pool or public IPs, so the IP can change quite quickly. Likewise for people on mobile switching from cellular to WiFi and back. Still a matter of balancing limits with real life.
    – jcaron
    Commented Apr 23 at 14:48
  • @jcaron: You make a good point with NAT, the application may not even know which IP to request a token for. I'll alter the answer. Commented Apr 23 at 14:51
  • 2
    The application does not need to know the IP, the server will see it, but it may change.
    – jcaron
    Commented Apr 23 at 14:53
  • @jcaron: Yes, but this may or may not work. That is, if the token is emitted as part of a separate call, the application may talk to the server from a different IP for the token call and the actual "functional" call. Commented Apr 23 at 15:14
-2

As the old saying goes, "He who has con has root." Which is: Anyone with physical access to a computer can be presumed to eventually have full access to a computer.

I can put an oscilloscope or a logic analyzer directly on the wires between your mobile device's CPU and its RAM. I can observe every bit in transit, every byte in memory, and all it takes is a little bit of my time. You have no way to even know that I'm doing this: The physical existence of the wires themselves is the side channel by which I get whatever data I want.

A device like the iPhone attempts to block such attacks by putting really secure stuff inside the hardened "Secure Element" chip, which is designed to self-destruct if somebody applies acid or sanding to remove the surface and look inside.

And even there, side-channel attacks exist against the magnetic fields leaving the device. When the hardware is leaky, what do you really think you can do in software to keep the bits inside the box? And I can probably get to the data without even the hardware hacks by just rooting the OS. I have con, so if I want it, I can get root.

Against all this, there's not much you can do. At best, you can prohibit the device from getting access to your data at all: Either don't send the data, or encrypt it, and if you encrypt it, it has to be non-user-accessible encryption: If the user can decrypt it (which they often need to do to, y'know, use your software), then the user can also find a way to access it. Period. No exceptions.

So once those bits leave your server? Assume there can be an infinite number of copies of them and develop your software accordingly.

3
  • 3
    This all-or-nothing approach is completely useless in OPs likely case. Because simply making it too hard to efficiently scrape is enough of a bar to clear for this scenario. We just need to make it cheaper to gather OPs data on their own rather than to steal it.
    – Hobbamok
    Commented Apr 24 at 14:02
  • @Hobbamok The question was how to protect content, and the answer is that realistically, you can't. If the content is short-lived, like live video, that might not be a relevant concern, but if the content — like most content — has considerable value long after it's been stolen — like a movie, a song, a book, or an article — then an attacker only needs to access it once to win. That means that in most cases, the costs are wildly imbalanced: The defender has finite resources, but the attacker can spend as much time/energy/money as it takes, and OP can't win against that. Commented Apr 24 at 15:44
  • 3
    sure, but I doubt that OPs data falls into the "eternally valuable + unrecreateable" category. And therefore it's sufficient to make it easier/cheaper to legally produce equal data than to steal from OP. Because otherwise your conclusion is to just do nothing, which is ridiculous
    – Hobbamok
    Commented Apr 24 at 16:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .