Which HTML attribute cannot be modified?

Asked

Viewed 141 times

0

Using PHP I display a table, in id of each li, I put the id of the record that is in the database. Once they displayed, I have an option that deletes the record, I do it through AJAX, caught the id that li, and have PHP delete.

But I realized that if I use Developer Tools, "famous F12", and manually change the ID of li, He’s going to take this new ID that I put in. That way the project that I’m doing is vulnerable depending on who uses it. I say this because there is a lot that I am using this method. There is some attribute that the user cannot edit or some other more secure method?

  • 2

    Longer answer: Not.

  • The way is to always validate in the backend.

  • 2

    Normally you wouldn’t have to do anything special in html. A well-written application will not delete based only on the ID, but on the user’s credentials. If the user is allowed to delete, it does not matter if it was by devtools or if it was by the original interface. What may be wrong is your application does not validate your credentials. This would be a real application problem, different from the path sought in the question.

3 answers

6


It does not exist, in fact it is not only HTML, it is in anything, whenever you depend on a client you will be vulnerable, so you should never trust anything that comes from the client, everything can come unexpectedly. Never trust the customer!

Imagine that in most existing software, mainly web only work by coincidence, because in general nobody moves, it is rare the programmer who validates all data entries and only accepts what is really suitable.

Applications nonweb hinder a little more because it requires a technical knowledge that few have, but for web, any curious can detonate its application.

Think about it, what’s the difference between a person accessing a id from your regular page or Dev Tools? Is there any situation that the person cannot access this id? Ensure on the server that this is not possible. There is no other way.

And make sure the server is not vulnerable. Make sure the request cannot be compromised, otherwise the server will not be safe.

  • Intendo, then for example, in my comic book, I have the client’s addresses, I have the id and idUser. I would have to check if the sent id has the same id as the logged in user. If yes you proceed with the action, if contract would be some user trying to modify something correct, I just interrupt the action and display an alert. I always try to do validation front and back.

  • That’s the way it is. There’s no way to stop users from doing something wrong in good or bad faith, you can prevent it from happening, you can restrict what it can do, you can audit, reverse, you can prevent unauthorized people from moving where they can’t.

2

There’s no stopping it. If the client changes a code that will be sent to the server, it is the server that should validate: check if the value exists, if the value received is valid, if the client who sent it had authorization to do so, etc...

But it’s always good to do a pre-validation frontend also, as it saves requests to the server.

In your example, if the guy changes id=10 to id=12, for example, and normally it doesn’t make a difference, he will only be changing 6 by half a dozen. Now, if it swaps id=10 per id=13 and the value "13" is not included in the values that this user can mess with, your backend should know this and prevent the script from continuing.

-3

You could generate validation keys for your inputs and log in an array, hence before submitting the form or any other action, you can check them using JS.

Ex:

<input id="1" data-validation="b89eaac7e61417341b710b727768294d0e6a277b"> 

In this input the data-validation is an SHA1 hash generated with the original field ID and header information with page load date and time. This is just an example of how you can keep track of the ID. So you can validate everything before submitting.

Generally, I create a few layers of validation on the front and back end ... and I don’t worry about real-time modifications, as they are always filtered in one layer or another.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.