يتطلب كل تفاعل تقريباً مع تطبيق لامركزي، من التداول على منصة تبادل لامركزية إلى تكديس رمز ما، منح ذلك التطبيق إذناً بتحريك رمز معيّن نيابة عن صاحب المحفظة. يُسمى هذا الإذن تصريح الرمز (token approval)، وهو جزء مشروع وضروري من طريقة عمل معظم تطبيقات البلوكتشين. المشكلة ليست في وجود التصاريح. المشكلة أن معظم واجهات المحافظ تعرضها بإيجاز وبصيغة تقنية، وأن معظم المستخدمين يؤكدونها بسرعة دون فهم ما يوافقون عليه فعلياً.
وفقاً لتقرير Chainalysis لجرائم العملات المشفرة لعام 2026، جنت عمليات الاحتيال على السلسلة ما لا يقل عن أربعة عشر مليار دولار في عام 2025، ارتفاعاً من اثني عشر مليار دولار في العام السابق، وقد ظل التصيد الاحتيالي القائم على التصاريح مساهماً ثابتاً في هذا الرقم، إذ تُعزى إليه أكثر من مليار دولار من الخسائر المُبلَّغ عنها تراكمياً منذ عام 2021 تحديداً.
ما الذي يمنحه تصريح الرمز فعلياً
عندما يطلب تطبيق ما تصريحاً، فهو يطلب من المحفظة تفويض عقد ذكي بنقل مبلغ يصل إلى حد معيّن من رمز ما، نيابة عن المالك، في الوقت الذي يختاره ذلك العقد. تطلب العديد من التطبيقات تصريحاً غير محدود بشكل افتراضي، لأن ذلك أكثر ملاءمة للتطبيق ويجنّب مطالبة المستخدم بإعادة الموافقة على كل معاملة مستقبلية. وهذه الملاءمة نفسها هي ما يجعل الإذن خطيراً إذا كان العقد المستلم خبيثاً أو تعرَّض لاحقاً للاختراق، لأن التصريح نفسه لا تنتهي صلاحيته ولا يتطلب أي تأكيد إضافي لممارسته.
التصريح ليس معاملة لمرة واحدة. إنه تفويض قائم يظل نشطاً إلى أجل غير مسمى على البلوكتشين حتى يُلغى يدوياً، بغض النظر عما إذا كان الموقع الذي طلبه سيُزار مرة أخرى أم لا.
شرح تصاريح ERC-20 وPermit وPermit2
دالة approve القياسية
يتضمن معيار الرمز ERC-20 الأصلي دالة تُسمى approve، يستدعيها مالك المحفظة لتفويض عنوان عقد معيّن بإنفاق مبلغ يصل إلى حد محدد من ذلك الرمز. يتطلب هذا معاملة على البلوكتشين، أي أنه يكلّف رسم شبكة ويُسجَّل بشكل دائم على البلوكتشين لحظة تأكيده. وبما أنها معاملة منفصلة ومرئية، تعرض معظم واجهات المحافظ على الأقل تحذيراً عاماً بأن ما يُطلب هو تفاعل مع عقد لا مجرد تحويل بسيط.
Permit والتوقيعات خارج السلسلة
يسمح معيار أحدث، يُشار إليه عادة باسم Permit، بمنح النوع نفسه من التصريح عبر رسالة موقَّعة بدلاً من معاملة على البلوكتشين. لا يكلّف التوقيع نفسه أي رسم شبكة، ولا يحتاج إلى أن يُبَث فوراً، إذ يمكن للعقد المستلم تقديمه إلى البلوكتشين في أي وقت لاحق لتفعيل التصريح. هذا مريح للتطبيقات المشروعة، لأنه يتيح للمستخدم الموافقة على إجراء وإتمامه، كمبادلة رمز، في تفاعل واحد بدلاً من معاملتين منفصلتين. وهو أيضاً بالضبط ما يجعل التصيد الاحتيالي القائم على Permit أصعب ملاحظة، إذ غالباً ما يبدو طلب التوقيع مشابهاً بصرياً لتوقيع رسالة غير ضارة، وقد عرضت العديد من واجهات المحافظ تاريخياً تفاصيل أقل لطلب توقيع مقارنة بمعاملة كاملة.
Permit2 والتصاريح الشاملة
يسمح Permit2، وهو امتداد إضافي تبنّته منصات التبادل اللامركزي على نطاق واسع، بإعادة استخدام تصريح واحد مُمنح لعقد Permit2 مركزي عبر تطبيقات مختلفة عديدة دون الحاجة إلى تصريح منفصل لكل تطبيق. يقلل هذا الاحتكاك والرسوم بالنسبة للمستخدمين الشرعيين، لكنه يعني أيضاً أن توقيع Permit2 واحد يتعرض للتصيد يمكن أن يُعرِّض رمزاً ما لأي تطبيق مبني للتفاعل مع نظام Permit2، مما يوسّع نطاق الأثر الفعلي لمحاولة تصيد ناجحة واحدة مقارنة بتصريح عقد واحد من الطراز القديم.
سيناريو واقعي: مطالبة توزيع مجاني مزيفة تمنح تصريحاً غير محدود
- تنتشر رسالة في مجتمع عملات مشفرة تدّعي أن مشروع رمز معروف يوزّع توزيعاً مجانياً مفاجئاً على حاملي أصل ذي صلة، مع رابط لصفحة مطالبة.
- تطلب صفحة المطالبة من الزائر توصيل محفظته والنقر على زر بعنوان «طالِب الآن»، مما يُطلق نافذة منبثقة من المحفظة تطلب تصريحاً لرمز المشروع، موصوفاً فقط بأنه تفاعل مع عقد.
- يُضبط مبلغ التصريح المطلوب على أقصى قيمة ممكنة يسمح بها معيار الرمز، بدلاً من مبلغ مطالبة محدد، مع أن هذا التفصيل لا يظهر بشكل بارز في شاشة التأكيد الافتراضية للمحفظة.
- تؤكد الضحية الطلب، ولا تتلقى أي رموز لأنه لم يكن هناك توزيع مجاني حقيقي أصلاً، وتغلق علامة التبويب معتقدة أن المطالبة فشلت ببساطة أو أنها استُنفدت بالفعل.
- بعد أسابيع، وبمجرد ارتفاع سعر الرمز أو تراكم رصيد أكبر لدى الضحية، يمارس المهاجم التصريح القائم وينقل الرصيد بالكامل في معاملة واحدة لم توافق عليها الضحية مباشرة قط.
التأخير بين تفاعل التصيد الأصلي والخسارة النهائية متعمَّد. فهو يفصل السرقة عن سببها في ذاكرة الضحية، ويجعل من غير المرجح إلى حد بعيد الإبلاغ عن صفحة التصيد المحددة أو ربطها بالخسارة عندما تقع في نهاية المطاف.
لماذا يصعب ملاحظة التصيد القائم على التصاريح أكثر من تحويل مُفرِّغ مباشر
يُفرِّغ مُفرِّغ المحفظة المباشر، الذي تناولناه في دليلنا المرافق، محفظة عادة خلال ثوانٍ من تأكيد توقيع، مما يجعل على الأقل العلاقة بين السبب والنتيجة واضحة للضحية فور وقوعها. أما التصيد القائم على التصاريح فيُبنى بشكل مختلف. فمعاملة التصريح نفسها لا تنقل شيئاً، لذا فإن الضحية التي تتحقق من رصيدها فور التأكيد لا ترى أي تغيير وتستنتج بشكل معقول أن شيئاً لم يحدث. يمكن أن تقع الخسارة الفعلية بعد أيام أو أسابيع أو أشهر، ينفذها المهاجم في الوقت الذي يختاره، مما يعني أن الرابط بين صفحة التصيد الأصلية والسرقة النهائية غالباً ما لا تدركه الضحية على الإطلاق. وهذا أيضاً سبب أهمية مراجعة التصاريح بشكل روتيني بالنسبة لهذا التهديد تحديداً أكثر من أهميتها بالنسبة لهجمات التفريغ المباشرة، إذ توجد نافذة حقيقية، مهما كانت غير مؤكدة المدة، يمنع إلغاء التصريح خلالها وقوع أي خسارة على الإطلاق.
كيف يُنفَّذ الهجوم عادة
صفحات المطالبة والتحقق المزيفة
الإعداد الأكثر شيوعاً هو صفحة تحاكي مطالبة توزيع مجاني، أو خطوة تحقق من المحفظة، أو تفاعلاً روتينياً مع بروتوكول. توصّل الضحية محفظتها متوقعة تأكيداً بسيطاً، فيطلب الموقع بدلاً من ذلك تصريحاً يغطي رمزاً ذا قيمة، مؤطَّراً في النافذة المنبثقة للمحفظة كتفاعل عام مع عقد بدلاً من أي شيء مثير للقلق.
التصيد عبر توقيعات Permit وPermit2
هناك نسخة أحدث وأصعب اكتشافاً تستغل معيار توقيع، يُشار إليه غالباً باسم Permit أو Permit2، يسمح بمنح تصريح عبر رسالة موقَّعة خارج السلسلة بدلاً من معاملة على البلوكتشين. وبما أن توقيع رسالة لا يُطلق دائماً التحذيرات البصرية نفسها التي تُطلقها معاملة، ولا يكلّف رسم شبكة، فإن الضحايا أكثر عرضة لتوقيعها دون تدقيق دقيق. تضمنت إحدى الحالات الموثَّقة على نطاق واسع خسارة متداول نحو مليون دولار في توقيع Permit2 واحد بعد أن ظنه تأكيداً روتينياً على واجهة منصة تبادل لامركزية.
الاستغلال المتأخر
بما أن التصريح لا يحتاج إلى استخدام فوري، غالباً ما يجمع المهاجمون أعداداً كبيرة من التصاريح عبر محافظ عديدة ويمارسونها لاحقاً، على دفعات، وغالباً في توقيت يتزامن مع فترات ارتفاع سعر رمز ما أو عندما يكون من غير المرجح أن تراقب الضحية تلك المحفظة بنشاط. هذا التأخير جزء من سبب عجز الضحايا أحياناً عن ربط الخسارة بتفاعل التصيد الأصلي، إذ قد تفصل أسابيع أو أشهر بين الحدثين.
كيفية التحقق من التصاريح القائمة وإلغائها
- استخدم أداة موثوقة لفحص التصاريح تقرأ سجل تصاريح محفظتك على البلوكتشين وتسرد كل إذن نشط، إلى جانب العقد الذي يحمله والمبلغ الذي يغطيه.
- ألغِ أي تصريح لا تتعرف عليه أو لم تعد بحاجة إليه، خصوصاً التصاريح غير المحدودة المرتبطة بعقود غير مألوفة أو نادرة الاستخدام.
- أولِ اهتماماً خاصاً لتصاريح من طراز Permit2، إذ إنها أقل وضوحاً بصرياً في معظم واجهات المحافظ من معاملة تصريح عادية على البلوكتشين.
- اجعل الإلغاء ممارسة روتينية بعد التفاعل مع أي تطبيق لامركزي جديد أو غير مألوف، لا مجرد إجراء يُتخذ رد فعل بعد اكتشاف خسارة.
إلى جانب التحقق من التصاريح القائمة، تستحق بضع علامات محددة عند طلب تصريح جديد أن تُعامَل كإشارة توقف فورية بدلاً من شيء يُراجَع لاحقاً.
- المبلغ المعروض للتصريح المطلوب هو أقصى قيمة يسمح بها معيار الرمز، بدلاً من رقم محدد مرتبط بالإجراء المُدَّعى.
- تطلب الصفحة تصريحاً قبل عرض أي فائدة أو مكافأة أو خدمة ملموسة، بدلاً من أن يكون ذلك خطوة ثانية طبيعية لتفاعل بدأته أنت.
- تصف النافذة المنبثقة للمحفظة الطلب فقط بأنه توقيع أو تفاعل عام مع عقد، دون ملخص مفهوم لما يجري تفويضه.
- يجمع الموقع بين الاستعجال، كعداد تنازلي أو نافذة مطالبة محدودة، وطلب تصريح للمحفظة بدلاً من معاملة مباشرة.
شرح كامل لعملية الإلغاء نفسها، بما في ذلك الأدوات الشائع استخدامها وكيفية تفسير ما يفوّضه كل تصريح فعلياً، متاح في دليلنا المخصص حول إلغاء تصاريح الرموز. تُعد تلك العملية واحدة من الخطوات الدفاعية القليلة الفعّالة حقاً المتاحة لصاحب المحفظة، إذ تغلق الوصول القائم مباشرة بدلاً من الاعتماد فقط على تجنب محاولات التصيد المستقبلية.
عندما يكون التصريح قد استُغل بالفعل
إذا كانت الأموال قد تحرّكت بالفعل عبر تصريح مستغَل، ينبغي إلغاء التصريح نفسه فوراً لمنع استخدام أي مخصص متبقٍ مرة أخرى، حتى بعد سرقة أولية. ينبغي توثيق المعاملة التي نفَّذت السرقة، إلى جانب معاملة التصريح الأصلية، بطوابع زمنية ومعرّفات، إذ غالباً ما يكون هذا التسلسل ما يتيح لمحقق تحديد كيفية وقوع الاختراق وما إذا كان مرتبطاً بنمط أوسع من نشاط تفريغ المحافظ، وهو ما نتناوله بمزيد من التفصيل في دليلنا حول هجمات تفريغ المحافظ.
الأسئلة الشائعة
تدعم معظم أدوات فحص التصاريح الموثوقة الآن عرض وإلغاء التصاريح القائمة على Permit2 إلى جانب التصاريح القياسية، مع أن الواجهة قد تفصلها في قسم مستقل. يستحق الأمر التحقق من الفئتين تحديداً، إذ إن تصاريح Permit2 أقل وضوحاً بصرياً في العديد من واجهات المحافظ.
لا. الإلغاء يمنع فقط استخدام تصريح قائم مرة أخرى في المستقبل. وليس له أي أثر على الأموال المنقولة بالفعل، إذ لا يمكن عكس معاملات البلوكتشين بمجرد تأكيدها.
معظم واجهات المحافظ مصمَّمة للاستخدام العام وتعرض التصاريح كتفاعل عادي مع عقد بدلاً من الإشارة إلى المبلغ أو المدة تحديداً. توفر أدوات فحص التصاريح المتخصصة عموماً تفاصيل أوضح من شاشة التأكيد الافتراضية للمحفظة.
يمكن أن يكون كذلك. يمكن للتصاريح القائمة على التوقيع، خصوصاً طلبات من طراز Permit2، أن تمنح صلاحية الإنفاق نفسها التي تمنحها معاملة تصريح على البلوكتشين، لكنها غالباً ما تُعرض بتحذير أقل وضوحاً ودون رسم شبكة، مما يجعل تجاهلها أسهل.
من الممارسات المعقولة مراجعة التصاريح النشطة كل بضعة أسابيع بالنسبة لمحفظة مستخدمة بنشاط، وفوراً بعد التفاعل مع أي تطبيق لامركزي جديد أو غير مألوف، أو مطالبة توزيع مجاني، أو صفحة سك.
المصادر وقراءات إضافية
- What are token approvals · MetaMask
- 2026 Crypto Crime Report: Scams · Chainalysis
- Uniswap Permit2 Phishing: $1 Million Loss Highlights Risk · Cryptonomist