OWASP Smart Contract Top 10 | OWASP Foundation
Welcome to the OWASP Top Ten for Smart Contracts
Telegram
Noobing Security Research
Уязвимость: Access Control Vulnerabilities Топ 1 уязвимость на 2025 год, согласно списку от OWASP. На первый взгляд кажется, что это очень простая уязвимость, которую можно избежать средствами уровня "не ставь пароль 12345", но на самом деле бывают намного более сложные случаи. ⢑⣁⡰⣀⢐ ⡘ ⢊⠨⢤ ⡘⡂⢨⢄ ⣠⠋⠜⢤⢰⢢⠘⣐⠋ ⠃⠩⢘⢂⡔⢊⠔⣐⠱⠕⢨ ⢂⡂⡘⣂⠥⢠⣀⠤ ⠬⡐⢤⣐⠊⠇⠋⠜ ⡢⠣⠚⠱⣂⠕⠓⡄⠲⡁⢆⠬⡤ ⡑⢤⠣⢒⡃⢢⢐⢤⡘⢰ ⢢ ⢨⢑⢘⠚⡌⡄⢡⢌⠢⢆⠇⠴⡑⡤ ⢃⡁⠓⠱⡡⠔⠰⠌⠴⠦⡑⢨ ⢆⠅⡅⡁⢤⠩⠦ ⡐⠕⡅⠚⢄⠖⠉⠱⡰⡆ ⡁⠥⠋⠍⢔⠍⠲⠙⠃⡆ ⠜⠩⡤⠍⡰⡨⣂⠕⡊⢰⢡⢔ ⢠⠥⢃⠌⢡⢄⡆⠒⢡⢆⠆⡡ ⡉⠋⠱⠤⢅⠲⡐⡡⠪⣂⠊ В чем заключается Строгое определение такое: уязвимость нарушения доступа - это уязвимость, позволяющая неавторизованным пользователям получить доступ и/или изменять данные и/или функции контракта Где искать Возникают чаще всего там, где недостаточно permission checks, например отсутствует модификатор onlyOwner, или функция вывода средств не проверяет что адрес, инициировавший вывод соответствует адресу, с чьего баланса списываются средства. Так же стоит следить за тем, чтобы роли в вашем протоколе не имели бы слишком много полномочий Пример В этой короткой статье рассказывается о то, что у функции burn протокола HospoWise не было модификатора onlyOwner, что привело к тому, что сжигать их токены мог любой желающий Как быть Хорошая новость в том, что такие очевидные нарушения прекрасно детектируются статическими инструментами анализа, так что надо: - использовать статические анализаторы типа slither и aderyn - использовать onlyOwner от OpenZeppelin - тесты тесты тесты Важность тестирования в написании контрактов невозможно переоценить
Telegram
Noobing Security Research
Уязвимость: Price Oracle Manipulation Это критическая уязвимость может быть обнаружена/использована в контрактах, которые зависят от внешних источников данных о цене актива. Схема действия достаточно проста: пользователь собирается купить ETH через ваш контракт за USDC/USDT, контракт принимает сумму, на которую следует совершить обмен, а для расчета покупки используется функция, возвращающая текущую стоимость актива при его покупке например на Uniswap Перед тем, как транзакция выполняется, происходит покупка большого количества одного токена из пары (часто с использованием flash loan буквально на миллиарды долларов), что искажает пропорцию активов в пуле —> искажает цену —> покупка проходит по невыгодной цене —> внесенная ранее ликвидность выносится из пула Либо наоборот, атакующий покупает актив по очень выгодной цене, в зависимости от стратегии атаки Пример Схему на изображении надо читать следующим образом: красные стрелки это путь средств "вглубь" атакуемого контракта, зеленые - это вынос. Все действия происходят в рамках одной транзакции. Схема упрощенная, но суть от этого не меняется Атакуемый контракт называется NFT Protocol, он позволяет купить NFT за 10 долларов 1. Атакующий (Flash Loan Receiver), получает займ 2. Первоначальная цена NFT при составляет 10 USDC или 1 ETH 4. Атакующий свапает на TSwap USDC на WETH (то есть выкупает ETH, эфира остается мало в пуле), меняя таким образом первоначальную пропорцию с 100 к 10 на 1000 к 1 5. 1 ETH теперь стоит 1000 USDC 6. Так как атакующий контракт берет информацию о цене эфира с TSWAP, то продажа NFT с контракта атакующему происходит за 0.01 ETH вместо 1 ETH 7. Атакующий продает NFT в другом месте за полную стоимость 8. Атакующий свапает ETH на USDC обратно, возвращая TSWAP пул в нормальное состояние 9. Атакующий возвращает Flash Loan + комиссии за использование средств 10. Профит атакующего равен цена NFT - комиссии за флешлоан Как защититься - Собирать данные по цене из нескольких источников - Установить пороговые значения для цен - Поставить таймлок на обновление цены, чтобы не допустить мгновенных колебаний - Запрашивать подписи от поставщиков цен Схему взял отсюда
X (formerly Twitter)
Telegram
Noobing Security Research
Ethereum is a dark forest Знакомы ли вы с концепцией темного леса? В последнее время в моем инфополе она чаще всего звучала в контексте сериала «задача трех тел» Если коротко, в темном лесу водятся монстры. Единственный способ выжить - либо быть самым сильным, либо не подавать признаков жизни. Подробнее на Википедии Казалось бы, при чем тут аудит смарт контрактов? Дело в том, что в сети эфира водятся монстры flashbots, которые слушают наши транзакции. И в случае, когда потенциальный профит превосходит затраты на исполнение, они атакуют Таким образом атакующий вектор находится вне плоскости программного слоя, в слое самой сети. Это становится возможным, потому что: - Все транзакции перед включением в блок попадают в mempool, так устроена сеть Ethereum. Мемпул место прозрачное, доступное для чтения - Приоритет газа существует, увеличив газ можно поставить свою транзакцию вперед других К чему приводит такой порядок дел В основном к тому, что атакующий пытается закинуть транзакцию перед или сразу после интересующей его транзакции, либо провести сэндвич-атаку, когда атакуемая транзакция «оборачивается» с двух сторон в манипулятивные транзы. По такому же принципу происходит flashloan атака, писал про нее тут, только там атакующий пишет контракт, а не ловит интересующую его транзакцию в мемпуле В случае, если в вашем контракте неправильно прописаны трансферы, например вы не проверяете кто инициализирует трансфер, флэшбот может воспользоваться этой дырой для вывода средств с контракта как только увидит такую транзакцию в мемпуле Очень крутая статья 2020 года про то как ребята пытались вытащить 12к$, которые застряли на видном, но еще не обнаруженном флешботами месте. Спойлер: ⡘⡌⡃⠍⣠⠘⠲ ⡢⠑⠨⢌⢅⠇⠱⣐ ⠦⠅⢅⢢⢨⠨⡢⠆⡂⢃⢄ ⠬⠇⠅ ⠆⠍⡁⠢⠖⠅ ⡉⠃⠴⢠⠴⡤ ⡆⢠⠱⠡⢈⠦⠢⠌⠎ ⠊ ⡡⠑⠴⠎ Ужас, но не ужас-ужас-ужас В основном флэшботы крутятся вокруг DEX, они арбитражат разность курсов и тем самым вообще-то выполняют очень важную функцию целостности цен по всему маркету. Могут правда зацепиться за крупные транзы и внести манипулятивную составляющую, которая неизбежно возникнет при крупной сделке. Могут подсунуть не самый выгодный курс, вынудив купить по бОльшей цене. Так же они могут первыми показывать на позиции, требующие ликвидации, получая за это бонус. Есть экзотические атаки, трудно выполняемые в текущих условиях сети эфира, но которые вполне серьезно обсуждались до The Merge (переход с PoW на PoS) типа Fee-based forking attacks или Time-bandit attacks. На них я останавливаться не буду, по крайней мере сейчас К посту прикладываю одну из первых системных статей по теме, она 2019 года. Какие-то части чуть устарели, но в ней классно описан математически аппарат того, как боты действуют, что лежит в основе их конкуренции и сотрудничества. Любителям теории игр будет интересно Это первый пост вводный пост по теме flashbots, дальше будет подробнее про виды атак, про способы защиты ваших протоколов и еще больше источников и статей https://t.me/web3securityresearch
Telegram
Noobing Security Research
Разбирая MEV: Кто такой этот ваш PBS Для того, чтобы начать тему защиты от MEV, надо углубиться в то, как устроена работа сети эфира на данный момент В 2022 году, во время The Merge произошел переход к архитектуре Proposer-Builder Separation (PBS). Суть ее заключается в том, что собирает блок builder, а включает его в сеть proposer (валидатор). До этого момента сборкой и предложением блоков сети занимался один актор, что вело к доминации крупных институционалов На данный момент PBS реализуется через промежуточное ПО, носящее название MEV-Boost. Это опенсорсный проект, разработанный Flashbots. То, что я пишу здесь по большей части базируется на документации FlashBots Auction Стоит отметить, что валидаторы по прежнему могут строить блоки самостоятельно На изображении представлен флоу, по которому транзакция движется от бандла до блока, включенного в цепочку. От сёрчера до валидатора. Эта схема называется Flashbots Auction В процессе участвуют несколько акторов/сущностей: - Искатели/сёрчеры (Searchers). Собирают транзакции в публичном и/или приватном мемпуле так, чтобы максимизировать выгоду. Они собирают транзакции в - Бандлы (Bundles). Массив независимых транзакций, сопровождающихся метаданными, содержащими условия исполнения. Все транзакции должны быть исполнены в том порядке, в котором их собрал сёрчер, причем бандл обладает атомарностью. Сёрчер отправляет бандл дальше по цепочке билдеру. - Строитель/Билдер (Builder). Его задача - сборка из бандлов наиболее прибыльного блока. Билдер видит все транзакции. Он передает собранный блок в реле - Реле/релэй (Relay). Это доверенный посредник между билдерами и валидаторами. Собирает готовые блоки, выбирает самый выгодный вариант для передачи валидатору При этом и сёрчеры, и билдеры, и реле имеют свой высококонкурентный рынок игроков Важно, что реле не отправляют валидаторам сразу готовые блоки, сначала отправляются заголовок самого доходного блока. Если валидатор возвращает подписанный заголовок реле, то получает в ответ полный блок, который предлагает для включения в блокчейн Кроме того, вся схема называется аукционом не просто так: сёрчеры и билдеры вынуждены отправлять дальше по цепочке bids (ставки), чтобы следующий актор выбрал их предложение. При этом сами транзакции могут быть скрыты до включения в блок В прошлом посте я писал, что MEV бот зафронтранил хакера. Он мог бы этого избежать, если бы использовал приватный мемпул, тем более, что для этого нужен был простой советский.. нужно было использовать приватный RPC Этот RPC прокидывает транзакцию в приватный мемпул, ну а дальше вы знаете, её подхватывает сёрчер https://t.me/web3securityresearch
rekt
Rekt - Home
DeFi / Crypto - Investigative journalism & creative commentary
![Cross Curve $1.4M Implementation Bug [Explained]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/https://ambitious-kindness-505c138052.media.strapiapp.com/Cross_Curve_Implementation_Bug_Explained_a389386222.png)
Cross Curve $1.4M Implementation Bug [Explained]
How a simple implementation bug led to a $1.4M loss at Cross Curve, explained with clear security lessons for DeFi teams.
X (formerly Twitter)
GitHub
GitHub - axelarnetwork/axelar-gmp-sdk-solidity: Solidity libraries and utilities provided by Axelar.
Solidity libraries and utilities provided by Axelar. - axelarnetwork/axelar-gmp-sdk-solidity
GitHub
axelar-gmp-sdk-solidity/contracts/express/AxelarValuedExpressExecutable.sol at main · axelarnetwork/axelar-gmp-sdk-solidity
Solidity libraries and utilities provided by Axelar. - axelarnetwork/axelar-gmp-sdk-solidity
GitHub
EIPs/EIPS/eip-7702.md at master · ethereum/EIPs
The Ethereum Improvement Proposal repository. Contribute to ethereum/EIPs development by creating an account on GitHub.
The Notorious Bug Digest #5: Post EIP-7702 Pitfalls, JIT Penalty Rebates, and Manipulation of Recursive Functions
Explore critical Web3 security insights in OpenZeppelin's Notorious Bug Digest #5: EIP-7702 EOA delegation exploits causing $85K losses, Uniswap v4 JIT liquidity penalty bypasses, and f(x) protocol recursive function vulnerabilities. Essential blockchain security analysis for developers worldwide.
BNB Smart Chain Explorer
Bsc Transaction Hash: 0x8a7c96521a... | BscScan
Call 0x0ff5919e Method By 0x223bf694...AFbe50268 on 0x223bf694...AFbe50268 | Success | Aug-24-2025 11:59:06 PM (UTC)
BNB Smart Chain Explorer
Address: 0x0aeb8c4a...c952feb53 | BscScan
Contract: Unverified | Balance: $0 across 0 Chains | Transactions: 0 | As at Feb-02-2026 02:56:58 PM (UTC)
Overview | Flashbots Docs
Flashbots Auction is a permissionless, transparent, and fair ecosystem for efficient MEV extraction and frontrunning protection which preserves the ideals of Ethereum. Flashbots Auction provides a private communication channel between Ethereum users and validators for efficiently communicating preferred transaction order within a block.
Telegram
Noobing Security Research
Взлом Makina Finance Вчера произошел взлом Makina Finance, атакующий эксплуатировал уязвимость в оракуле MachineShareOracle.sol По сути это Price Oracle Manipulation с использованием flash-loan, которая описана в этом посте, она затронула пул DUSD/USDC (Dialectic USD/USDC Stableswap pool) на Curve Finance. Makina Finance быстро отреагировала, активировав security mode но я решил написать про эту атаку потому, что бОльшую часть прибыли атакующего перехватил MEV-бот, который зафронтранил транзакцию атакующего, оказывается так тоже бывает Получается, что крупным протоколам было бы неплохо иметь своих ботов на страже Про подобных ботов я писал разбор статьи https://t.me/web3securityresearch
Telegram
Noobing Security Research
Изучаю и пишу про безопасность смарт контрактов
GitHub
makina-periphery/src/oracles/MachineShareOracle.sol at main · MakinaHQ/makina-periphery
Makina periphery smart contracts. Contribute to MakinaHQ/makina-periphery development by creating an account on GitHub.
Telegram
Noobing Security Research
Уязвимость: Price Oracle Manipulation Это критическая уязвимость может быть обнаружена/использована в контрактах, которые зависят от внешних источников данных о цене актива. Схема действия достаточно проста: пользователь собирается купить ETH через ваш контракт за USDC/USDT, контракт принимает сумму, на которую следует совершить обмен, а для расчета покупки используется функция, возвращающая текущую стоимость актива при его покупке например на Uniswap Перед тем, как транзакция выполняется, происходит покупка большого количества одного токена из пары (часто с использованием flash loan буквально на миллиарды долларов), что искажает пропорцию активов в пуле —> искажает цену —> покупка проходит по невыгодной цене —> внесенная ранее ликвидность выносится из пула Либо наоборот, атакующий покупает актив по очень выгодной цене, в зависимости от стратегии атаки Пример Схему на изображении надо читать следующим образом: красные стрелки это путь средств "вглубь" атакуемого контракта, зеленые - это вынос. Все действия происходят в рамках одной транзакции. Схема упрощенная, но суть от этого не меняется Атакуемый контракт называется NFT Protocol, он позволяет купить NFT за 10 долларов 1. Атакующий (Flash Loan Receiver), получает займ 2. Первоначальная цена NFT при составляет 10 USDC или 1 ETH 4. Атакующий свапает на TSwap USDC на WETH (то есть выкупает ETH, эфира остается мало в пуле), меняя таким образом первоначальную пропорцию с 100 к 10 на 1000 к 1 5. 1 ETH теперь стоит 1000 USDC 6. Так как атакующий контракт берет информацию о цене эфира с TSWAP, то продажа NFT с контракта атакующему происходит за 0.01 ETH вместо 1 ETH 7. Атакующий продает NFT в другом месте за полную стоимость 8. Атакующий свапает ETH на USDC обратно, возвращая TSWAP пул в нормальное состояние 9. Атакующий возвращает Flash Loan + комиссии за использование средств 10. Профит атакующего равен цена NFT - комиссии за флешлоан Как защититься - Собирать данные по цене из нескольких источников - Установить пороговые значения для цен - Поставить таймлок на обновление цены, чтобы не допустить мгновенных колебаний - Запрашивать подписи от поставщиков цен Схему взял отсюда
Telegram
Noobing Security Research
Ethereum is a dark forest Знакомы ли вы с концепцией темного леса? В последнее время в моем инфополе она чаще всего звучала в контексте сериала «задача трех тел» Если коротко, в темном лесу водятся монстры. Единственный способ выжить - либо быть самым сильным, либо не подавать признаков жизни. Подробнее на Википедии Казалось бы, при чем тут аудит смарт контрактов? Дело в том, что в сети эфира водятся монстры flashbots, которые слушают наши транзакции. И в случае, когда потенциальный профит превосходит затраты на исполнение, они атакуют Таким образом атакующий вектор находится вне плоскости программного слоя, в слое самой сети. Это становится возможным, потому что: - Все транзакции перед включением в блок попадают в mempool, так устроена сеть Ethereum. Мемпул место прозрачное, доступное для чтения - Приоритет газа существует, увеличив газ можно поставить свою транзакцию вперед других К чему приводит такой порядок дел В основном к тому, что атакующий пытается закинуть транзакцию перед или сразу после интересующей его транзакции, либо провести сэндвич-атаку, когда атакуемая транзакция «оборачивается» с двух сторон в манипулятивные транзы. По такому же принципу происходит flashloan атака, писал про нее тут, только там атакующий пишет контракт, а не ловит интересующую его транзакцию в мемпуле В случае, если в вашем контракте неправильно прописаны трансферы, например вы не проверяете кто инициализирует трансфер, флэшбот может воспользоваться этой дырой для вывода средств с контракта как только увидит такую транзакцию в мемпуле Очень крутая статья 2020 года про то как ребята пытались вытащить 12к$, которые застряли на видном, но еще не обнаруженном флешботами месте. Спойлер: ⡘⡌⡃⠍⣠⠘⠲ ⡢⠑⠨⢌⢅⠇⠱⣐ ⠦⠅⢅⢢⢨⠨⡢⠆⡂⢃⢄ ⠬⠇⠅ ⠆⠍⡁⠢⠖⠅ ⡉⠃⠴⢠⠴⡤ ⡆⢠⠱⠡⢈⠦⠢⠌⠎ ⠊ ⡡⠑⠴⠎ Ужас, но не ужас-ужас-ужас В основном флэшботы крутятся вокруг DEX, они арбитражат разность курсов и тем самым вообще-то выполняют очень важную функцию целостности цен по всему маркету. Могут правда зацепиться за крупные транзы и внести манипулятивную составляющую, которая неизбежно возникнет при крупной сделке. Могут подсунуть не самый выгодный курс, вынудив купить по бОльшей цене. Так же они могут первыми показывать на позиции, требующие ликвидации, получая за это бонус. Есть экзотические атаки, трудно выполняемые в текущих условиях сети эфира, но которые вполне серьезно обсуждались до The Merge (переход с PoW на PoS) типа Fee-based forking attacks или Time-bandit attacks. На них я останавливаться не буду, по крайней мере сейчас К посту прикладываю одну из первых системных статей по теме, она 2019 года. Какие-то части чуть устарели, но в ней классно описан математически аппарат того, как боты действуют, что лежит в основе их конкуренции и сотрудничества. Любителям теории игр будет интересно Это первый пост вводный пост по теме flashbots, дальше будет подробнее про виды атак, про способы защиты ваших протоколов и еще больше источников и статей https://t.me/web3securityresearch
Telegraph
AI-агенты с фальшивыми воспоминаниями: атака на web3-агентов манипуляцией контекстом, часть 1.
Канал Noobing Security Research Это обзорный перевод статьи "Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents, 2025, Atharv Singh Patlan, Peiyao Sheng, S. Ashwin Hebbar, Prateek Mittal, Pramod Viswanath" Перевод не дословный. При переводе я стараюсь донести суть, по возможности сокращая текст. Если вы нашли смысловые неточности в тексте, прошу написать в сообщения каналу по ссылке выше. Термины, указанные в скобках - то, как авторы называют те или иные сущности/явления.
Telegraph
AI-агенты с фальшивыми воспоминаниями: атака на web3-агентов манипуляцией контекстом, часть 2.
Канал Noobing Security Research Это обзорный перевод статьи "Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents, 2025, Atharv Singh Patlan, Peiyao Sheng, S. Ashwin Hebbar, Prateek Mittal, Pramod Viswanath" Перевод не дословный. При переводе я стараюсь донести суть, по возможности сокращая текст. Если вы нашли смысловые неточности в тексте, прошу написать в сообщения каналу по ссылке выше. Термины, указанные в скобках - то, как авторы называют те или иные сущности/явления.
Telegram
Noobing Security Research
Изучаю и пишу про безопасность смарт контрактов
Telegram
Сиолошная
AI agents find $4.6M in blockchain smart contract exploits LLM всё лучше справляются с задачами в сфере кибербезопасности, о чём я уже писал ранее (вот про релиз Google, вот про CTF, вот Cybench). Но каковы экономические последствия этих возможностей? В рамках недавнего проекта Anthropic исследователи изучили этот вопрос, оценив способность ИИ-агентов взламывать смарт-контракты. Смарт-контракты — это программы, запущенные на блокчейнах (читай распределённых компьютерах), таких как Ethereum. Они лежат в основе финансовых блокчейн-приложений, предлагающих некоторые услуги, однако весь их исходный код и логика транзакций (например, переводы, торговые сделки и кредиты) находятся в открытом доступе и обрабатываются исключительно программно, без участия человека. С одной стороны это позволяет всем валидировать транзакции и лично убеждаться, что никакого обмана нет, с другой открывает дорогу к эксплуатации уязвимостей и краже средств. Существующие бенчмарки в сфере кибербезопасности упускают важное измерение: они…
Smart Contracts \ red.anthropic.com
Telegram
Noobing Security Research
Уязвимость: Inflation Attack/Donation attack Этот пост написан на основе треда security researcher Kankodu Итак, мы знаем, что такое инфляционная атака и как можно защититься и даже применяем это на практике. Этот отчет о уязвимости мне понравился потому, что демонстрирует важность консистентности работы с выпускаемыми токенами. Всё должно подчиняться единым правилам, иначе - дрейн Речь пойдет об уязвимости в лендинг протоколе Vesuxyz, которая возникала в момент добавления нового asset’a к пулам коллатералов. Сама уязвимость уже исправлена и внесенные изменения можно посмотреть здесь Протокол VESU поддерживает деплой нескольких пулов, каждый из которых является лендинг маркетом с разными парами коллатерал - займ. Для каждой пары свой LTV (Loan-to-Value - сколько можно занять под свой залог). Такая структура позволяет использовать очень разные вариации займов. Существует Genesis pool, который содержит значительный TVL и который по сути является обычным лендинг маркетом с поддержкой регипотеки ⠆⠕⣄⠥⢅⡨⠃⡂⢃⣄⠸⢘⠘⢊⣠⢘…
Telegram
Noobing Security Research
Изучаю и пишу про безопасность смарт контрактов
Telegram
Noobing Security Research
Тесты? Тесты. Часть 2 6 слой. Stateful Fuzz тесты/Тесты инварианта Инвариант - это состояние/поведение вашего контракта, которое не должно нарушаться ни при каких обстоятельствах. Из-за того, что само слово invariant несколько перегружено смыслами, то получается, что так называют и это нерушимое правило и способ тестирования. Отличие от stateless в том, что в этом случае генерируемые фаззером значения отправляются на один и тот же экземпляр/экземпляры контракта/функций. Из-за этого его сложнее написать, это тоже достойно отдельного поста. Суть там следующая, если не зарываться в техническое: мы создаем экземпляр контракта, выбираем какие функции из него собираемся тестировать в связке, а потом в случайном порядке подаем им случайные значения на вход. Если какая то последовательность вызовов функции нарушает наш инвариант, то мы увидим в логах всю цепочку вызовов, приведшую к ошибке. Огромное отличие от теста без сохранения состояния в том, что мы к тому же можем ограничивать подаваемые на вход значения, чтобы…
Certora
Industry-leading formal verification tools and smart contract audits.
The Certora Verification Language — Certora Prover Documentation 0.0 documentation
Telegram
Noobing Security Research
Какие бывают аудиты Продолжаю обозревать теорию, потому что практика должна иметь базис Существует два вида аудита: приватный (private) и соревновательный (competitive). В определенных рамках делать придется одно и то же, но по разному будут расставлены акценты. Для аудита конечная цель - сделать протокол более безопасным, это понятно. В приватном вы оказываете услуги проекту/фирме/кто-там-вам-заказал-аудит и он, как правило, не публичный, то есть отчет вы если и сможете закинуть себе в портфолио, то с некоторой задержкой. Соревновательный проходит на платформах типа codehawks, протоколы там выкладываются перед деплоем, а награда делится среди нашедших уязвимости. Сейчас на codehawks нет актуальных соревнований, но есть на code4rena. Там же через 9 дней стартует аудит для Chainlink с призовым пулом в $200k в USDC и продолжительностью в месяц В случае приватного аудита в процесс включается: - работа с командой протокола, возможно придется учить людей лучшим практикам, например обращать внимание, что в коде не должно быть магических чисел и для storage переменных хорошо бы использовать префикс s_ - анализ полноты и содержания тестов - отработка критических ситуаций, буквально команда может позвонить и сказать что-то в духе "нас ломают, помоги выбраться из собаки ситуации" Фокус в приватном аудите стоит не сколько на поиске уязвимостей, сколько на повышении качества кодовой базы Для соревновательного аудита главное - количество уязвимостей, которые вы обнаружили. Рассказать проекту как бы вы их убрали тоже надо, но поскольку обычно есть ограничение по времени (1-4 недели), то фокус стоит на количестве и тяжести найденного Приватный аудит технически ограничен по времени тоже, но в этом случае работа итеративная, потому что аудит вы проводите на конкретный код, с конкретным хэшем коммита, то есть после того как ваши замечания исправили, ваш аудит по сути не актуален для обновленной версии и это нормально, про стадии аудита детальнее я расскажу позже
GitHub
GitHub - crytic/echidna: Ethereum smart contract fuzzer
Ethereum smart contract fuzzer. Contribute to crytic/echidna development by creating an account on GitHub.
.png)
Cyfrin Updraft
Learn Assembly and Formal Verification - Cyfrin Updraft
Learn how the solidity compiler and opcodes work. Write contracts with Assembly and Yul, learn to write formal verification tests to guarantee your invariants hold.
GitHub
GitHub - a16z/halmos: A symbolic testing tool for EVM smart contracts
A symbolic testing tool for EVM smart contracts. Contribute to a16z/halmos development by creating an account on GitHub.
Telegram
Noobing Security Research
Уязвимость: Inflation Attack/Donation attack Этот пост написан на основе треда security researcher Kankodu Итак, мы знаем, что такое инфляционная атака и как можно защититься и даже применяем это на практике. Этот отчет о уязвимости мне понравился потому, что демонстрирует важность консистентности работы с выпускаемыми токенами. Всё должно подчиняться единым правилам, иначе - дрейн Речь пойдет об уязвимости в лендинг протоколе Vesuxyz, которая возникала в момент добавления нового asset’a к пулам коллатералов. Сама уязвимость уже исправлена и внесенные изменения можно посмотреть здесь Протокол VESU поддерживает деплой нескольких пулов, каждый из которых является лендинг маркетом с разными парами коллатерал - займ. Для каждой пары свой LTV (Loan-to-Value - сколько можно занять под свой залог). Такая структура позволяет использовать очень разные вариации займов. Существует Genesis pool, который содержит значительный TVL и который по сути является обычным лендинг маркетом с поддержкой регипотеки ⠆⠕⣄⠥⢅⡨⠃⡂⢃⣄⠸⢘⠘⢊⣠⢘…
Telegram
Noobing Security Research
Изучаю и пишу про безопасность смарт контрактов
Telegram
Noobing Security Research
AI нам поможет? Если коротко, то ситуация с AI такая же, как и в остальных сферах, т.е. не панацея, но инструмент В этой области я решил опираться на научные статьи, коих к моему удивлению не прям много Первой стала Demystifying exploitable bugs on smart contracts 2023 года выпуска, не очень свежо по меркам AI, но не так давно, если подумать Не буду подробно на ней останавливаться, скажу только, что там коллектив авторов, написано хорошо, но главное - согласно исследованию агенты находили не более 20% уязвимостей! Как так вышло авторы сказать не могут, но велика вероятность, что контракты, которые они проверяли еще при разработке подвергались анализу с помощью AI и потому «легкие» баги уже были вычищены. Главная проблема была в том что для поиска уязвимостей требуется анализировать высокоуровневую логику вкупе с низкоуровневой имплементацией и в 2023 у LLM были с этим проблемки В общем, в 2023 было прям не очень Но! 31 марта 2025 года вышло продолжение (часть авторов та же), где они рассказывают о своем новом методе PromFuzz, который набирает 86.96% recall и 93.02% по f1! За метрики оценки сетей я сейчас вам рассказывать не буду, но это впечатляющий прогресс Так, подводящую часть закончил 😂 В общем, я эту статью буду здесь разбирать, если владеете английским и хотите прочесть побыстрее, то скачивайте прикрепленный файл
Telegram
Noobing Security Research
Изучаю и пишу про безопасность смарт контрактов
