Безопасность фронта: фишинг, approve, симуляция

В Web3 ошибка фронта может стоить пользователю всех денег. Главные угрозы и как фронт защищает пользователя.

Безопасность Web3-фронта — не про защиту своего сервера, а про то, чтобы не дать пользователю по ошибке или из-за фишинга подписать опасную транзакцию.

В Web2 худшее, что бывает на фронте, — XSS или утечка токена. В Web3 ставки выше: подпись — это деньги. Один неверный approve на вредоносный контракт, и кошелёк опустошён без возможности отмены. Фронтендер dApp обязан мыслить как защитник пользователя.

Главные угрозы

  • Фишинг и подмена адреса. Пользователь заходит на сайт-клон, подписывает транзакцию «настоящему» на вид контракту — а это адрес злоумышленника.
  • Опасные approve. Бесконечный approve на вредоносный контракт = разрешение вывести все токены.
  • Подмена данных подписи. Пользователь думает, что подписывает «вход», а на деле — разрешение на перевод (slep-подпись).
  • Скомпрометированные зависимости. Вредоносный npm-пакет на фронте может перехватывать вызовы кошелька.

Что делает фронт для защиты

  1. Проверяйте адреса контрактов. Берите их из надёжного конфига, а не из URL/ввода пользователя. Показывайте, с каким контрактом идёт взаимодействие.
  2. Не запрашивайте бесконечный approve по умолчанию. Предлагайте approve ровно на сумму операции.
  3. Показывайте, что именно подписывается. Человекочитаемое описание действия рядом с окном кошелька.
  4. Симулируйте транзакцию перед отправкой (через eth_call/инструменты вроде Tenderly), чтобы поймать revert и неожиданные эффекты заранее.
  5. Проверяйте сеть и адрес перед каждой записью — частая дыра.

«Не доверяй, проверяй»

Кошелёк — последняя линия обороны, но он показывает «сырую» транзакцию, которую пользователю трудно понять. Хороший dApp дополняет это понятным контекстом: «Вы разрешаете контракту X тратить до 100 USDC». Чем понятнее, тем меньше шанс, что пользователь подпишет что-то вредное вслепую.

Как работает под капотом (симуляция)

Симуляция — это запуск транзакции «вхолостую» через eth_call на текущем состоянии: нода исполняет вызов, но ничего не записывает, и возвращает результат или ошибку revert. Так фронт заранее видит, пройдёт ли транзакция и что изменит, не тратя газ. Продвинутые сервисы симуляции показывают изменения балансов («после этой транзакции у вас станет на 1 NFT больше, на 0.1 ETH меньше») — это резко снижает риск слепой подписи.

Частые ошибки

  • Брать адрес контракта из URL/ввода. Прямой путь к подмене; адреса — из проверенного конфига.
  • Бесконечный approve по умолчанию. Удобно, но опасно; делайте это осознанным выбором.
  • Не объяснять подпись. Пользователь подпишет вслепую — мечта фишера.

Итоги

  • В Web3 ошибка подписи необратима и стоит денег — фронт защищает пользователя.
  • Проверяйте адреса/сеть, избегайте бесконечных approve, объясняйте подпись.
  • Симуляция транзакции ловит revert и опасные эффекты до отправки.
Проверьте себя
1. Почему бесконечный approve опасен?
AОн стоит больше газа
BОн даёт контракту разрешение вывести все ваши токены
CОн меняет chainId
DОн удаляет NFT
2. Что такое симуляция транзакции?
AОтправка с нулевым газом
BЗапуск через eth_call без записи, чтобы заранее увидеть результат и revert
CПодпись сообщения
DПеревод в тестовую сеть
3. Откуда фронт должен брать адреса контрактов?
AИз URL-параметра
BИз поля ввода пользователя
CИз проверенного конфига приложения
DИз чужого сайта