@Vitalievich
Самоучка. Опыт в Win, C#. Интерес: IOS, Android

Атака из «режима разработчика». Как защититься?

Если в браузере (например в chrom) в "режиме разработчика" (F12) изменить значение HTML элемента или функцию JS, измененные данные передаются на сервер (по submit`у). При должном умении "хакер" может выполнить недозволенную для него операцию. Как от этого защищаться (защищаются). Я вижу только один способ: Данные, загружаемые на страницу из сервера (например какие-то id), и которые используются в дальнейшем при обработке submit`a на сервере защищать hash`ем и на сервере выполнять соотв. верификацию. Или json -> строка + hash -> шифрация -> браузер (sumbit) -> сервер -> дешифрация -> верификация.
  • Вопрос задан
  • 182 просмотра
Пригласить эксперта
Ответы на вопрос 4
Нет такой защиты, ее не существует.
csrf тут не причем, никакой скрипт не пытается выполнится.

F12 доступна всем, пользователь получил копию документа (HTML, CSS, JS), и может с ней сделать что угодно.
Точно также он может посмотреть HTTP запрос, и отправлять туда что угодно не используя браузер.

На хабре давным давно описывали проект, который защищает от подобного. Мол человек заходил из своего браузера в другой браузер, где нет F12, и уже там открывается сайт. Можете погуглить эту статью.

Клиентский код выполняется и хранится на клиенте, клиент может с ним делать все что пожелает.
Сервер должен проверять каждый запрос на валидность, не зависимо ни от чего. Любой запрос считается не правильным, если не доказано обратное.

Посмотрите на Postman, Fiddler2, Burp. Это ПО специально для того что бы смотреть и изменять ответ-запрос.

Посмотрел комменты к другим ответам.
- Сервер не должен принимать стоимость товара полученные от клиента как действительную. Клиент получил копию цены, ее значение на момент запроса. Это просто информация для клиента, не для сервера. Только сервер знает текущую стоимость, клиент может запросить ее значение в определенный момент времени, и все.
А вот что делать если клиент успел выполнить заказ по старой цене, а на сервере уже новая, это задача анализа (для аналитиков).

Вам достаточно изучить код любого интернет магазина, как реализовано там. Книгу поискать где подобное приложение разбирается.
Ответ написан
Комментировать
sim3x
@sim3x
При должном умении "хакер" может выполнить недозволенную для него операцию.
нет
Ведь вы проверяете все права дотсупа данного юзера на беке

Или вы подумали, что вы первый изобрели csrf?
Ответ написан
Stalker_RED
@Stalker_RED
json -> строка + hash -> шифрация -> браузер (sumbit) -> сервер -> дешифрация -> верификация.
если первая "шифрация" на стороне клиента, то что мешает хакеру подставить в нее любые свои данные?

Выход только один - проверять всё на стороне сервера.
Ответ написан
@rPman
Только перенос 'опасной' деятельности на сервер вас спасет.

Правильный подход к веб-разработке - на javascript исполняется только интерфейс и все что с этим связано, а вся логика должна быть на сервере.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы