نشر القائمة السوداء: كيف يمكن لحالة إساءة استخدام مؤكدة أن تقضي على الشبكة بأكملها (AR)
حظر حساب واحد يزيل رأسًا واحدًا من الأفعى متعددة الرؤوس. تمنع القائمة السوداء المستندة إلى الجلسة إعادة استخدام كل معرّف تم لمسه - الوجه، الوثيقة، الهاتف، البريد الإلكتروني، IP، الجهاز - عبر 12 نوع إدخال، مما يضمن فشل أي حساب.

هناك لحظة محددة تتسرب فيها قيمة معظم برامج مكافحة إساءة الاستخدام: اللحظة التي تلي فوزك.
طبقة حركة المرور الخاصة بك تُشير إلى حساب ما. يقوم محلل بالتحقيق. الأدلة قوية، القضية مؤكدة، الحساب محظور. وبعد ساعات، يعود نفس المشغل بحسابات جديدة، لأن الشيء الوحيد الذي طاله تطبيقك كان صفًا في جدول المستخدمين.
وصفت Anthropic هذه الديناميكية بالضبط في تقريرها الصادر في فبراير 2026 حول حملات التقطير – وهي شبكة وكيلة "أدارت أكثر من 20,000 حساب احتيالي في نفس الوقت"، واستبدلتها بمجرد إزالتها. لم تكن الإزالة هي العقبة. كان التجديد أرخص من الإزالة.
الحل هو جعل عملية التنفيذ تعمل على المعرّفات بدلاً من الحسابات. تم بناء واجهة برمجة تطبيقات القوائم (Lists API) من Didit حول آلية واحدة تقوم بذلك في استدعاء واحد.
النقاط الرئيسية
- إضافة إلى القائمة السوداء باستخدام
reference_session_idتجعل Didit يستخرج القيمة الصحيحة تلقائيًا من الجلسة — الوجه، الوثيقة، الهاتف، البريد الإلكتروني، IP أو الجهاز — ويضع علامة على النموذج الأساسي بأنه في القائمة السوداء، ويربط الإدخال بالجلسة المصدر. - 12 نوع إدخال:
face،document،phone،email،ip_address،device_fingerprint،wallet_address،bank_account،user،business،country،key. - القوائم السوداء هي من إنشاء النظام، واحدة لكل نوع إدخال، وغير قابلة للتغيير. لا يمكنك إنشاؤها، وهذا ما يجعل عملية التنفيذ موحدة.
- تصبح الإدخالات سارية المفعول فورًا عند وقت التحقق. يؤدي حذف إدخال إلى إلغاء حظر المطابقة.
- يقبل
ip_addressنطاق CIDR، لذا يمكنك حظر البنية التحتية بدلاً من عنوان واحد. - القوائم البيضاء عبر نفس الأنواع الـ 12 تحافظ على المطورين الموثوق بهم بعيدًا عن كل مسار تصعيد.
أنواع القوائم الهامة
تحتوي واجهة برمجة التطبيقات على ثلاثة أنواع من القوائم، والتمييز بينها مقصود.
القوائم السوداء هي قوائم يتم إنشاؤها بواسطة النظام - واحدة لكل نوع إدخال - وهي غير قابلة للتغيير. لا يمكنك إنشاؤها أو إعادة تسميتها أو حذفها. يمكنك إضافة وإزالة الإدخالات. هذا القيد هو ميزة: فهو يعني أن "المدرجة في القائمة السوداء" لها معنى واحد بالضبط عبر مؤسستك، ولا توجد طريقة للوصول إلى أربع قوائم سوداء للوجوه متنافسة تتحقق منها الخدمات المختلفة بشكل غير متسق.
القوائم البيضاء هي لك لإنشائها. الأجهزة الجيدة المعروفة، ونطاقات العناوين، والكيانات التجارية، والمستخدمون يذهبون إلى هنا.
القوائم المخصصة هي لكل شيء آخر - تصنيفاتك الخاصة، ومجموعات المراقبة، ومجموعات المراجعة.
# العثور على القائمة السوداء للوجه
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
-H 'x-api-key: YOUR_API_KEY'
الآلية الهامة
هذه هي الطريقة العادية لإدراج شيء ما في القائمة السوداء، وهي الطريقة الخاطئة في كل موقف حقيقي تقريبًا:
curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{ "value": "203.0.113.44" }'
هذا يدرج عنوانًا واحدًا في القائمة السوداء. وفي الوقت نفسه، فإن الجلسة التي كنت تحقق فيها تحتوي أيضًا على وجه ورقم وثيقة وهاتف وبريد إلكتروني وبصمة جهاز - كل واحد منها هو معرّف يجب على المشغل استبداله قبل العودة.
الاستدعاء الأفضل:
curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{ "reference_session_id": "a7f3...c19" }'
عند تمرير reference_session_id، يقوم Didit بالاستخراج التلقائي للقيمة الصحيحة لنوع إدخال تلك القائمة من الجلسة، ويضع علامة على النموذج الأساسي بأنه في القائمة السوداء، ويربط الإدخال بالجلسة بحيث يمكن للوحة التحكم أن تُظهر لك مصدره.
ينتج عن ذلك ثلاثة أمور، وجميعها مهمة عمليًا:
لا يوجد استخراج يدوي. لا يقوم محللك بقراءة بصمة الجهاز من الشاشة وإعادة كتابتها. أخطاء النسخ في بيانات التنفيذ هي إخفاقات صامتة - لا يتم تفعيل الحظر ببساطة، ولا يكتشف أحد ذلك.
يتم الحفاظ على المصدر. يرتبط كل إدخال بالجلسة التي بررته. عندما يسأل أحدهم بعد أربعة أشهر لماذا تم حظر هذا الجهاز، فإن الإجابة هي نقرة واحدة، وليست مشروعًا أثريًا.
التنفيذ قابل للتكرار. يغطي الاستدعاء نفسه مقابل كل قائمة سوداء لنوع الإدخال سطح تعريف الجلسة بالكامل.
إذا كانت الجلسة تحتوي على عدة أمثلة من نفس النوع، قم بتمرير value بجانب reference_session_id لإزالة الغموض.
يمكنك أيضًا فرض ذلك من خارج جلسة التحقق. reference_object_uuid جنبًا إلى جنب مع metadata.reference_type - transaction أو vendor_user أو vendor_business - يقوم بحظر من معاملة أو من مستخدم أو عمل بائع، ويحافظ على نفس الارتباط بالمصدر.
أنواع الإدخالات الـ 12
| نوع الإدخال | يحظر | ملاحظات |
|---|---|---|
face | الشخص | يمكن تحميله مباشرةً عبر تحميل الوجه |
document | بيانات الاعتماد | |
phone | الرقم | يتم تطبيعه تلقائيًا إلى E.164 |
email | العنوان | |
ip_address | العنوان أو النطاق | يقبل CIDR، مثل 10.0.0.0/8 |
device_fingerprint | الجهاز | 8 أحرف أبجدية رقمية كحد أدنى |
wallet_address | عنوان المحفظة على السلسلة | |
bank_account | الحساب | |
user | سجل المستخدم | |
business | الكيان | |
country | الاختصاص القضائي | |
key | مفتاح مخصص |
اثنان منهم يستحقان الذكر لهذه المشكلة.
يقبل ip_address نطاق CIDR. حظر 203.0.113.0/24 يحظر البنية التحتية، وليس عنوانًا واحدًا. عندما تعمل عملية زراعة على شبكة فرعية مستأجرة، هذا هو الفرق بين التنفيذ الذي يتوسع والتنفيذ الذي يلعب لعبة "اضرب الخلد". استخدمه بحذر - يغطي النطاق المستخدمين الحقيقيين أيضًا، والنطاقات الواسعة جدًا هي كيف تحظر بهدوء مشغل شبكة جوال في بلد ما.
يدعم face التحميل المباشر. عندما يكون لديك صورة ولكن لا توجد جلسة، قم بتحميلها مباشرة:
curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{ "image": "<base64-encoded image>" }'
يستخرج Didit البيانات البيومترية. ومنذ ذلك الحين، يتم فحص هذا الوجه عند كل عملية تحقق.
ماذا يحدث بعد إدراج إدخال
تؤدي الإضافة إلى قائمة سوداء للنظام إلى حظر المطابقات المستقبلية فورًا وقت التحقق. لا يوجد تأخير في الانتشار ولا توجد مهمة دفعية.
عند التحقق التالي، تظهر عملية التنفيذ كتحذيرات:
FACE_IN_BLOCKLIST— مطابقة حاسمة، تم رفض التحقق.POSSIBLE_FACE_IN_BLOCKLISTهي مطابقة على وشك الحظر أقل من العتبة القصوى ويجب توجيهها للمراجعة، وليس الرفض.IP_ADDRESS_IN_BLOCKLIST/DEVICE_FINGERPRINT_IN_BLOCKLIST— إصابات الشبكة والجهاز.
في بحث الوجه، تكون المطابقة في القائمة السوداء هي الشيء الوحيد الذي يضبط status على "Declined". تحمل كل مطابقة في الاستجابة أيضًا is_blocklisted، لذا يُظهر لك التحقيق على الفور أي أجزاء من المجموعة تخضع بالفعل للتنفيذ وأيها لا تزال نشطة.
الإزالة متماثلة: يؤدي حذف إدخال إلى إلغاء حظر الكيان المطابق. التنفيذ قابل للعكس بطبيعته، وهذا مهم لأن التنفيذ المفرط الاتساع يمثل خطرًا حقيقيًا وتحتاج إلى مسار واضح للعودة.
curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
-H 'x-api-key: YOUR_API_KEY'
القوائم البيضاء: حماية المطورين الذين تريدهم
التنفيذ الذي يتصاعد فقط يخنق المنتج في النهاية. تدعم نفس أنواع الإدخالات الـ 12 القوائم البيضاء، وهي صمام الأمان.
أضف نطاقات IP للمكتب الشريك التصميمي إلى القائمة البيضاء. أضف أجهزة فريق الهندسة لعميل المؤسسة إلى القائمة البيضاء. أضف كيانًا تجاريًا موثوقًا به إلى القائمة البيضاء بحيث لا يواجه مستخدموه أبدًا مسار تصعيد. يتم تفعيل IP_ADDRESS_IN_ALLOWLIST و DEVICE_FINGERPRINT_IN_ALLOWLIST عند حدوث تطابق، بحيث يمكنك تأكيد تطبيق الإعفاء بدلاً من افتراض حدوثه.
هذه هي الآلية التي تجعل التنفيذ العدواني قابلاً للنجاة. يمكنك تحمل سياسة صارمة على البنية التحتية غير المعروفة تحديدًا لأن سكانك المعروفين جيدًا قد تم استثناؤهم بشكل صريح.
الأخطاء التي تستحق المعالجة
- 400 — فشلت القيمة في مدقق نوع الإدخال، أو كان
list_typeخاطئًا للعملية (على سبيل المثال، تحميل وجه مقابل قائمة غير قائمة وجوه)، أو لا يحتويreference_session_idعلى بيانات من النوع المطلوب. هذه الحالة الأخيرة شائعة وغير ضارة: ليست كل جلسة تلتقط كل معرف. - 403 —
{"detail": "ليس لديك إذن لتنفيذ هذا الإجراء."}
لاحظ أن الخطأ 400 من "الجلسة لا تحتوي على بيانات من هذا النوع" متوقع عندما تقوم بتدوير جلسة عبر جميع القوائم السوداء لأنواع الإدخال. تعامل معه كتخطي، وليس كفشل.
تدفق تنفيذ مُجرب
لقد أكد محلل وجود إساءة استخدام في الحساب acct_8842.
- حل الكتلة أولاً. بحث الوجه على وجه الجلسة يعيد اثني عشر حسابًا؛ ارتباط الجهاز وIP يجلب دزينة أخرى. التنفيذ قبل الحل يحظر حسابًا واحدًا ويحذر المشغل.
- أضف إلى القائمة السوداء من الجلسة المؤكدة —
reference_session_idمقابل القوائم السوداء للوجه والجهاز وIP والبريد الإلكتروني والهاتف والوثيقة. ستة استدعاءات، لا يوجد استخراج يدوي، مصدر كامل. - النظر في النطاق. إذا كانت أدلة الشبكة تشير إلى بنية تحتية مستأجرة، فإن إدخال CIDR يغطي الشبكة الفرعية. تحقق مما هو موجود هناك أولاً.
- تصرف بناءً على الكتلة وفقًا لسياستك الخاصة — الحسابات التي حددتها بالفعل لا تلغي حظر نفسها.
- تحقق من التنفيذ. أعد تشغيل بحث الوجه. يجب أن تحمل المطابقات الآن
is_blocklisted: true. - انتظر محاولة التجديد. الحساب التالي الذي تم إنشاؤه على هذا الوجه أو الجهاز أو الشبكة الفرعية يتم رفضه عند التحقق بدلاً من الظهور في حركة المرور الخاصة بك بعد ثلاثة أسابيع.
الخطوة 6 هي الهدف بأكمله. لم تعد تكلفة عودة المشغل هي "إنشاء عنوان بريد إلكتروني جديد". بل هي "الحصول على أجهزة جديدة وشبكة جديدة وشخص جديد".
حالات الاستخدام
منصات واجهة برمجة تطبيقات الذكاء الاصطناعي تحول حالة تقطير أو إساءة استخدام مؤكدة إلى تطبيق عبر كل معرف لمسه المشغل.
إساءة استخدام التجربة والائتمان حيث يعود نفس الجهاز والوجه باستمرار للحصول على تخصيص مجاني جديد.
الأسواق التي تحظر البائعين الذين تم إزالتهم من إعادة التسجيل تحت اسم عمل جديد.
الألعاب التفاعلية التي تفرض الاستبعاد الذاتي، حيث يعتبر اللاعب المستبعد العائد فشلًا تنظيميًا، والتنفيذ على مستوى الوجه هو التحكم الموثوق الوحيد.
الأسئلة الشائعة
هل يمكنني إنشاء قائمة سوداء خاصة بي؟
لا. القوائم السوداء يتم إنشاؤها بواسطة النظام، واحدة لكل نوع إدخال، وهي غير قابلة للتغيير — يمكنك إضافة وإزالة الإدخالات. يمكنك إنشاء قوائم بيضاء وقوائم مخصصة بحرية. هذا القيد يحافظ على معنى "في القائمة السوداء" واحدًا في كل مكان.
ما مدى سرعة سريان الإدخال؟
فورًا، عند التحقق التالي.
ماذا لو أضفت شيئًا إلى القائمة السوداء عن طريق الخطأ؟
احذف الإدخال وسيتم إلغاء حظر الكيان. لهذا السبب يهم المصدر — كل إدخال تم إنشاؤه من جلسة يرتبط بها، حتى تتمكن من مراجعة الغرض من الإدخال قبل إزالته.
هل يؤثر إدراج نطاق IP في القائمة السوداء على المستخدمين الشرعيين ضمن هذا النطاق؟
نعم، وهذا هو الخطر. إدخال CIDR يحظر كل شيء بداخله. استخدم النطاقات عندما تشير الأدلة إلى بنية تحتية مخصصة، واستخدم العناوين الفردية بخلاف ذلك، وأضف النطاقات الجيدة المعروفة إلى القائمة البيضاء أولاً.
هل يمكنني الإدراج في القائمة السوداء من شيء ليس جلسة تحقق؟
نعم. reference_object_uuid بالإضافة إلى metadata.reference_type (transaction، vendor_user أو vendor_business) يغطي المعاملات ومستخدمي أو أعمال البائعين.
هل هذا يوقف استخراج النموذج؟
لا. إنه يمنع جهة فاعلة معروفة محددة من إعادة الدخول من خلال المعرفات التي قمت بتطبيقها، ويزيد من تكلفة التجديد. الكشف عن الاستخراج في المقام الأول هو وظيفة طبقة حركة المرور الخاصة بك، وتحديد ما ينتجه الاستخراج هو وظيفة طبقة النموذج الخاصة بك. هذا هو ذراع التنفيذ لدفاع ثلاثي الطبقات، وليس بديلاً للطبقتين الأخريين.
هل أنت مستعد للبدء؟
واجهة برمجة تطبيقات القوائم متاحة في كل حساب Didit.
- اقرأ الوثائق — نظرة عامة على واجهة برمجة تطبيقات القوائم و كتالوج تحذيرات IP والجهاز.
- شاهد المنتج — التحقق من المستخدم.
- تحقق من الأسعار — مدرجة علنًا، الدفع حسب النجاح، بدون حدود دنيا.
- ابدأ مجانًا — business.didit.me، 500 عملية تحقق KYC شهريًا بدون تكلفة.
مقالات ذات صلة
- مشكلة حسابات هيدرا: لماذا يبدأ الدفاع عن التقطير بتحديد الهوية (AR)
- التحقق من الشركات للوصول إلى واجهة برمجة تطبيقات الذكاء الاصطناعي: من يتحكم في هذا الحساب حقًا؟ (AR)
- التحقق من الوصول إلى واجهة برمجة التطبيقات لمقدمي نماذج الذكاء الاصطناعي: بنية متعددة المستويات حسب المخاطر (AR)
- البحث بالوجه 1:N: الكشف عن جميع الحسابات التي يتحكم بها شخص واحد (AR)
- التحقق البيومتري متعدد المستويات لوصول واجهة برمجة تطبيقات الذكاء الاصطناعي: ربط الامتياز بالشخص (AR)
- شبكات حسابات الهيدرا: كيف تتحول 20 ألف حساب إلى فاعل واحد (AR)