در حال آمادهسازی صوت...
تعریف کوتاه برای گوگل
هک قرارداد هوشمند Smart contract hacking زمانی رخ میدهد که مهاجم از خطاهای منطقی، ضعفهای کدنویسی، طراحی اشتباه اقتصادی یا وابستگیهای خارجی یک قرارداد روی Blockchain سوءاستفاده میکند. این حملات معمولاً کلید خصوصی را نمیشکنند؛ بلکه قواعد خود قرارداد را علیه داراییهای قفلشده در آن به کار میگیرند.
چرا قراردادهای هوشمند با وجود شفافیت هک میشوند؟ Smart contract hacking
قرارداد هوشمند قرار است «کد قابل اعتماد» باشد؛ اما همین ویژگی، نقطه خطر آن نیز هست. وقتی یک قرارداد روی Ethereum یا شبکههای مشابه منتشر میشود، منطق آن در بسیاری از موارد تغییرناپذیر، عمومی و قابل تعامل برای همه است. اگر یک خطای کوچک در منطق برداشت، قیمتگذاری، دسترسی یا محاسبه وجود داشته باشد، مهاجم به جای نفوذ سنتی، فقط همان منطق ناقص را اجرا میکند.
اهمیت این موضوع در DeFi بیشتر دیده میشود. پروتکلهای وامدهی، صرافیهای غیرمتمرکز، استخرهای نقدینگی، پلهای بینزنجیرهای و Wallets هوشمند، داراییهای واقعی کاربران را به کد متصل میکنند. بنابراین یک خطای نرمافزاری میتواند مستقیماً به خروج سرمایه منجر شود، نه فقط از کار افتادن یک سرویس.
در گزارشها و منابع امنیتی ۲۰۲۵ و ۲۰۲۶، آسیبپذیریهایی مانند کنترل دسترسی، خطای منطق، بازدرآمدی، دستکاری اوراکل و حملات فلشلون همچنان در فهرست مهمترین ریسکهای قرارداد هوشمند قرار دارند. OWASP نیز نسخه ۲۰۲۶ Smart Contract Top 10 را به عنوان سند آگاهیبخشی برای توسعهدهندگان Web3 و تیمهای امنیتی معرفی کرده است.
هک قرارداد هوشمند Smart contract hacking در سطح فنی چگونه اتفاق میافتد؟
قرارداد هوشمند مجموعهای از توابع، متغیرهای وضعیت، مجوزها و تعاملات خارجی است. هر تراکنش، یک تابع را فراخوانی میکند و باعث تغییر وضعیت قرارداد میشود. اگر ترتیب تغییر وضعیت، اعتبارسنجی ورودی، سطح دسترسی یا تعامل با قراردادهای دیگر درست طراحی نشده باشد، مسیر حمله شکل میگیرد.
نکته کلیدی این است که مهاجم معمولاً «بلاکچین» را هک نمیکند. Bitcoin از اساس برای منطق پیچیده قراردادهای هوشمند طراحی نشده است و بیشتر به امنیت دفترکل و انتقال ارزش متکی است؛ این همان جایی است که میتوان به مقاله داخلی «بلاکچین چیست» لینک داد. در مقابل، Ethereum محیطی عمومی برای اجرای قراردادهای هوشمند فراهم کرد؛ بنابراین موضوع «قرارداد هوشمند چیست» در اکوسیستم اتریوم اهمیت مرکزی دارد.
در حملات قرارداد هوشمند، مهاجم به دنبال شکاف میان «قصد طراح» و «رفتار واقعی کد» است. طراح ممکن است تصور کند فقط مالک قرارداد میتواند دارایی را منتقل کند، اما اگر تابعی عمومی باشد یا اعتبارسنجی نقشها ناقص انجام شود، قرارداد چیز دیگری اجرا میکند. مستندات Ethereum نیز کنترل دسترسی صحیح را یکی از اصول پایه امنیت قراردادهای هوشمند معرفی میکند.
معماری سیستم؛ قرارداد هوشمند تنها یک قطعه نیست
یک قرارداد هوشمند در خلأ کار نمیکند. بیشتر حملات جدی از تعامل چند لایه ایجاد میشوند:
۱. لایه قرارداد اصلی
این لایه شامل منطق سپردهگذاری، برداشت، رأیگیری، وامدهی، سواپ یا مدیریت دارایی است. خطاهای بازدرآمدی، محاسبات اشتباه، نبود محدودیت برداشت و نقص در اعتبارسنجی ورودی معمولاً از اینجا شروع میشوند.
۲. لایه دسترسی و مالکیت
قراردادها معمولاً نقشهایی مانند مالک، مدیر، اپراتور، خزانهدار یا رأیدهنده دارند. اگر این نقشها درست تفکیک نشوند، یک کلید لو رفته یا یک تابع اشتباه میتواند کل پروتکل را در معرض خطر قرار دهد.
۳. لایه اوراکل
اوراکل قیمت یا داده بیرونی را وارد قرارداد میکند. اگر قرارداد قیمت یک دارایی را از منبع ضعیف، کمعمق یا قابل دستکاری دریافت کند، مهاجم میتواند ارزش وثیقه، نرخ تبدیل یا قیمت تسویه را به نفع خود تغییر دهد.
۴. لایه تعاملات خارجی
قرارداد ممکن است با توکنها، DEXها، Bridges، Wallets و Exchanges تعامل داشته باشد. هر تعامل خارجی یک سطح حمله جدید ایجاد میکند؛ زیرا قرارداد دیگر فقط به منطق خود متکی نیست.
۵. لایه حاکمیت و ارتقا
بسیاری از پروتکلها قابل ارتقا هستند. اگر قرارداد Proxy، مالک ارتقا، رأیگیری DAO یا Timelock درست طراحی نشود، مهاجم میتواند به جای تخلیه مستقیم، ابتدا منطق قرارداد را تغییر دهد.
رایجترین روشهای هک قرارداد هوشمند Smart contract hacking
۱. حمله بازدرآمدی یا Reentrancy
بازدرآمدی زمانی رخ میدهد که قرارداد قبل از بهروزرسانی وضعیت داخلی خود، به یک آدرس یا قرارداد خارجی اجازه تعامل میدهد. اگر آن قرارداد خارجی دوباره تابع قبلی را فراخوانی کند، ممکن است بتواند چند بار برداشت انجام دهد، در حالی که موجودی هنوز کاهش نیافته است.
این حمله به دلیل پرونده تاریخی The DAO در Ethereum مشهور شد. اما نسخههای جدیدتر آن پیچیدهتر هستند: بازدرآمدی میانتابعی، میانقراردادی و حتی Read-only Reentrancy که در آن داده خواندهشده برای پروتکلهای دیگر گمراهکننده میشود. منابع امنیتی Ethereum و ConsenSys بازدرآمدی را یکی از طبقات کلاسیک حمله در قراردادهای هوشمند میدانند.
نکته مهم این است که بازدرآمدی فقط «برداشت چندباره» نیست. در DeFi مدرن، یک مقدار اشتباه در لحظه نامناسب میتواند قیمت سهم استخر، نسبت وثیقه یا وضعیت وام را تغییر دهد.
۲. ضعف کنترل دسترسی
اگر تابعی که باید فقط توسط مالک، DAO یا نقش مشخص اجرا شود، به صورت عمومی قابل فراخوانی باشد، مهاجم نیازی به شکستن رمزنگاری ندارد. او فقط تابعی را اجرا میکند که نباید در اختیارش میبود.
این نوع ضعف میتواند به تغییر مالک، برداشت خزانه، توقف قرارداد، ارتقای مخرب یا تغییر آدرس اوراکل منجر شود. در گزارش OWASP Smart Contract Top 10 سال ۲۰۲۵، آسیبپذیریهای کنترل دسترسی بیشترین خسارت ثبتشده را در میان دستههای اصلی داشتهاند.
در اینجا تفاوت میان «کد باز» و «کد امن» مشخص میشود. متن قرارداد ممکن است روی Explorer قابل مشاهده باشد، اما اگر مدل دسترسی درست طراحی نشده باشد، شفافیت بهتنهایی امنیت ایجاد نمیکند.
۳. دستکاری اوراکل قیمت
قراردادهای DeFi برای تصمیمگیری به قیمت نیاز دارند: قیمت وثیقه، قیمت توکن، نرخ تبدیل، ارزش LP Token یا قیمت تسویه. اگر این قیمت از یک استخر کمعمق یا منبع کوتاهمدت گرفته شود، مهاجم میتواند قیمت را برای مدت کوتاهی تغییر دهد و قرارداد را فریب دهد.
دستکاری اوراکل معمولاً با سرمایه زیاد یا فلشلون ترکیب میشود. مهاجم ابتدا قیمت را در یک بازار کمعمق جابهجا میکند، سپس از پروتکل هدف وام میگیرد، وثیقه را بیشارزش نشان میدهد یا دارایی را زیرقیمت خریداری میکند.
راهنماهای امنیتی ConsenSys و پژوهشهای جدید DeFi، دستکاری اوراکل را یکی از ریسکهای مهم پروتکلهای مالی غیرمتمرکز میدانند، بهویژه زمانی که قرارداد به داده خارجی بدون محدودیت زمانی، میانگینگیری یا اعتبارسنجی چندمنبعی وابسته باشد.
۴. حمله فلشلون
فلشلون به خودی خود ابزار مخرب نیست. این قابلیت به کاربر اجازه میدهد مقدار بزرگی دارایی را بدون وثیقه، فقط در محدوده یک تراکنش قرض بگیرد و در همان تراکنش بازپرداخت کند. خطر زمانی ایجاد میشود که این سرمایه موقت برای بزرگنمایی یک ضعف طراحی استفاده شود.
در حمله فلشلون، مهاجم معمولاً چند عملیات را در یک تراکنش ترکیب میکند: گرفتن وام، تغییر قیمت، تعامل با پروتکل آسیبپذیر، برداشت سود و بازپرداخت وام. اگر در پایان تراکنش سود باقی بماند و همه شروط بلاکچین معتبر باشند، حمله موفق است.
بنابراین فلشلون علت اصلی نیست؛ تقویتکننده است. ضعف واقعی معمولاً در اوراکل، مدل قیمتگذاری، محاسبه وثیقه یا نبود محدودیت نقدینگی قرار دارد.
۵. خطای منطق اقتصادی
بسیاری از هکها به باگ فنی آشکار مربوط نیستند، بلکه از مدل اقتصادی اشتباه ناشی میشوند. برای مثال، اگر پاداشها بدون محدودیت صادر شوند، قیمت سهم استخر درست محاسبه نشود یا ترتیب واریز و برداشت قابل سوءاستفاده باشد، قرارداد از نظر کدنویسی اجرا میشود اما از نظر اقتصادی شکست میخورد.
این نوع خطا در پروتکلهایی دیده میشود که چند ماژول به هم وابسته دارند: استخر نقدینگی، توکن حاکمیتی، وثیقه، پاداش، رأیگیری و خزانه. هرچه طراحی اقتصادی پیچیدهتر باشد، احتمال وجود مسیرهای غیرمنتظره بیشتر میشود.
مهاجم در این حالت مثل یک کاربر عادی عمل میکند، اما رفتار او مرزی است: از همان قواعدی استفاده میکند که برای کاربران سالم طراحی شدهاند، فقط در ترکیبی که طراح پیشبینی نکرده است.
۶. خطاهای امضا و Wallet
در Web3، بسیاری از مجوزها با امضا انجام میشوند. اگر پیام امضا شده دامنه مشخص، زنجیره مشخص، زمان انقضا یا nonce معتبر نداشته باشد، ممکن است دوباره استفاده شود یا در محیط دیگری معتبر بماند.
این موضوع برای Wallets اهمیت زیادی دارد. کاربر ممکن است تصور کند فقط یک ورود ساده یا تأیید بیخطر انجام میدهد، اما در واقع مجوز انتقال توکن، تأیید نامحدود یا پیام قابل استفاده در قرارداد دیگری را امضا کند. این نقطه برای لینک داخلی «کیف پول دیجیتال چیست» بسیار مناسب است.
خطای امضا همیشه از قرارداد نمیآید؛ گاهی از رابط کاربری، پیام مبهم، استاندارد ناقص یا درک اشتباه کاربر ایجاد میشود. امنیت قرارداد هوشمند بدون امنیت کیف پول کامل نیست.
۷. باگهای ارتقاپذیری و Proxy
بسیاری از قراردادها برای رفع باگ یا افزودن قابلیت، از الگوی Proxy استفاده میکنند. در این مدل، آدرس کاربر ثابت میماند اما منطق اجرایی میتواند تغییر کند. اگر مالک ارتقا بهخوبی محافظت نشود یا تابع مقداردهی اولیه دوباره قابل اجرا باشد، مهاجم میتواند کنترل منطق آینده را به دست بگیرد.
باگهای Initialization یکی از نمونههای خطرناک این حوزه هستند. قراردادی که باید فقط یک بار مقداردهی شود، اگر بعداً دوباره مقداردهی شود، ممکن است مالک جدید، آدرس خزانه یا پارامترهای حیاتی آن تغییر کند.
ارتقاپذیری یک شمشیر دو لبه است: از یک سو امکان اصلاح آسیبپذیری را فراهم میکند؛ از سوی دیگر، یک نقطه کنترل قدرتمند ایجاد میکند که اگر آلوده شود، کل سیستم را تغییر میدهد.
سناریوی عملی: هک یک پروتکل وامدهی DeFi
فرض کنید یک پروتکل DeFi به کاربران اجازه میدهد توکن A را وثیقه بگذارند و در برابر آن استیبلکوین قرض بگیرند. قرارداد قیمت توکن A را از یک استخر معاملاتی کوچک میگیرد. این استخر نقدینگی کمی دارد، اما قرارداد آن را به عنوان منبع قیمت معتبر میشناسد.
مهاجم با یک فلشلون مقدار زیادی سرمایه میگیرد و قیمت توکن A را در همان استخر بهطور موقت بالا میبرد. قرارداد وامدهی این قیمت مصنوعی را میخواند و تصور میکند وثیقه مهاجم بسیار ارزشمند است. سپس مهاجم مقدار زیادی استیبلکوین قرض میگیرد.
در پایان تراکنش، مهاجم قیمت را به حالت نزدیک به قبل برمیگرداند، فلشلون را بازپرداخت میکند و بدهی بد در پروتکل باقی میماند. هیچ کلید خصوصی شکسته نشده، هیچ بلاکی دستکاری نشده و شبکه Blockchain طبق قواعد خود کار کرده است؛ خطا در طراحی اعتماد به اوراکل بوده است.
این سناریو نشان میدهد چرا امنیت قرارداد هوشمند فقط ممیزی کد نیست. باید مدل اقتصادی، عمق بازار، منبع داده، رفتار کاربران، ریسک نقدینگی و وابستگی به Exchanges یا DEXها نیز تحلیل شود.
کاربردهای واقعی این تحلیل در صنعت
DeFi
پروتکلهای وامدهی، صرافیهای غیرمتمرکز، مشتقات، استخرهای نقدینگی و Yield Farming بیشترین وابستگی را به قراردادهای هوشمند دارند. در این حوزه، هر خطای کوچک میتواند با نقدینگی بالا ترکیب شود و خسارت بزرگ بسازد.
NFT و بازیهای بلاکچینی
در NFTها، خطای Mint، امضا، لیستکردن، Royalty یا مجوز انتقال میتواند باعث فروش ناخواسته یا ضرب بیش از حد شود. در بازیها، اقتصاد درونبازی میتواند با توکنومیکس ضعیف یا قرارداد پاداش ناقص آسیب ببیند.
DAO و حاکمیت
در DAOها، حمله ممکن است از مسیر رأیگیری، Quorum، وامگیری توکن حاکمیتی یا اجرای پیشنهاد مخرب انجام شود. بنابراین امنیت حاکمیت به اندازه امنیت تابع برداشت مهم است.
Wallets و Account Abstraction
کیف پولهای هوشمند قابلیتهایی مانند بازیابی اجتماعی، امضای چندگانه و محدودیت هزینه دارند. اما همین قابلیتها اگر درست پیادهسازی نشوند، سطح حمله جدیدی ایجاد میکنند.
Bridges و انتقال بینزنجیرهای
پلها میان چند شبکه کار میکنند و به اعتبارسنجی پیام، امضا، اجماع یا نگهداری دارایی وابستهاند. به همین دلیل، حمله به پلها معمولاً ترکیبی از قرارداد هوشمند، زیرساخت و عملیات امنیتی است.
خطاهای رایج درباره هک قراردادهای هوشمند Smart contract hacking
تصور اول: اگر قرارداد روی بلاکچین است، پس امن است
Blockchain تغییرناپذیری و شفافیت میدهد، اما درستی منطق را تضمین نمیکند. اگر منطق اشتباه منتشر شود، همان اشتباه به شکل قابل اعتماد اجرا میشود.
تصور دوم: ممیزی امنیتی یعنی نبود باگ
Audit احتمال خطا را کاهش میدهد، اما تضمین مطلق نیست. بسیاری از حملات از ترکیب شرایط بازار، تعاملات خارجی و رفتارهای مرزی ایجاد میشوند؛ چیزهایی که همیشه در تستهای محدود دیده نمیشوند.
تصور سوم: کد بسته امنتر است
برخی تصور میکنند پنهانکردن کد، مهاجم را عقب میاندازد. اما در اکوسیستم قراردادهای هوشمند، بایتکد روی زنجیره قرار دارد و قابلیت تحلیل دارد. Chainalysis در ۲۰۲۶ به الگوی سوءاستفاده از قراردادهای تأییدنشده و بسته نیز اشاره کرده است؛ زیرا نبود شفافیت، بررسی عمومی و پژوهش امنیتی را دشوار میکند.
تصور چهارم: فقط توسعهدهنده مسئول امنیت است
امنیت قرارداد هوشمند یک مسئله چندلایه است. توسعهدهنده، طراح اقتصاد، تیم عملیات، مدیر کلیدها، ارائهدهنده اوراکل، رابط کاربری و حتی کاربر Wallet هم در سطح ریسک نقش دارند.
مقایسه با هک سیستمهای سنتی
در هک سنتی، مهاجم معمولاً به دنبال ورود غیرمجاز به سرور، سرقت رمز عبور، اجرای بدافزار یا دسترسی به پایگاه داده است. هدف، شکستن دیوارهای دفاعی سیستم است.
در هک قرارداد هوشمند، مهاجم اغلب نیازی به ورود مخفیانه ندارد. او تراکنشی عمومی ارسال میکند که از نظر شبکه معتبر است. تفاوت در این است که آن تراکنش از یک فرض اشتباه در کد یا طراحی اقتصادی استفاده میکند.
به همین دلیل، امنیت Web3 باید قبل از استقرار آغاز شود. در سیستم سنتی میتوان سرور را Patch کرد، دسترسی را بست یا پایگاه داده را برگرداند. اما در قراردادهای غیرقابلارتقا، اشتباه منتشرشده ممکن است دائمی باشد.
چگونه میتوان ریسک هک قرارداد هوشمند Smart contract hacking را کاهش داد؟
کاهش ریسک با یک ابزار حل نمیشود. ترکیبی از طراحی امن، تست، ممیزی، پایش و واکنش اضطراری لازم است.
در سطح کد، الگوهایی مانند Checks-Effects-Interactions، محدودکردن تماسهای خارجی، کنترل دسترسی دقیق، اعتبارسنجی ورودی، محافظ بازدرآمدی، محدودیت برداشت، استفاده از کتابخانههای استاندارد و تستهای Property-based اهمیت دارند.
در سطح اقتصادی، باید مدل قیمتگذاری، عمق نقدینگی، اوراکل چندمنبعی، TWAP، محدودیت اسلیپیج، سقف وام، پارامترهای وثیقه و سناریوهای بازار شدید بررسی شوند.
در سطح عملیات، مدیریت کلید، Multisig، Timelock، برنامه Bug Bounty، مانیتورینگ تراکنش، توقف اضطراری محدود و برنامه پاسخ به حادثه ضروری است. OpenZeppelin نیز در ۲۰۲۶ بر این نکته تأکید کرده که امنیت بلاکچین فقط آسیبپذیری قرارداد نیست و باید عملیات امنیتی، حاکمیت و زیرساخت را هم پوشش دهد.
آینده امنیت قراردادهای هوشمند در ۲۰۲۶ و بعد از آن
امنیت قراردادهای هوشمند به سمت ترکیب چند حوزه حرکت میکند: تحلیل ایستا، تست فازی، اثبات رسمی، مانیتورینگ زنده، شبیهسازی اقتصادی و امنیت عملیاتی. قراردادهای حساس مالی دیگر نمیتوانند فقط با یک Audit کوتاه وارد بازار شوند.
در ۲۰۲۶، رشد Account Abstraction، داراییهای توکنیزهشده، DeFi سازمانی و پلهای چندزنجیرهای سطح حمله را گستردهتر میکند. همزمان، ابزارهای دفاعی نیز پیشرفتهتر میشوند: شبیهسازی پیش از اجرا، محدودیتهای پویا، سیستمهای تشخیص رفتار غیرعادی و بررسی رسمی منطق قرارداد.
آینده این حوزه احتمالاً به سمت استانداردسازی بیشتر میرود. همانطور که Wikipedia دانش را ساختارمند کرد، CoinMarketCap داده بازار را قابل مقایسه کرد و Investopedia مفاهیم مالی را توضیح داد، دانشنامههای تخصصی Web3 باید امنیت قراردادهای هوشمند را با زبان دقیق، قابل فهم و قابل ارجاع توضیح دهند.
جمعبندی نهایی
قراردادهای هوشمند زمانی هک میشوند که منطق اجرایی آنها با واقعیت اقتصادی، امنیتی یا عملیاتی سازگار نباشد. مهاجم معمولاً شبکه Blockchain را نمیشکند؛ بلکه از خطاهای قرارداد، اوراکل، دسترسی، امضا، ارتقاپذیری یا تعاملات DeFi استفاده میکند.
مهمترین حملات شامل بازدرآمدی، ضعف کنترل دسترسی، دستکاری اوراکل، فلشلون، خطای منطق اقتصادی، باگهای امضا و نقص در سیستمهای ارتقاپذیر است. امنیت پایدار در این حوزه فقط با کدنویسی بهتر به دست نمیآید؛ بلکه به معماری درست، طراحی اقتصادی مقاوم، ممیزی مستقل، پایش زنده، مدیریت کلید و آموزش کاربران Wallet وابسته است.
در اکوسیستمهایی مانند Ethereum، که قرارداد هوشمند بخش اصلی نوآوری است، فهم روشهای هک فقط برای توسعهدهندگان نیست. سرمایهگذاران، کاربران DeFi، تیمهای صرافی، طراحان Wallets و پژوهشگران Blockchain هم باید بدانند که اعتماد در Web3 نه از شعار تمرکززدایی، بلکه از طراحی دقیق و آزمونپذیر به دست میآید.