6

I am trying to better understand and determine the impact and implications of a web app where data tamping is possible.

When discussing data tampering, I am referring to when you are able to use a tool such as BurpSuite or Tamper Data to intercept a request and modify the data and submit it successfully.

I understand that this will allow an attacker to evade Client-side validations. For example, if the client does not allow certain symbols e.g. (!#[]) etc, an attack can input the correct details which the client will validate and then intercept the request and modify the data to include those symbols. But I'm thinking there is more than just the evasion of client-side validation that this vulnerability allows.

I am also thinking it perhaps opens the door to allow Dictionary-attacks using BurpSuite or Brute-force logins to user accounts since data can be intercepted and modified which can be used to test username and password combinations.

Would appreciate any insight regarding the implications of a Data Tampering vulnerability.

Improve this question
5
  • 55
    All client-side validations are for user convenience, not for security.
    – schroeder ♦
    Commented Apr 5, 2022 at 13:12
  • 1
    You have 2 different issues here that you need to separate: 1) the impact on the client and user, and 2) the impact on the service. But a properly designed service does not depend on client-side controls. So the impact should be on the user-side alone. The impact to the user will depend entirely on the app, which only you know. So, given all this, the question is too broad and undefined to answer.
    – schroeder ♦
    Commented Apr 5, 2022 at 13:15
  • 5
    Anything your web app can do, can be done with curl. Thinking about intercept and modify is missing the point; arbitrary data can be sent to the server.
    – prosfilaes
    Commented Apr 7, 2022 at 14:29
  • 2
    Even Javascript code, anything you send to a client should be considered at best a polite request. There's nothing stopping a client from not executing, selectively executing, or executing modified code. If you need to make sure some data is valid, you need to do it yourself on a computer you trust (your server).
    – Different55
    Commented Apr 7, 2022 at 15:13
  • @schroeder That's what we hope :-)
    – gnasher729
    Commented Apr 8, 2022 at 15:08

4 Answers 4

Reset to default
45

This "Data Tamper Vulnerability" is not a vulnerability. It's like "Door without lock vulnerability."

Client-side validation is not validation. Is a convenience tool: better let the user know instantly that he cannot have # as username then waiting for the form to be submitted, the server reject the username and send back an error message stating that the username was not accepted AND he has to fill out the entire form again.

If your threat model does not include "user submitting data without validation," you are doing it wrong. When an attacker sees your javascript stripping # from a field, one of the first things he will try is to send # on a field, and your server must deal with it.

Do proper validation on the server. Never trust any data from the client: form fields, URL, GET parameters, cookies, JWT, filenames, everything coming from the client is untrusted until validated on the server.

If the client is sending malicious input and the server is not validating, several bad things can happen:

  • SQL Injection
  • Remote Code Execution
  • Cross Site Scripting
  • Server side request forgery
  • Remote file inclusion

... to name a few.

Improve this answer
21
  • 7
    @Krellex Yes that is possible, but only if no validation is done on the server. This is exactly why we say "never trust user input/client-side validation, always validate data server side before using or storing it"
    – nobody
    Commented Apr 5, 2022 at 17:56
  • 13
    @Krellex No. The only way to stop it is server side validation. Brute force attacks can be mitigated by server side rate limiting.
    – nobody
    Commented Apr 5, 2022 at 18:28
  • 3
    @Krellex Client-side validation can be bypassed using just the tools that pop up if you hit the F12 key while using Chrome. A user who knows what they're doing is fully able to tamper with their own data as they see fit. Nothing you do on the client side can change that, because users can modify or bypass any of the client-side code too. They can change the data before it's encrypted.
    – Robyn
    Commented Apr 6, 2022 at 4:05
  • 8
    "Validation" have a broad sense here, is to make sure that the input is valid for the expected purpose. Taking the input as is and trusting it is valid is wrong.
    – ThoriumBR
    Commented Apr 6, 2022 at 12:08
  • 7
    @leftaroundabout That's a tedious solution. Working, but convoluted and difficult. Simply checking that it doesn't contain illegal characters on the server side is much simpler. It can be done in 2 lines of code and will be obvious to whoever works on the code in the future. As and added bonus it's what everyone does, so your future code maintainers will EXPECT this. The base36 option will just be confusing when they see it the first time. Also it's a lot easier to debug your application when the data is in plaintext, rather than obfuscated like that.
    – Vilx-
    Commented Apr 6, 2022 at 20:09
18

Proper web site/app security MUST assume that the client may sometimes actually be a custom made malicious tool, designed and built from the ground up by an attacker for the express purpose of defeating your security. If your server-side security cannot protect against such a tool, then you don't actually have security at all.

If you do have actual server-side security, then client-side data tampering simply is not an issue. Anything that client-side data tampering could do, a hypothetical custom attacker's tool could also do, so if your server is secure against a custom malicious tool then it is secure against client-side data tampering.

Improve this answer
7

I understand that this will allow an attacker to evade Client-side validations.

You're thinking of the roles backwards. If you're trying to make software running on an end user's computer enforce some rule of your own against what they want to do, you are the attacker and they are the defender. Don't be in that role.

Where you are the defender is on your own server, processing the data the user sent you via the software you provided to them to help them submit it in a manner most useful to them. That's where you have both the technical capability and the standing to do so. Get it right and you don't have to worry about trying to make the user's own computer police them.

Improve this answer
1
  • 1
    This gave me flashbacks to whenever anything "secure" would require a java applet.
    – papirtiger
    Commented Apr 7, 2022 at 19:33
6

Other answers correct you on client side vulnerabilities.

I want to add this rather direct answer to be very clear.

Every attack is indeed possible, unless your own server deliberately prevents it.

While we can nitpick that (not every attack, and not all attacks are literally server prevented), the broad picture that paint is both true and a useful way to think about it.

That means, for example...

  • Brute force attacks are easy ... unless your server limits the number of attempts allowed in some way.
  • User accounts and passwords can be stolen or intercepted, if the clients machines or networking is weak on security. Since you don't control that, you only have limited ways to prevent or mitigate it.
  • User forms, text, web requests and values returned,and local storage/cookies, can be faked or targeted maliciously. Again not in your control, you can only do the things you can do. You don't control clients. You do control your own systems. And you can hope the clients have some decent security.
Improve this answer
1
  • "Every attack is indeed possible, unless your own server deliberately prevents it.". I could not have stated better.
    – ThoriumBR
    Commented Apr 7, 2022 at 21:50

You must log in to answer this question.

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