Can an attacker use inspect element harmfully?

Question

I know this is a broad question, but I think I'm missing something here. Is it possible for an attacker to cause damage to a site by simple using inspect element and editing the javascript and html? For example, it seems too easy for someone to change the maxlength of an input, and upload so much data that it could crash the server, I know that it is always good practice to check data at the server but it still seems too easy. Or another more potentially dangerous example is if the attacker can mess with an $.ajax call and send bad info to the server. Is it something I should be worrying more about or are the changes just temporary, on the attackers browser?

Answer 1

The changes are temporary on the individual user's browser.

However, the changes will allow that user to interact with your backend however they choose to do so. This is one way in which sites are attacked.

The standard rule is to never trust input coming from the user / browser. Do not trust the value of hidden fields, do not trust that they have not changed the length, do not trust that they have not added new values (e.g. to a drop down), do not trust any validation that has been done in Javascript, etc.

Some examples:

• Some shopping sites in the past would include the amount to be paid as a hidden field in the form. Changing this value changed the amount charged to a credit card while still approving the transaction.
• Sites with Javascript validation rules that could be skipped by posting directly to the backend service opening themselves up to SQL and HTML / Script injection attacks.
• Drop downs, radio button, and checkbox inputs where unexpected values can be added to the form.

Answer 2

Yes, they can. When they inspect elements, they can modify everything locally, so it'll be a temporal modification for their local environment, however they can modify values that can affect your server.

For example, let's imagine that you have an online store, and you have an "Edit Product" option. Once you go there, you have a hidden field, where you store the product ID, such that when you try to update that product in your back-end, you'll use that ID to know which product to update. An attacker can easily change that value, and now he'll be able to modify any other product (including products that don't belong to him).

Another classic example could be a number field, where you assume that the user will only be able to submit numeric values, so in your back-end, you use that number in your query, for example, something like

"SELECT * FROM Products WHERE Price > " + Price;

You're expecting a numeric value, so you think that there's no way that an attacker can send text for an SQL Injection, but he can easily modify that value (either by changing the number input for a text input, modifying the javascript value before sending it, or intercepting the network traffic and modifying the value from there), and now you can end up with something like:

"SELECT * FROM Products WHERE Price > 0; DROP TABLE Products--"

That's the main reason why you should never trust user input. Are you expecting a numeric value? Then make sure it's a number before using it. Is your user updating a product? Make sure that the product really belongs to him before updating it. Do you have a maxlength property for your data? Double check in your server to make sure that it still has a valid length.

It might seem like something really easy and simple, but people make mistakes. A simple example is the "Heart Bleed" bug, where all that could had been avoided by verifying the request's length, instead of trusting user submitted data.

And that's the main reason why you need to never trust user submitted data, and always perform a double check in your back-end.

Answer 3

You should be worring about this. Never trust input coming from the client. Do not expect that any check you're performing on the client side is really executed. You always need to check the input at the server side. As you already mentioned a user could use the various inspection tools to change the local code or simply craft a malicious packet completely by hand.

Answer 4

Yes they can. They can see your code, giving them a chance to find a vulnerability or make a vulnerability and attack the vulnerability. Even though the edits are temporary and only on the attacker’s browser, they can cause harm.