0

I'm developing a HTTP web server. I've used HTTPS as the protocol between client and server but I know that HTTPS can't prevent parameter tampering.

As we know, we can set parameters in URL, in HTTP header or in HTTP body. So clients could see these parameters directly.

In my view, there are two issues (Well I'm not an expert on security, so I don't know if the two issues do exist):

  1. Users can tamper the parameters. For example, you have no right to access the resources of other clients, but if you tamper some parameters, you might access some resources illegally.
  2. Users can see directly parameters, such as the ID of user. In my project, we put the user ID into all of HTTP requests' headers to trace the requests. Well, I just feel that this is not a good idea because user could see his ID directly. I'm thinking if I need to encrypt it...

As I said before, I'm not an expert on security, so could you please give me some solutions about the issues? I just learnt about JWT, JWT could prevent parameters tampering but clients could still see the parameters of JWT directly and I don't think I could put all of parameters into JWT.

2
  • "user could see his ID directly" - Sure. Why would you want to prevent it?
    – mentallurg
    Commented Apr 12, 2023 at 8:29
  • @mentallurg My colleague told me that the user ID generated by DB shouldn't be shown to users becaues it's unsafe...
    – Yves
    Commented Apr 12, 2023 at 9:10

2 Answers 2

1

There is nothing special to HTTP here but is the same for any kind of data exchange:

  • When processing untrusted data from the user one must always verify the data according to what one expects the data to be. Never assume that one can trust a client.
  • To protect the integrity of server generated data (or generated by third party) reflected by the client to the server (like Cookies, JWT token ...) one needs to add integrity protection to the message and verify in the server that nobody has tampered with the message. This can be for example done using HMAC.
  • To protect against the client extracting information from data which should only be reflected back to the server (like Cookies, JWT token, ...) one needs to encrypt the data so that only the server can decrypt it.
1

Users can tamper the parameters.

It depends on what you mean by "parameters". If you mean any data that the user sends to the server, then it is not true. For instance, user can work around any validations that you implement in JavaScript. That's why server should not trust any data received from the client and should validate all the data.

But JWT and similar elements cannot be tampered.

For example, you have no right to access the resources of other clients, but if you tamper some parameters, you might access some resources illegally.

No. If you properly implement security aspects, it is impossible. JWT is signed. If one user tries to break the signature and uses all the computers in the world for this purpose, then even in millions of years all these computers will not be able to break the signature.

Thus, user A is not able to fake a JWT and to pretend to be a user B.

Import is: This works only, if you properly validate JWT (structure, expiration, claims), if you properly check user permissions.

Important is: This works only, if you properly handle other aspects, e.g. if you protect against XSS, if you use TLS, if you use HttpOnly and SameSite cookie attributes properly. If you don't care about this, then in the worst case an XSS attack can succeed and JWT token can be stolen (if HttpOnly is not used).

You can start with what OWASP recommends.

Users can see directly parameters, such as the ID of user... I just feel that this is not a good idea...

If you implement all relevant validations properly, then there is no problem. The only security aspect is, that IDs, if you generate them incrementally across all users, can give an insight into how many object of this type you have in your database, e.g. how many products you have, how many orders, how many users. Some of them can be mitigated, if IDs are generated for each user independently, e.g. if every user has order 1, every user has order 2, etc., and the order key consists of user ID and order ID of this user.

There is no generic answer for all possible cases. In every case check what might be consequences and decide if you want to disclose particular attributes like IDs.

JWT could prevent parameters tampering

No. JWT just means that the party that sends this particular JWT is allowed to perform particular operations (contained in this JWT) on the data related to the particular user (whose name is contained in this JWT). As I said above, JWT cannot be tampered. One user cannot create a JWT with the name of another user or with own name but with other claims/roles, because JWT is only trusted, if it is signed by identity provider. User cannot create a signature in the name of identity provider, because it requires the private key which identity provider keeps secret.

but clients could still see the parameters of JWT directly

JWT does not contain any secret data. User name is not a secret for the user. User claims/roles are not secret for the user, because user applied for these roles when was enrolled into the system, and user was informed about any roles granted. Expiration date in the token is also not a secret.

I don't think I could put all of parameters into JWT

JWT is not a container for arbitrary data. It should only contain data related to authorization: What permissions are granted to access of what user.

Any other attributes should not be put to JWT.

You must log in to answer this question.

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