احتيال الموافقات: كيف يستنزف توقيع واحد محفظتك

على سلاسل الكتل من نوع EVM، تعيش الرموز مثل USDC أو DAI داخل عقودها الذكية الخاصة، لا في محفظتك. محفظتك لا تحتفظ سوى بالمفاتيح التي تثبت أنك تتحكم في رصيد ما. ولذلك حين يحتاج تطبيق مثل منصة تبادل لامركزية (DEX) إلى تحريك رموزك نيابة عنك، لا يستطيع أن يمد يده ويأخذها هكذا. عليك أن تمنح الإذن أولاً.

يُسمى هذا الإذن موافقة. وأشيع صوره دالة approve في معيار ERC-20، حيث تخبر عقد الرمز بأن عنوان منفِق محدد يجوز له تحويل رموزك حتى مبلغ معين. وستصادف بضعة أنواع مختلفة:

• approve على رموز ERC-20، وهي تحدد سقف إنفاق لمنفِق واحد حتى عدد ثابت من الرموز.
• setApprovalForAll على عقود NFT من نوع ERC-721 وERC-1155. وهذه أوسع بكثير، إذ تتيح للمنفِق تحويل كل NFT تمتلكه في تلك المجموعة، بما فيها ما تشتريه لاحقاً.
• توقيعات Permit وPermit2، وهي نمط أحدث يتيح لك منح سقف إنفاق عبر توقيع رسالة خارج السلسلة بدلاً من إرسال معاملة على السلسلة، وعادة من دون أي تكلفة غاز عليك.

الموافقات شرعية، ولا مفر منها إن أردت أن تلمس معظم تطبيقات التمويل اللامركزي (DeFi). والمأزق أن الآلية نفسها التي تتيح لمنصة تبادل موثوقة أن تبادل رموزك تتيح كذلك لعقد خبيث أن يستنزفها.

كثير من التطبيقات تطلب موافقة غير محدودة افتراضياً، فتضبط سقف الإنفاق على أقصى قيمة ممكنة. تفعل ذلك كي لا تضطر إلى الموافقة مرة أخرى، وهو أمر مريح فعلاً. لكنه يعني كذلك أن عقد المنفِق يستطيع تحريك كل رمز من ذلك النوع في محفظتك، إلى الأبد، حتى تلغي الموافقة.

يعشق المهاجمون هذا. فموقع تصيّد متنكر في هيئة مطالبة بتوزيع مجاني (airdrop)، أو سكّ رمز، أو فرصة عائد، سيعرض عليك طلب موافقة يبدو روتينياً. ووافق عليه، فإذا عنوان المنفِق في تلك المعاملة عائد للمهاجم. وليس على الاستنزاف أن يقع فوراً. يستطيع المهاجم الانتظار حتى ينمو رصيدك، أو حتى يوافق كثير من الضحايا، ثم يكنس الجميع في دفعة واحدة.

وبما أن التحويل الخبيث مصرّح به تقنياً بموجب موافقة وقّعتها، فلا يرى عقد الرمز فيه شيئاً غير عادي. فمن منظور السلسلة، أنت من منح الإذن. وهذا ما يجعل احتيال الموافقات بالغ الفعالية: السرقة معاملة طبيعية تماماً وصحيحة.

وينطبق المنطق نفسه على setApprovalForAll في الـNFT. فموافقة واحدة متهورة على سوق مزيف قد تسلّم مجموعة كاملة، بما في ذلك قطع لم تشترِها بعد.

بُني معيارا Permit وPermit2 لتسهيل الأمر على المستخدمين. فبدلاً من دفع غاز لمعاملة موافقة منفصلة، توقّع رسالة خارج السلسلة تصرّح بسقف إنفاق. ثم يقدّم التطبيق المتلقي ذلك التوقيع على السلسلة لاحقاً، حين يحتاج فعلاً إلى الإنفاق.

هذا قوي ومريح، لكنه يقلب نموذج التهديد. فتوقيع Permit ليس أكثر من بيانات توقّعها بمفتاحك. وهو لا يظهر في مستكشف الكتل بوصفه موافقة معلّقة، ولا يكلّف عادة شيئاً، فيبدو بلا ضرر. ولا توجد معاملة على السلسلة تفحصها قبل أن يقع الضرر.

يستطيع المهاجم بناء طلب Permit يُسمّي عنوانه هو بوصفه المنفِق، ويضبط المبلغ على رصيدك الكامل، ويستخدم مهلة طويلة. وقّعه، فيصير بيده قسيمة صالحة لاستنزاف ذلك الرمز متى أراد. ولأن التوقيع جرى خارج السلسلة، فقد لا ترى أبداً تحذيراً بأن أموالك في خطر حتى تكون قد ذهبت بالفعل.

• معاملة الموافقة العادية مرئية على السلسلة، ويمكن أحياناً اكتشافها قبل التأكيد.
• توقيع Permit يبقى غير مرئي حتى يُستبدل، وقد يكون ذلك بعد وقت طويل.
• يستطيع Permit2 على وجه الخصوص تجميع الموافقات عبر رموز كثيرة، فقد يعرّض توقيع واحد أكثر من أصل للخطر.

الدرس هنا بسيط. طلب التوقيع ليس آمناً تلقائياً لمجرد أنه لا يطلب غازاً. فالتوقيعات خارج السلسلة قد تكون خطيرة تماماً كالمعاملات.

تعرض محفظتك نوعين مختلفين جذرياً من الطلبات، وتعلّم التمييز بينهما من أنفع المهارات التي يمكنك اكتسابها.

المعاملة (transaction) تغيّر الحالة على السلسلة وتكلّف غازاً. وستعرض محفظتك رسوم الشبكة، وعنوان العقد الذي تتعامل معه، وغالباً إجراءً مفكوك الترميز مثل Approve أو Transfer. ويمكنك عادة فحص المنفِق والمبلغ قبل أن تؤكد.

أما طلب التوقيع (signature) فيطلب منك توقيع بيانات بمفتاحك الخاص، وعادة من دون رسوم غاز. بعض التوقيعات بلا ضرر، مثل إثبات ملكية المحفظة لتسجيل الدخول إلى موقع. وأخرى، مثل Permit أو Permit2 أو أمر على سوق، تصرّح بتحريك قيمة. وتحاول المحافظ الحديثة فكّ ترميزها فتُظهر حقولاً مثل المنفِق والرمز والقيمة والمهلة.

وحين يظهر أي طلب، تمهّل وتحقق:

• هل هذه معاملة أم توقيع؟ وإن كانت توقيعاً، فما نوعه؟
• ما عنوان المنفِق؟ وهل تتعرّف عليه بوصفه التطبيق الذي قصدت استخدامه؟
• ما المبلغ أو سقف الإنفاق؟ هل هو رصيدك الكامل أم قيمة غير محدودة؟
• هل يطابق الإجراء ما نقرت عليه؟ تسجيل الدخول لا ينبغي أن يتطلب Permit.

إذا طلب فجأةً شيء بسيط مثل الاتصال أو المطالبة موافقةً على رمز أو توقيع Permit، فعامِل هذا التناقض على أنه إشارة تحذير.

لا يقتصر المهاجمون على دالة approve الأساسية. فمعيار ERC-20 يتضمن أيضاً increaseAllowance، التي ترفع سقف إنفاق قائماً بدلاً من استبداله. وتتكئ بعض مسارات التصيّد على هذه الدالة لرفع الأذونات في صمت، وبما أن اسم الدالة يبدو تقنياً وغير مؤذٍ، يوقّع عليها الضحايا دون أن يستوعبوا ما تمنحه.

يتزاوج احتيال الموافقات كذلك جيداً مع تسميم العناوين. في هجوم تسميم العناوين، يرسل لك المحتال تحويلاً ضئيلاً أو بقيمة صفرية من عنوان مبنيّ ليبدو شبه مطابق لعنوان تستخدمه كثيراً، بحيث يتطابق في أوّل حروفه وآخرها. ولاحقاً، حين تنسخ عنواناً من سجل معاملاتك، قد تلتقط العنوان المسمّم بالخطأ.

اجمع بين الاثنين يتضاعف الخطر. فالضحية الذي تدرّب بالفعل على الثقة بعنوان مألوف المظهر قد يوافق أو يرسل أموالاً إلى عقد لم يقصد التعامل معه قط. لذا تحقّق من العنوان الكامل في كل مرة، لا من أوّل الحروف وآخرها فحسب، ولا تنسخ أبداً وجهة من سجلّك دون فحصها حرفاً بحرف.

كل موافقة منحتها في أي وقت تظل قائمة حتى تلغيها أو تعيدها إلى الصفر. وبعد أشهر من استخدام تطبيقات مختلفة، يكون معظم المستخدمين النشطين قد كدّسوا عشرات الموافقات القائمة، كثير منها غير محدود، لعقود توقفوا عن استخدامها منذ زمن. وكل واحدة منها باب تُرك مفتوحاً.

تلغي موافقة بإرسال معاملة تعيد سقف إنفاق ذلك المنفِق إلى الصفر، أو باستخدام أداة موثوقة لإدارة الموافقات تعرض موافقاتك القائمة وتتيح لك مسحها. الإلغاء يكلّف غازاً، لكن ذلك أرخص بكثير من خسارة رصيدك.

اجعل الإلغاء عادة منتظمة، لا تنظيفاً لمرة واحدة. راجع موافقاتك بين الحين والآخر، خصوصاً بعد أن تكون قد لمست تطبيقات جديدة أو تجريبية، وامسح كل ما لا تحتاج إليه فعلياً. ومع Permit2 والأنظمة المشابهة، تحقّق من الموافقات المسجّلة هناك أيضاً، لأنها تعيش في عقد منفصل عن موافقات ERC-20 التقليدية.

وتقليص تعرّضك مسبقاً يساعد كذلك. فحين يتيح لك تطبيق الخيار، وافق فقط على المبلغ الذي تحتاج إليه للإجراء الذي أمامك بدلاً من سقف إنفاق غير محدود. ستوافق مرات أكثر، لكن كل موافقة لا تضع في خطر سوى مبلغ صغير ومحدد.