Protect API from being tampered?

Question

I'm building an API with websocket that serializes data through JSON. The App itself is a chat application. I came up with the following structure to send my data:

{date: '2020-05-31', time: '14:28:05', text: "Hey!", to: '<id:int>', from: '<id:int>'}

The user basically sends a message through the browser and this is received in a websocket server. The from: 'id' would be from the user sending the data whereas the to: 'id' would be to the user the data is being sent.

Looking at this I have a very bad feeling. My thoughts; The user using the App would in theory authenticate and that's where he would get his id. Then the receiver would have another id, such that is not the same as the authenticated one (obviously). The server would then look for that id and send the message but I'm not sure if this is secure.

I have some aspects that I think must be dealt correctly to protect the app from any attacker:

• What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user?
• What if the attacker builds a script that spams millions of messages by taking advantage of the "to:id" field?

Is it possible there is another security issue that I'm not concerned of?

Answer 1

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user?

Create a session, and use the session identifier as identifier, not the user ID directly. E.g. let user send credentials, and upon successful validation, return a (short lived) session handle, that can be used in future messages.

Validate that the session exists and is active, and map it back to user server-side.

What if the attacker builds a script that spams millions of messages by taking advantage of the "to:id" field?

Rate limit users server side. For instance, disallow sending messages to more than ten different users a minute. This will probably not bother legitimate users, but will hamper spammers efforts. Tuning of the limit may obviously be needed - and it may be an idea to raise it for trusted users, based on behavior, and lower it upon receiving reports about spam from users.

Answer 2

Basically, you have to treat every input from the user as potentially malicious.

Vidarlo has already mentioned two security issues and how they can be prevented in his answer.

I'd also add that the content itself ("text:") could contain malicious code (e.g. javascript snippets). Make sure that this code is not executed on the receiving end.

And I'd also check if the time seems correct. Depending on your application, having verified timestamps could be useful or even necessary.

Answer 3

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user?

Do not use from:id in your API. You already know it from user authenticated session instead and have zero reason for user to transmit it to you in the first place. And if there's nothing to transmit, there's nothing to tamper.

On that note, throw away date and time too. You already know when you've received message and don't need user to tell you that. You only'd need those if your application+API have some concept of offline/scheduled/backlog messages.

What if the attacker builds a script that spams millions of messages by taking advantage of the "to:id" field?

That's pretty old, even classic problem that have different, just as old solutions. One of the simplest is to introduce a timeout: backend remembers when the use sent a message and he can't send anything until some period passed. Some more complex solution still boil down to limiting user to some amount of messages per some period of time, but use progressively larger delays that fall off with time as more messages are sent in. Search for "throttling" or "rate limit" for some examples and ideas.

Answer 4

Here's a slightly alternative view of how these issues could be tackled. I am assuming that authentication and session management is implemented properly.

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user?

If you generate a unique (long, random, very difficult to guess, like a session identifier) identifier for each "chat room" at the time of creation and make sure all parties are happy to join that chat room, you could use that instead of user identifiers and control which chat rooms each user could message, to ensure that others cannot send content to someone else's private chats; So your messages from users X and Y would be issued to chat room A and the application would send them across. User Z has not been allowed in so the application refuses to pass the message.

What if the attacker builds a script that spams millions of messages by taking advantage of the "to:id" field?

Make sure that messages cannot be addressed to user identifiers and work towards making user identifiers difficult to guess.

Answer 5

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user?

Another option is to give each user a set of public and private keys. These can be used to generate a signature for each message which verifies the contents haven't been tampered with and originated from the specified user.

Let's say user 1 wants to send a message to user 2, a simplified process would be:

• user 1 is given a public/private key pair. They (or the server) expose their public key to other users.
• user 1 creates the message content and then generates a signature for it using their own private key (they keep this secret)
• user 1 sends the message in a packet that looks something like

{ "Signature": "kA7dagf4...", Content: {date: '2020-05-31', time: '14:28:05', text: "Hey!"...

• user 2 receives the message and then uses user 1's public key to verify the message content matches the signature

The key thing is that the public key can only be used to verify the signature - it's not possible to create a signature without the private key.

Any malicious actor who wants to impersonate user 1 and send a message to user 2 would be unable to, because they won't be able to create a signature that is verified by user 1's public key. So user 2 would see the signature is invalid and be able to reject the message when they receive it.

This is roughly how JSON Web Tokens work - I'd suggest reading up on that for more information - https://jwt.io/introduction/

What if the attacker builds a script that spams millions of messages by taking advantage of the "to:id" field?

As mentioned in previous answers, a combination of rate limiting and making the to:id and from:id fields difficult to guess.

Answer 6

There are numerous security issues in your approach, most already pointed out in other answers.

I want to answer with general principles that will help you find these issues by yourself.

treat every user-supplied data as malicious

everything coming from a client is untrusted. It needs input validation, trimming, escaping, the whole nine yards. In your case, your app probably sends proper JSON, but what happens in your API if someone hand-crafts a JSON and gives you invalid JSON, doesn't terminate the string or mixes SQL injection in there?

never take input on data you already have

as pointed out in other answers, you already know the date/time and the "from" ID, so don't accept them as input. In general, never accept input on something that you can get from a more trustworthy source.

SWIFT approach

go through every element and ask yourself "what could possibly go wrong?". SWIFT (here or several other sources) is a structured way of doing that. Essentially, once you've reduced your input to text and to-ID, think about how someone could abuse those. Could he send wrong data, too little data, too much data? This approach should land you at the threats outlined in other answers, such as enumeration, flooding/spamming, etc.

consider your backend system

finally, know the weaknesses of your backend system. If you have an SQL database behind, think if there are possibilities for SQL injection. Also think about performance and system limits - can a user potentially send so much data that it overwhelms your I/O, your processing or your storage capacity? Can he block the API for other users (what's your parallel processing limits? how many connections can you handle, etc.)

While that's not a full threat modeling approach, I find that it serves 90% as good with a small amount of the full effort.

Answer 7

An obvious one is that the data is not encrypted. You've already mentioned tampering and often encryption and integrity are addressed at the same time because encryption without integrity still leaves you open to attack

Add a MAC (message authentication code) for the data. Some encryption modes like GCM (Galois/Counter Mode) include one, others are separate so you might use HMAC with something else. Kill 2 birds with one stone as it were, or simply use 2 stones. Will this protect the user from an attacking on your side of the API though? You have to think about what happens if you are compromised too.

You might look at other kinds of API and see how they've mitigated types of attack. For instance, OAuth 2 uses a state parameter and a nonce, for differing reasons. As with @vidarlo's answer, you could use a nonce in combination with the session ID.

Answer 8

Rule 0: Never trust the client. Validate all inputs from the client side under all circumstances.

In this instance that means checking that the sending user is (a) authenticated as who they claim to be sending the message as, and (b) are authorized to send a given message, based on your criteria. It also means that the "text" field has to be sanitized before being stored or displayed to anyone, and that the timestamp for sending time should be set by the server - as far as your system is concerned a message was only "sent" when the system received it from the sender.

After trimming the parts of the model off that the server can (and should) fill in for the user, really what you have is just the recipient ID, and the message content.

As far as concerns about enumerating the user list by using sequential IDs and/or spamming, there are multiple ways of handling that, such as a "friend request" (by email, phone, username, etc) system that limits users to only being able to send messages to pre-authorized recipients and makes no indication of whether the target of a friend request is an actual user in the system. Additionally you can do traditional rate limiting with something like a leaky bucket, or even build a monitoring system that flags/bans users that are exhibiting flood/spam behaviors.