1

Recently I attended a workshop were the presenter explained securing rest APIs.

One of the things he recommended to avoid man in the middle attacks was to not send IDs in the URLs (i.e. not sending the IDs as path parameters For e.g. Don't do this : GET /orders/{order-id}). This way a malicious hacker will not be able to change the IDs in flight and direct the request to an incorrect resource in the back-end. Better approach would be to put ids in the body and sending the body as the part of the payload of a token. If some one tampers with the token then the signature in the token wont match with the modified content in the payload.

Is this the right approach or the best approach?

humbleCoder
  • 113
  • 4

1 Answers1

3

... to avoid man in the middle attacks was to not send IDs in the URLs (i.e. not sending the IDs as path parameter ex. Don't do this : GET /orders/{order-id})

A man in the middle can both manipulate the request header (containing the target URL) and the request body too, so the "protection" to move important information into the body will not help.

... Better approach would be to use something like tokens and IDs in the body.

I'm not sure what exactly you mean with this. But if for example the order-id given by the server should be save against manipulation by a man in the middle attacker then protecting it with a signature (token) based on the order-id, the current user session and some server side secret would work. It would be irrelevant if this is used in the URL or the request body though.

Anyway, trying to protect against an active man in the middle by somehow protecting fields is not sufficient since it only protects information provided and protected by the server but not by the user (i.e. where to ship stuff etc). Protection against man in the middle attacks should be done with encryption by HTTPS instead.

Protecting server-provided information (like order-id) with signatures is instead a way to protect against attacks where some attacker tries to access data from other users. This is not specific for man in the middle attacks though.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • I have updated the question to convey what I was asking correctly. – humbleCoder Dec 17 '19 at 06:50
  • 1
    @humbleCoder: Again, a man in the middle can easily modify the body of the request too. Simply putting data into the body instead of the URL will not protect them. Signatures (tokens) will protect them instead but it does not matter if parameters and signatures are in the body or the URL for this. – Steffen Ullrich Dec 17 '19 at 06:55
  • For man in the middle its clear now to me as per your answer that we have to use HTTPS to encrypt end to end communication. However someone can still modify the requested URL right (In my understanding HTTPS does not encrypt the URL we are trying to hit) So I fail to understand why moving parameters (order_id) to the body and securing them with tokens and signatures will not protect against someone changing the ids and redirecting the request to a unwanted resource. – humbleCoder Dec 17 '19 at 08:05
  • 1
    @humbleCoder: *"In my understanding HTTPS does not encrypt the URL we are trying to hit"* - Your understanding is wrong, i.e. HTTPS encrypts the URL including path, parameters etc. It does have the domain name part of the URL in clear in the TLS handshake but even this is protected against manipulation. See also [Are GET parameters secure over https?](https://security.stackexchange.com/questions/38688/). – Steffen Ullrich Dec 17 '19 at 08:33
  • Ohhhh..now I get it..thanks..that was a big gap in my knowledge!! – humbleCoder Dec 17 '19 at 08:56