Почему кошелёк могут опустошить «без подписи»
Цель материала: объяснить механику разрешений
(approval — действие выдачи прав, allowance — записанный лимит списания),
разобрать ключевые сценарии
EVM — это группа совместимых блокчейн-сетей с одинаковыми правилами работы смарт-контрактов,
где управление токенами и NFT построено на системе разрешений.
В таких сетях approve, allowance и
Главная уязвимость здесь — ожидание, что каждое списание потребует отдельной подписи. В интерфейсе кошелька подпись выглядит как обычный шаг («разрешить», «подключить», «подтвердить для обмена»), поэтому пользователь подтверждает не перевод, а выдачу прав, которые сохраняются в контракте и используются позже без нового окна подтверждения.
Лишний allowance
(записанный в контракте лимит, определяющий, сколько токенов можно списать)
на стейблкоин или активный
Если вы оцениваете риск DeFi шире, чем approvals, добавьте в список проверки отдельные поверхности атаки: фронтенд dApp, мосты, MEV, ключи и операционные ошибки. Гайд по безопасности в DeFi: карта угроз и чеклист .
Approval phishing использует выдачу прав через approve/permit
(создание или изменение allowance)
или
Одна подпись approve/permit или
Что такое approval phishing и в чём его «нечестная честность»
Ключевые термины в разделе:
-
Spender — адрес смарт-контракта, которому разрешено списывать ERC-20 токены владельца
в пределах allowance через
transferFrom . -
Operator — адрес, получивший право переводить NFT владельца в механике
setApprovalForAll , без ограничения по количеству токенов коллекции. - Allowance — значение в контракте ERC-20, задающее максимальное количество токенов, которое spender может списать.
- Revoke — транзакция, которая обнуляет allowance или отключает operator, прекращая право списания или перевода.
Approval phishing использует штатные механизмы разрешений: выдача прав выглядит легитимно, не вызывает мгновенной потери средств и поэтому часто не воспринимается как риск в момент подписи.
Approval phishing — это атака, при которой пользователя убеждают выдать разрешение (approval/allowance) на управление токенами или NFT, а затем используют это право для вывода активов. Опасное действие маскируют под привычный шаг интерфейса: «подтвердите для обмена», «разрешите для минта», «подпишите для клейма», «дайте доступ для депозита».
В отличие от кражи ключа злоумышленнику не нужен приватный ключ и не требуется прямой перевод средств. Достаточно, чтобы пользователь один раз выдал право конкретному адресу списывать активы: spender для ERC-20 или operator для NFT. После этого вывод выполняется без новых окон кошелька и без повторных подтверждений владельца.
На уровне блокчейна транзакции выглядят валидными: пользователь действительно изменил состояние контракта и выдал право конкретному адресу. Поэтому кошелёк формально не «взломан»: активы уходят через заранее выданные разрешения, а не через обход подписи.
Approve обычно не переводит средства сразу. Он записывает лимит allowance в контракте токена, после чего spender может вызвать
Пока баланс не изменился, подпись часто воспринимается как безопасная. При unlimited approval или setApprovalForAll злоумышленник может вывести текущие активы и любые будущие поступления, пока allowance не будет обнулён или статус operator не будет отключён.
Проще говоря: approve — это не перевод, а выдача права списания конкретному адресу. Approval phishing заключается в том, что пользователю подсовывают выдачу права на чужой адрес, маскируя её под нормальный этап обмена, минта или клейма.
Approval phishing работает за счёт валидных разрешений. Опасность возникает после подписи, когда активное право списания используется без участия владельца.
Разрешения в EVM — это записи прав в контрактах, а не разовые действия; именно поэтому approve может работать месяцами и использоваться без повторной подписи.
Как работают разрешения в EVM: allowance, spender и «бесконечный approve»
Разрешение в EVM — это запись в состоянии контракта токена или NFT, которая связывает ваш адрес и конкретный адрес spender/operator. Эта запись определяет, кто может списывать токены через
- ERC-20: approve → allowance → transferFrom
- Пользователь вызывает approve(spender, amount) и указывает адрес spender.
- Контракт токена сохраняет лимит allowance — максимальное количество токенов, которое spender может списать.
- Spender вызывает transferFrom и списывает токены без новых подписей, пока allowance не станет равным 0 или не будет исчерпан.
- Контракт проверяет allowance при
transferFrom , а не запрашивает подпись у владельца при каждом списании.
- Allowance привязан к связке owner → spender → token
- Разрешение существует только для конкретного токена и конкретного spender.
- Approve на USDT не даёт доступа к USDC и не распространяется на другие контракты.
- Каждый новый токен или новый spender требуют отдельного approve.
- Unlimited approval — это максимальное значение allowance
- При unlimited approve в allowance записывается предельное числовое значение.
- Spender получает право списывать токены этого контракта в пределах этого значения, включая будущие поступления на адрес.
- Разрешение остаётся активным до транзакции revoke, даже если сервис больше не используется.
- NFT: setApprovalForAll — статус оператора без лимита
- setApprovalForAll(operator, true) включает статус оператора для всей NFT-коллекции владельца.
- Это не лимит по количеству или сумме: право сохраняется до транзакции setApprovalForAll(operator, false).
- Если operator скомпрометирован, NFT могут быть выведены без новых подтверждений владельца.
Unlimited approve для ERC-20 увеличивает максимальный объём списания через
Разрешения в EVM — это долговременные записи прав в контрактах. Один approve может работать месяцами, unlimited увеличивает доступный лимит списания, а
Permit-подпись (например, EIP-2612) передаёт приложению право установить allowance через подпись сообщения; приложение затем использует подпись в транзакции, которая выдаёт права и выполняет действие в одном вызове.
Permit, Permit2 и подпись сообщения: как выдают разрешения без отдельного approve и почему это используют в атаках
Помимо обычного approve в EVM есть способы выдать разрешение без отдельной транзакции. Пользователь просто подписывает сообщение, а приложение использует эту подпись в своей транзакции, которая сразу и выдаёт право списания, и выполняет действие — своп, депозит или клейм. Такие механики называются permit и его расширения вроде Permit2.
С точки зрения UX это выглядит как уменьшение количества шагов: нет отдельной транзакции approve и не требуется газ для отдельного вызова approve. Техническое последствие то же: в контракте появляется право списания, и это право может оставаться активным дольше одной операции, если параметры подписи задают широкий лимит или долгий срок действия.
Два типа подтверждений, которые путают чаще всего:
- Транзакция (on-chain): approve / revoke / transfer — отправляется в сеть, требует газ и меняет состояние контракта.
- Подпись сообщения (off-chain): permit и похожие механики — не требуют газа при подписи, но дают приложению возможность установить те же права доступа.
| ⚙️ Механика | 🧾 Что вы даёте | 📍 Где встречается | ⚠️ Ключевой риск |
|---|---|---|---|
| Approve (ERC-20) | Лимит списания токена для spender | DEX, лендинг, фарминг, мосты | Unlimited allowance активен до revoke |
| Permit (EIP-2612 и аналоги) | Разрешение через подпись без отдельного approve | Свопы «в один клик», агрегаторы, DeFi-интерфейсы | Подпись выглядит «безопасно», но задаёт реальные права |
| SetApprovalForAll (NFT) | Глобальный доступ ко всей коллекции | Маркетплейсы, минты, игровые dApp | NFT переводятся без повторных подтверждений |
Ключевой нюанс: approve и permit приводят к одному результату — у конкретного адреса появляется право управлять активами владельца. Отличается форма подтверждения: транзакция в сети или подпись сообщения, которую позже используют внутри транзакции.
Чеклист перед подписью (30 секунд): быстрый фильтр, чтобы увидеть, выдаёт ли подпись право списания.
- Что подтверждается? Permit или approve означает выдачу доступа.
- Кому выдаётся доступ? Смотрите на spender или operator в параметрах, а не на дизайн сайта.
- Какой лимит? Unlimited на ликвидные токены увеличивает доступный объём списания.
- Есть ли setApprovalForAll? Для NFT это статус полного оператора коллекции.
- Есть ли срочность? Давление по времени часто используют для подписи без проверки параметров.
Permit и «подписи без газа» меняют только форму подтверждения. Подпись сообщения может установить права доступа на токены или NFT так же, как approve, поэтому параметры подписи нужно читать как выдачу разрешений.
В типовых схемах approval phishing пользователя подводят к подписи approve/permit или
Типовые схемы approval phishing: как вас подводят к «правильной» подписи
Эти схемы используют знакомые интерфейсы и стандартные сценарии, из-за чего выдача разрешений выглядит как обычный шаг работы с сервисом.
Почти все атаки следуют одной логике: сначала пользователя приводят на страницу, которая выглядит как интерфейс dApp, затем запрашивают подпись, которая выдаёт право списания или право оператора, и после этого используют активное разрешение для вывода активов без новых подтверждений.
Ключевая особенность — отсутствие прямого требования отправить перевод. Вместо перевода запрашивается approve/permit или
- Клон популярного сервиса
- Поддельный домен или рекламная ссылка ведёт на визуально похожую копию DEX или маркетплейса.
- Интерфейс запрашивает approve «для обмена» или
setApprovalForAll «для листинга NFT». - В параметрах подписи указан spender/operator, который не относится к реальному сервису.
- Компрометация официальных каналов
- Ссылка публикуется в Discord, Telegram или X от имени проекта или модератора.
- Используются триггеры срочности: «ошибка контракта», «перенос минта», «последний шанс».
- Ссылка ведёт на страницу, которая запрашивает approve/permit на адрес злоумышленника.
- Социальная инженерия через «поддержку»
- Злоумышленник пишет в личные сообщения, представляясь саппортом сервиса.
- Под предлогом «отменить зависшую транзакцию» запрашивается подпись.
- Фактически пользователь подписывает permit или выдаёт approve стороннему адресу.
- Подмена смысла подписи
- В окне кошелька отображается технический вызов без пояснений со стороны интерфейса.
- Пользователь подтверждает, не сверяя адрес spender/operator и лимит.
- Риск максимален, если интерфейс не показывает spender, лимит или тип разрешения.
Пример: пользователь подключает кошелёк к странице «airdrop», нажимает Claim и подписывает unlimited approve на стейблкоин. Баланс не меняется, но позже, при поступлении средств, spender списывает токены через
Такие атаки не требуют немедленного вывода. Злоумышленник может ждать роста баланса или поступления ликвидности и затем использовать активное разрешение.
Типовые схемы approval phishing маскируют выдачу прав под привычные действия. Пока allowance или статус operator активны, злоумышленник может использовать их в любой момент без новых подтверждений владельца.
Allowance и
Типичные ошибки пользователей: почему approvals копятся и становятся угрозой
Опасность approvals редко ощущается в момент подписи, потому что approve обычно не меняет баланс. Риск появляется позже, когда активное разрешение используют для списания, и усиливается, если такие разрешения остаются в нескольких сетях и на нескольких токенах.
Самая частая ошибка: unlimited approvals на стейблкоины и ликвидные токены. В момент подписи это выглядит как экономия шагов, но технически это означает большой allowance, который позволяет spender списывать токены через
Та же логика работает и с
Отдельный класс ошибок связан с доверием к бренду и визуальному оформлению. Пользователь ориентируется на домен, логотип или дизайн, но разрешение всегда выдаётся конкретному адресу — spender или operator. При подмене интерфейса дизайн не меняет адрес в параметрах подписи.
Частая ошибка — считать проблему закрытой после revoke в одной сети. Approvals изолированы по сетям: allowance в Ethereum и allowance в Arbitrum — это разные записи в разных контрактах, поэтому разрешение может оставаться активным в другой сети.
Если вы переносите ликвидность между сетями, проверяйте approvals после кроссчейн-операций: мосты и роутеры часто требуют approve на отдельный spender в каждой сети. Как работают и какие безопаснее.
Дополнительную путаницу создают подписи без газа. Permit и похожие механики воспринимаются как «мягкие» подтверждения, но результат тот же: приложение получает возможность установить разрешение, которое затем используется для списания.
Ошибки усиливаются, когда один кошелёк используют одновременно для хранения, активной торговли и экспериментов. В таком режиме один лишний spender/operator создаёт доступ к активам, которые не были частью исходной операции.
Основная угроза approvals — это активные разрешения, которые остаются в контрактах после завершения задачи. Unlimited allowance, включённый operator для NFT и разрешения в нескольких сетях увеличивают объём активов, доступных для списания без новых подтверждений.
Разрешения проверяются отдельно по каждой сети: allowance и списки operator в Ethereum не совпадают с Arbitrum, Optimism, Polygon или BSC, потому что записи прав хранятся в контрактах конкретной сети.
Где проверять разрешения: что именно смотреть и в каком порядке
Проверка разрешений — это последовательность шагов по сетям и типам активов. ERC-20 и NFT используют разные механики доступа, поэтому их нужно анализировать отдельно и закрывать в приоритетном порядке: сначала неизвестные адреса и широкие лимиты, затем оставшиеся рабочие разрешения.
- Определите сеть с максимальной активностью
- Разрешения не «общие»: Ethereum, Arbitrum, Optimism, Polygon, BSC — отдельные списки approvals.
- Начинайте с сети, где сосредоточена ликвидность и были последние транзакции.
- Проверьте ERC-20 approvals и сократите лишнее
- Приоритет — неизвестный spender и unlimited allowance на стейблкоины и ликвидные токены.
- Удаляйте неиспользуемые разрешения и снижайте лимиты до суммы, которая нужна для текущей операции.
- Проверьте NFT approvals отдельно
- Особое внимание —
setApprovalForAll для маркетплейсов и игровых dApp. - Оставляйте operator только на период, когда он реально нужен.
- Особое внимание —
- Сверьте адреса, которые оставляете активными
- Сверьте spender/operator с сервисами, которым вы доверяете, по адресу в подписи или в эксплорере.
- Если адрес не узнаётся — обнулите allowance или отключите operator и выдайте новое разрешение только при необходимости.
| Подход | Что проверяет | Сильная сторона | Ограничение |
|---|---|---|---|
| Блокчейн-сканер сети | ERC-20 allowance и часто NFT approvals | Данные из сети, без доверия к интерфейсу dApp | Нужно переключать сети и анализировать адреса |
| Revoke-сервисы | Разрешения по токенам и NFT в выбранной сети | Список + кнопка обнуления allowance/отключения operator | Покрытие зависит от сети и интеграций |
| Кошельки с симуляцией | Spender, лимиты, предупреждения до подписи | Видно, какой адрес получит права до подтверждения | Разная глубина отображения approvals |
На что смотреть в списке разрешений
- Неизвестный spender или operator. Если адрес не узнаётся, это кандидат на отзыв.
- Unlimited allowance на ликвидные активы. Большой allowance увеличивает доступный объём списания.
- Разрешения в L2 и сайдчейнах. Approvals могут оставаться активными в сетях, где вы давно не делали транзакций.
- NFT-операторы без текущей необходимости. Активный operator позволяет переводить NFT без новых подтверждений.
- Прокси-контракты и апгрейды. Approve привязан к адресу spender, поэтому старое разрешение остаётся активным даже при смене логики через апгрейд.
Логика проверки: сначала обнуляйте allowance у неизвестных адресов и убирайте unlimited на чувствительных токенах, затем сокращайте оставшиеся лимиты до суммы, которая нужна для текущих операций.
Проверка разрешений должна совпадать с тем, как они хранятся: отдельные сети, отдельные токены, отдельные spender/operator. Приоритет unknown и unlimited закрывает основные сценарии списания без новых подтверждений.
Revoke — это транзакция, которая устанавливает allowance в 0 для пары owner→spender→token или переключает
Как отозвать разрешения (revoke) правильно: токены, NFT и частые ошибки
Revoke — это on-chain транзакция, которая меняет allowance или отключает NFT-оператора. В результате в контракте фиксируется новое состояние: конкретный адрес больше не имеет права управлять вашими активами. Revoke останавливает будущие списания, но не отменяет уже выполненные транзакции.
Пошаговый алгоритм revoke для ERC-20
- Определите сеть. Approvals изолированы по сетям: Ethereum, Arbitrum, Optimism и другие L2 имеют отдельные списки разрешений.
- Найдите токен и spender. Проверьте адрес контракта токена, название токена и текущий лимит allowance, особенно для стейблкоинов и ликвидных активов.
- Выполните revoke. Стандартный вариант — установка allowance в 0 через вызов approve(spender, 0) или кнопку revoke в сервисе.
- Проверьте результат. Убедитесь, что allowance стал 0 и разрешение больше не отображается как активное.
Пошаговый алгоритм revoke для NFT
- Откройте список операторов коллекции. Ищите активные
setApprovalForAll и связанные адреса operator. - Отключите оператора. Статус должен быть переведён в false.
- Повторите для ключевых коллекций. Проверяйте коллекции с наибольшей стоимостью и ликвидностью в первую очередь.
Частая ошибка: revoke сделан в одной сети, а в другой сети allowance или статус operator остаётся активным. Если вы работали через мосты, агрегаторы и мультисетевые dApp, проверяйте approvals в каждой сети отдельно.
Нюанс ERC-20: некоторые токены требуют последовательность approve(spender, 0) перед установкой нового allowance. В таких случаях revoke начинается с обнуления лимита.
Revoke меняет запись прав в контракте: allowance становится 0 или operator отключается. Чтобы revoke реально закрыл доступ, его нужно выполнять в правильной сети и для правильной пары токен→spender или коллекция→operator.
Если вы выдали approve/permit или
Если вы уже выдали опасный approve: быстрый план снижения ущерба
В этой ситуации решает порядок действий: сначала нужно убрать активы из-под действия активных разрешений, затем обнулить allowance и отключить operator, и только после этого разбираться с источником подписи.
При подозрении на
- Выведите активы на «чистый» адрес. Новый кошелёк с новой сид-фразой разрывает связь с текущими approvals, потому что allowance и operator привязаны к старому owner-адресу.
- Отзовите разрешения на скомпрометированном адресе. Обнулите allowance у spender для стейблкоинов и ликвидных токенов, затем — у остальных токенов.
- Проверьте NFT-разрешения. Отключите
setApprovalForAll у operator, которые не нужны. - Отключите dApp-подключения в кошельке. Это не меняет allowance, но убирает активные сессии сайта, который может снова запросить подпись.
- Изолируйте среду. Если есть риск вредоносного расширения или подмены сайта, используйте другой браузер или устройство.
Не соглашайтесь на «тестовые переводы», «проверку безопасности» или «возврат средств» по совету посторонних. Такие запросы часто используются, чтобы получить новую подпись или прямой перевод.
После выдачи опасного разрешения приоритет — уменьшить объём активов, доступных через allowance/operator, и затем обнулить эти права транзакциями revoke. До тех пор, пока права активны, списание может произойти без новых подтверждений.
Профилактика approval phishing сводится к контролю двух параметров: кому выдаётся право (spender/operator) и какой объём/масштаб права выдаётся (allowance или
Профилактика: как выдавать разрешения так, чтобы не стать удобной целью
Профилактика approval phishing строится на управлении разрешениями: разделении ролей адресов, ограничении allowance и отключении operator после завершения задачи.
Большинство потерь связано с активными разрешениями, которые остаются в контрактах после завершения операции: unlimited allowance, включённый operator для NFT и привычка подтверждать подписи без проверки адреса. Эти записи прав позволяют списание без новых подтверждений до момента revoke.
Разделение ролей кошельков
Использование одного адреса для хранения, торговли и экспериментов делает любой approve критичным для всего баланса на этом адресе. Разделение адресов ограничивает объём активов, который оказывается доступен через allowance или operator. Если вы выбираете «хранилище» под долгосрок, начните с обзора аппаратных криптокошельков и настройте холодное хранение до активной работы в DeFi.
🧩 Базовая схема из трёх адресов
- Хранилище (долгосрок): основной капитал, минимум dApp-взаимодействий, отсутствие активных approvals.
- Операционный адрес: регулярные DeFi-операции, ограниченный баланс, плановый контроль allowance и operator.
- Экспериментальный адрес: airdrop, NFT, новые проекты; риск ограничен суммой, которая на нём хранится.
Снижение масштаба каждого разрешения
Даже при работе с проверенными сервисами учитывайте сценарий ошибки или компрометации spender/operator. Для ERC-20 масштаб права задаёт allowance, для NFT масштаб задаёт статус
- Используйте точные лимиты. Allowance задаёт максимум токенов, которые spender может списать.
- Обнуляйте allowance после завершения задачи. Это прекращает право списания через
transferFrom . - Проверяйте адрес spender. Разрешение выдаётся адресу в параметрах подписи, а не «сайту».
- Отключайте setApprovalForAll после задачи. Operator не должен оставаться активным после листинга или игровой сессии.
- Не подтверждайте подпись из-за срочности. Срочность часто используют, чтобы подпись не проверяли.
Режим ревизии: когда проверять approvals
- После разовой операции. Если сервис не используется регулярно, обнулите allowance или отключите operator после завершения операции.
- Для операционного DeFi-адреса. При постоянной активности делайте ревизию approvals раз в одну–две недели и удаляйте лишние разрешения.
- Для экспериментального адреса. Для новых dApp и airdrop проверяйте и закрывайте разрешения после каждой сессии.
Рабочая модель: approve/permit задаёт право конкретному адресу, allowance задаёт лимит, revoke меняет лимит на 0 или отключает operator.
Профилактика approvals — это управление активными разрешениями: разделение адресов, точные лимиты allowance и отключение operator после задачи уменьшают объём активов, доступных для списания без новых подтверждений.
Approve даёт протоколам возможность вызывать
Approve как механизм: сильные стороны и встроенные риски
Approve — фундамент DeFi-инфраструктуры: он позволяет протоколам выполнять операции через
Механика approve — компромисс между хранением активов на своём адресе и автоматизацией действий протокола. Активы остаются на вашем адресе, но контракт получает право списания в пределах allowance, заданного в approve.
✅ Сильные стороны approve
- Активы остаются на адресе владельца до момента списания через
transferFrom . - Протоколы могут выполнять операции без подписи каждого шага, используя allowance.
- Allowance позволяет ограничить максимальный объём списания для конкретного spender.
- Разрешения проверяемы в блокчейне и могут быть обнулены транзакцией revoke.
❌ Встроенные риски approvals
- Разрешение действует до revoke и не зависит от закрытия сайта или отключения кошелька.
- Unlimited allowance увеличивает объём токенов, доступных для списания при компрометации spender.
- Если approve подписан без проверки spender и лимита, право может быть выдано не тому адресу.
SetApprovalForAll для NFT даёт operator право переводить всю коллекцию одним действием.
Approve — это инфраструктурный механизм управления правами. Он удобен, потому что перевод выполняется через allowance без повторной подписи, и рискован, потому что активное разрешение работает до revoke и может быть использовано для списания позже.
Кейсы и уроки: почему «правильный контракт» всё равно может стать проблемой
Даже при работе с легитимными сервисами активные approvals создают риск: уязвимость, апгрейд или подмена фронтенда становятся опасными, если в контракте уже записан allowance или включён operator.
Ключевое свойство approvals — отсутствие «срока жизни». Если разрешение выдано, контракту не нужно повторно запрашивать approve: он использует уже записанные права. Поэтому риск зависит не только от текущего сервиса, но и от списка approvals, который накопился на адресе.
🔓 Кейс 1: уязвимость в легитимном протоколе + unlimited approvals
Пользователь выдаёт unlimited approve протоколу, а позже в логике списаний находят ошибку, позволяющую контракту списывать больше токенов, чем предполагалось.
- Контракт уже имеет право списания через allowance, атака не требует новой подписи владельца.
- Unlimited allowance увеличивает объём списания до размера баланса токена на адресе владельца.
- Пользователи, которые не делают новых транзакций, остаются уязвимыми, пока allowance не обнулён.
Unlimited approve превращает баг в протоколе в риск для всего баланса токена на адресе. Точный allowance ограничивает максимум списания, а revoke прекращает право списания.
🧩 Кейс 2: апгрейд proxy-контракта меняет поведение доступа
Апгрейдируемые контракты сохраняют адрес, но код по этому адресу может измениться после апгрейда или компрометации управления.
- Approve привязан к адресу spender, а не к конкретной версии кода.
- После апгрейда новый код может использовать allowance иначе, чем ожидал владелец.
- Старый allowance остаётся активным, пока его не обнулят транзакцией.
При апгрейдах протоколов старые approvals нужно пересматривать, потому что allowance остаётся активным на том же адресе spender.
🧠 Кейс 3: подмена фронтенда при сохранении бренда
Пользователь заходит на знакомый сайт, но интерфейс подменён через DNS, рекламу, CDN или вредоносные расширения.
- Внешний вид интерфейса совпадает с привычным.
- Approve или permit выдаётся адресу, который не является контрактом сервиса.
- Проверка spender/operator в подписи выявляет подмену, бренд и дизайн не выявляют.
Ориентируйтесь на адрес spender/operator и лимит allowance в подписи, а не на домен и оформление страницы.
🛰️ Кейс 4: агрегаторы и роутеры как широкий шлюз доступа
Агрегаторы и маршрутизаторы используют один spender для множества маршрутов и протоколов.
- Один адрес spender обслуживает много сценариев и много токенов.
- Если spender будет скомпрометирован, риск распространяется на всех, кто выдавал ему allowance.
- Unlimited allowance увеличивает объём списания, доступный через этот адрес.
Для роутеров лимит allowance определяет максимум списания, а регулярный revoke убирает старые разрешения, которые больше не нужны.
🖼️ Кейс 5: setApprovalForAll для NFT остаётся активным годами
- Это статус оператора, а не лимит по количеству NFT.
- Даже без активности operator остаётся включённым в контракте коллекции.
- Компрометация operator даёт возможность перевести NFT без новой подписи владельца.
Отключение
Инцидент становится возможным, когда в контракте уже записан allowance или включён operator. В этот момент списание может быть выполнено без новой подписи владельца.
На практике инциденты возникают из-за разрешений, оставшихся после завершённых операций. Регулярная проверка, отключение лишних allowance и operator ограничивают объём активов, доступных для списания без новой подписи.
FAQ помогает понять, какие подписи выдают права, как работает revoke и почему списание возможно без повторного подтверждения.
FAQ по approval phishing, approve и revoke
Почему говорят «опустошили без подписи», если я что-то подписывал?
Подпись была на выдачу прав, а не на перевод средств. После approve, permit или
Unlimited approve — это всегда ошибка?
Unlimited approve записывает в allowance очень большое значение. Это увеличивает максимум токенов, которые spender может списать через
Revoke может вернуть украденные средства?
Нет. Revoke меняет состояние контракта только на будущее: allowance становится 0 или operator отключается. Уже выполненные транзакции не отменяются.
Удаление кошелька или «отвязка сайта» убирает approvals?
Нет. Разрешения хранятся в блокчейне внутри контрактов токенов и NFT. Отключение сайта или удаление приложения не меняют allowance и статус operator в контракте.
Где именно хранится approve?
В состоянии смарт-контракта. Для ERC-20 это запись allowance(owner, spender), для NFT это approvals и operators в контракте коллекции.
Можно ли ограничить approve конкретной суммой?
Да. В approve передаётся параметр amount, и именно он задаёт значение allowance. Spender не сможет списать больше, чем позволяет текущее allowance.
Что опаснее: approve на токен или setApprovalForAll на NFT?
Обычно
Нужно ли проверять approvals в L2 и сайдчейнах?
Да. Каждая сеть хранит свои записи прав в своих контрактах. Allowance в Ethereum и allowance в Arbitrum — это разные значения, поэтому проверка только одной сети не показывает разрешения в других сетях.
Аппаратный кошелёк защищает от approval phishing?
Аппаратный кошелёк защищает приватный ключ и подпись от кражи на устройстве, но не меняет смысл подписываемого действия. Опасный approve/permit или
FAQ сводится к одной проверяемой разнице: подпись может выдавать права (approve/permit/
Одно ошибочное approve/permit или
Как защититься от approval phishing и держать разрешения под контролем
Разрешения — основа DeFi-механик, но именно allowance и статус operator позволяют выводить активы без повторной подписи, если право было выдано «лишнему» адресу.
Approval phishing — это злоупотребление легитимными правами. Один approve/permit или
Чтобы на адресе не оставались активные права, держите контроль через конкретные действия:
- Проверяйте адрес доступа. Важен spender/operator в подписи и в списке approvals, а не бренд и дизайн.
- Ограничивайте allowance. Задавайте лимит под задачу вместо unlimited и обнуляйте allowance, когда право больше не нужно.
- Отключайте operator для NFT. Не оставляйте
setApprovalForAll включённым после завершения действия. - Проверяйте все сети. Allowance и operator хранятся отдельно в каждой сети, поэтому ревизия делается по каждой сети, где был dApp.
- Разделяйте адреса по ролям. Баланс на адресе определяет максимум, который можно списать через активные права на этом адресе.
Относитесь к approvals как к активным правам доступа, записанным в контрактах. Минимальные лимиты allowance, отключение operator и ревизия по всем сетям уменьшают объём активов, доступных для списания без новой подписи.