إخفاء عبر API (موقعين)
إخفاء API هو تطور لنموذج الموقعين. بدلاً من إعادة توجيه بسيطة، يتواصل الموقع أ عالي المخاطر مع الموقع ب منخفض المخاطر عبر واجهة برمجة تطبيقات (API) خلفية لإنشاء جلسات دفع فريدة ومملوءة مسبقاً.
📝 ملخص
- التقنية: إنشاء الدفع من خادم إلى خادم (S2S).
- الهدف: القضاء على تسريبات المحيل في الواجهة الأمامية وخلق تجربة دفع "ملصق أبيض" سلسة.
- درجة الخطر: شديد.
🏗 الهندسة التقنية
mermaid
sequenceDiagram
participant User as متصفح المستخدم
participant ServerA as خادم أ عالي المخاطر
participant ServerB as خادم ب منخفض المخاطر
participant PSP as PSP API
User->>ServerA: ينقر "شراء"
ServerA->>ServerB: POST /api/create-order
Note right of ServerA: { amount: 100, item: "X" }
ServerB->>PSP: إنشاء جلسة
PSP-->>ServerB: تم إنشاء الجلسة
ServerB-->>ServerA: إرجاع checkout_url
ServerA->>User: إعادة توجيه إلى PSP
User->>PSP: إكمال الدفعمنطق الواجهة الخلفية (Pseudocode)
python
# Site A (High Risk)
def process_payment():
response = requests.post("https://site-b.com/api/generate-link", json={
"price": 100.00,
"product_name": "Consulting Hours" # Obfuscated
})
return redirect(response.url)🕵️♂️ الكشف وإشارات المخاطر
1. عدم تطابق IP
- الإشارة: طلب API لإنشاء الجلسة يأتي من IP الخادم أ، لكن المستخدم ينفذ الدفع من IP سكني.
- الكشف: يقارن PSPs بين
Client-IP(المستخدم) مقابلInitiator-IP(الخادم). إذا كان IP البادئ مزود استضافة معروف (مثل DigitalOcean) يختلف عن خادم الموقع ب، فهذا مريب.
2. بنود عامة
- الإشارة: يتم تعيين جميع المنتجات إلى أوصاف عامة مثل "رسوم خدمة" لتتناسب مع نموذج عمل الموقع ب.
3. شذوذ التوقيت
- الإشارة: يتطابق طابع "إنشاء الجلسة" الزمني تماماً مع ارتفاعات حركة المرور على شبكات تابعة عالية المخاطر معروفة.
🏦 احتمالية كشف PSP (مقدمي خدمات الدفع)
| المزود | الاحتمالية | تحليل الكشف |
|---|---|---|
| Stripe | 85% | قوية. يطابق client_ip (المتصفح) مقابل created_ip (API). يضع علامة على الحسابات التي يتم فيها إنشاء جلسات الدفع بواسطة خوادم خارجية. |
| Adyen | 88% | قوية. تبصم خادم "البادئ". إذا أنشأت عناوين IP لاستضافة محددة جلسات عبر تجار متعددين، يتم وضع علامة عليها. |
| PayPal/Braintree | 75% | متوسطة/قوية. يكتشف عدم تطابق السرعة. الموقع ب لديه حركة مرور ويب منخفضة ولكن حجم إنشاء دفع API مرتفع. |
| Checkout.com | 82% | قوية. يحلل "وقت الدفع". غالباً ما يكون للروابط التي تم إنشاؤها بواسطة API أنماط زمن انتقال مختلفة عن عمليات الدفع للمستخدم الأصلي. |
| Shopify Payments | 60% | متوسطة. إذا تم استخدامه بدون رأس (Headless)، يكون الكشف أصعب. يعتمد على إشارات الاحتيال (عدم تطابق CVV) بدلاً من الطبولوجيا. |
| Authorize.net | 30% | ضعيفة. غالباً ما لا تتطلب عمليات تكامل API القديمة مطابقة IP صارمة بين المنشئ والدافع. |
| Nuvei | 70% | متوسطة. جيد في اكتشاف القطاعات عالية المخاطر (العملات المشفرة/الألعاب) ولكن من الصعب اكتشاف إخفاء API العام دون مراجعة يدوية. |
| Revolut Business | 80% | قوية. تراقب الأموال "العابرة". إذا قام الموقع ب بتحويل الأموال فوراً إلى كيان آخر، فإن ذلك يؤدي إلى تشغيل تنبيهات غسيل الأموال. |
| Payoneer Checkout | 75% | متوسطة. يركز على التدفقات عبر الحدود. قد يضع علامة إذا كانت حركة المرور في الموقع أ من منطقة خاضعة للعقوبات مقنعة بواسطة الموقع ب. |
⚠️ ملاحظات المحلل
هذا هو المعيار الصناعي للإخفاء الاحترافي. يتطلب تطوراً تقنياً. يجب على المحللين البحث عن الموقع ب الذي يحتوي على نقطة نهاية API مكشوفة (مثل /api/v1/checkout) تتلقى حجم حركة مرور مرتفع مقارنة بزيارات واجهة الموقع.