Attack of the "developer mode". How to protect yourself?

If the browser (e.g. in chrome) to "developer mode" (F12) to change the value of HTML element or a JS function, the changed data are transmitted to the server (for submit'have). With proper skill, a hacker can perform unauthorized surgery for him. How to protect yourself from it (protected). I see only one way: Data is uploaded to the page from the server (for example, some id), and which are used further in the processing submit'a server to protect hash'eat and the server to perform ACC. verification. Or json -> string + hash -> encryption -> browser (sumbit) -> server -> decoding -> verification.
March 20th 20 at 11:38
4 answers
March 20th 20 at 11:40
No such protection doesn't exist.
csrf has nothing to do with any script trying to run.

F12 is available to all, the user received a copy of the document (HTML, CSS, JS), and could use it to do anything.
Similarly, he can view HTTP request and send back anything not using a browser.

Habré long ago described the project, which protects him from such. They say man came from his browser in a different browser where there is no F12, and already there have website. You can Google this article.

The client code is executed and stored on the client, the client can do with it everything you wish.
The server must check every request for validity, no matter what. Any request is not correct, unless proven otherwise.

Look at the Postman, Fiddler2, Burp. It is specifically for that to watch and change the response to the query.

Looked comments to other answers.
- The server must not accept the value of the goods received from the client as valid. The client received a copy of the prices, its value at the time of the request. It's just information for the client, not the server. Only the server knows the current value, the client can request its value at a particular point in time, that's all.
But what to do if the client had to execute the order at the old price and the new server already, it is the task of the analysis (for analysts).

You can simply explore the code of the online store, as implemented there. The book to find where such an application understands.
March 20th 20 at 11:42
With proper skill, a hacker can perform unauthorized surgery for him.
no
After you check all the rights of dotzup of the user on the Beck

Or do you think that you invented the first csrf?
Only it's not CS, but just RF.

Everything else is, any data coming from the outside (from a browser) by default untrusted - Rita_Hilpe commented on March 20th 20 at 11:45
@jordon_Colli, Yes
But the essence of the mechanism of this is not affected - karina59 commented on March 20th 20 at 11:48
Access rights are checked of course. But "hacker" can substitute for example a new ID and product price (this is only a simple example). Rights of access to a method on the server he has, he had a legitimate client, but to buy this(new ID) product it is impossible. Specifically, this can be checked on the server, but similar and very different objects MB. a lot. Looking for something versatile. Haven't found anything. Invented what he invented and wrote. Realized that I had reinvented the wheel. It's called "Encrypted Token" Well, the main thing now is to make the wheels round. Thank you all. - gilbert.Hoeger commented on March 20th 20 at 11:51
@alysa_Murray,
Horror
The user tried to add a product to the cart and not to add - what error you get him back?

Universalnoe the decision is in your framework - karina59 commented on March 20th 20 at 11:54
@alysa_Murray,
> new ID
Well buy another product if he can't buy this product, you should also be checking on the server
> and the price
and this is all nonsense, the price can be only from the database on the server

You do not get to do everything on the server. At some point you still have the input from the user and it will still have to validate - Rita_Hilpe commented on March 20th 20 at 11:57
March 20th 20 at 11:44
json -> string + hash -> encryption -> browser (sumbit) -> server -> decoding -> verification.
if the first "encryption" on the client side, what prevents a hacker to substitute it with any of your data?

The only solution is to check everything server-side.
Encryption / decoding of course on the server - gilbert.Hoeger commented on March 20th 20 at 11:47
March 20th 20 at 11:46
Only the transfer of 'dangerous' activities on the server will save you.

The right approach to web development - javascript is executed only interface, and all connected with it, and all logic must be on the server.

Find more questions by tags JavaScriptASP.NET