1

I have a mobile application, for Android and iOS (both native), that communicates with the backend through a REST API (over HTTPS).

The application allows users to sign in or use the app as a guest, but in both cases I need to track user's activity based on which we send them push notification. The activity is also used for statistics on daily installs and daily usage.

In order to do so, the first thing the application does on startup is to check if it has a device UUID set, and if does not it sends a "register-device" request to the API which generates a new UUID and stores it into the database. The generated UUID is returned to the app and stored persistently. The app then sends the UUID within each request. This allows us to know how many devices/users use the app, daily activity and if available, the device's push notification token.

This works relatively well but I have some concerns regarding security. Let assume that some one is able to deobfuscate the app and gain the API key. With the API key he can access the API in the same way as the app can and can start sending thousands of "register-device" requests, which would fill the database and gradually decreasing API performance.

Is there any way to overcome this issue? I could generate the UUID on the client side, but that would lead to the same issue - the attacker would just need to generate a valid UUID and send it to the API.

Improve this question

1 Answer 1

Reset to default
1

Here is a list of tips/techniques that you can use:

  • If users are authenticated and you assign a unique uuid, just allow one TCP/HTTP/HTTPS connection for a given uuid. By doing this, you will limit the number of connections to your service that can use the uuid.

  • If somebody wants to reuse a uuid or do a "uuid attack" by flooding from requests you can use a basic rate limiting in combination with a IP dropping/blocking rule on a firewall.

  • On the generation of your uuid use a good crypto library that generates real random numbers, you can also use the last 8 bytes(for example) to do a hash of ip + user credential in the case that your random generator is not good. For example: <8 bytes random>-<8 bytes random>-<8 bytes random>-<first 8 bytes of sha256(ip + user cred)>

Hope it helps

Improve this answer
1
  • so rate limiting is the only viable counter measure against this kind of attack? Limiting number of connections per UUID doesn't sound like a good option as it can result in valid requests being limited (and since rate limiting would already drop too frequent request). Generation of UUID on the server is really not an issue since I can check for collisions while generating it. I wonder how other services, such as firebase, handle this sort of issues.
    – blejzz
    May 27, 2019 at 9:48

You must log in to answer this question.

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