A
A
Alexander Solovkin2019-05-03 15:32:57
JavaScript
Alexander Solovkin, 2019-05-03 15:32:57

Attack from "developer mode". How to protect yourself?

If in the browser (for example, in chrom) in "developer mode" (F12) you change the value of the HTML element or the JS function, the changed data is transmitted to the server (by submit). With proper skill, a "hacker" can perform an operation that is not allowed for him. How to protect yourself from this (protect yourself). I see only one way: The data loaded onto the page from the server (for example, some id), and which are used later in the processing of submit`a on the server, protect hash`em and execute on the server acc. verification. Or json -> string + hash -> encryption -> browser (sumbit) -> server -> decryption -> verification.

Answer the question

In order to leave comments, you need to log in

4 answer(s)
M
MrDywar Pichugin, 2019-05-03
@Dywar

There is no such protection, it does not exist.
csrf has nothing to do with it, no script is trying to be executed.
F12 is available to everyone, the user has received a copy of the document (HTML, CSS, JS), and can do whatever they want with it.
In the same way, he can look at the HTTP request, and send anything there without using a browser.
On Habré, a long time ago they described a project that protects against this. Like, a person went from his browser to another browser where there is no F12, and the site opens there already. You can google this article.
The client code is executed and stored on the client, the client can do whatever he wants with it. Look at Postman, Fiddler2, Burp. This software is specifically for watching and changing the response-request. Looked at the comments on other answers.
The server must check each request for validity, no matter what. Any request is considered invalid unless proven otherwise.
- The server should not accept the value of the goods received from the client as valid. The client received a copy of the price, its value at the time of the request. This is just information for the client, not for the server. Only the server knows the current value, the client can request its value at a certain point in time, and that's it.
But what to do if the client managed to complete the order at the old price, and there is already a new one on the server, this is the task of analysis (for analysts).
You just need to study the code of any online store, as implemented there. Look for a book where such an application is understood.

S
sim3x, 2019-05-03
@sim3x

With proper skill, a "hacker" can perform an operation that is not allowed for him.
no
After all, you check all the rights of the dotsup of this user on the back
Or did you think that you were the first to invent csrf?

S
Stalker_RED, 2019-05-03
@Stalker_RED

json -> string + hash -> encryption -> browser (sumbit) -> server -> decryption -> verification.
if the first "encryption" is on the client side, then what prevents a hacker from substituting any of his data into it?
There is only one way out - to check everything on the server side.

R
rPman, 2019-05-04
@rPman

Only transferring 'dangerous' activities to the server will save you.
The correct approach to web development is that only the interface and everything connected with it is executed in javascript, and all logic should be on the server.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question