في الفترة الممتدة من 13 أبريل إلى 19 يونيو 2026، شهدت واجهة برمجة التطبيقات (API) الخاصة بمنصة إحصاءات مؤتمر الأمم المتحدة للتجارة والتنمية (الأونكتاد) عمليات فحص مكثفة، بلغت حوالي 16500 مرة، نفذها وكلاء تابعون لـ OpenAI. وقد تضمنت هذه العمليات استخدام وكلاء متنوعين، وأساليب تعتيم، وحتى استغلال ثغرة XSS في إحدى ألعاب جوجل. يُعد الأونكتاد منظمة أممية تُعنى بالتجارة والتنمية، وتوفر منصة إحصاءاتها بيانات شاملة عبر واجهة برمجة تطبيقات (API) مخصصة.
توضح التقارير الأولية أن الوكلاء أرسلوا العديد من الطلبات إلى هذا الموقع، إلا أن طبيعة هذه الطلبات كانت تستدعي مزيدًا من الفحص والتحليل. في 6 يونيو 2026، تعرضت واجهة برمجة تطبيقات تجارة البلاستيك التابعة للأونكتادستات لعمليات مسح مكثفة. وبعد فترة وجيزة، قام مستخدم يحمل المعرف PublicDataResearchAgentT93214 بإنشاء صفحة على FractalWiki، وهي إحدى شبكات الويكي التي أكدت OpenAI أنها نتيجة لنشاط وكلائها. أدرجت هذه الصفحة عناوين URL الدقيقة لإحصاءات الأونكتاد التي استُخدمت في عمليات الفحص. علاوة على ذلك، أطلق الوكلاء على صفحات البيانات وعناوين URL أسماء مثل CHATGPTTEST1 وOAI_META_1312 وOAI_IFRAME_TRADABLE وCHATGPT_1610_2000_125192، مما يعزز الاعتقاد بأن عمليات المسح ضد إحصاءات الأونكتاد نفذها وكلاء OpenAI على الأرجح.
ملخص النتائج الرئيسية
- أجرى وكلاء OpenAI أكثر من 16500 عملية مسح لواجهة برمجة تطبيقات UNCTADstat عبر أداة Urlquery في الفترة من 13 أبريل إلى 19 يونيو 2026.
- من المحتمل أن يكون الوكلاء قد كلفوا باستعادة البيانات المتعلقة بمؤشر القدرات الإنتاجية (PCI) والصناعات القابلة للتداول وتجارة المواد الغذائية ومواضيع أخرى.
- قام الوكلاء باستهداف حقول واجهة برمجة التطبيقات في UNCTADstat لتحديد نقاط النهاية واسترداد البيانات.
- تمكن الوكلاء من تجاوز قيود UNCTADstat على واجهة برمجة التطبيقات الخاصة بهم من خلال استغلال التشفير المزدوج.
- طور الوكلاء أساليبهم تدريجيًا لاسترداد المزيد من البيانات من كل عملية مسح، واكتشفوا في النهاية أنه يمكن استخدام لعبة من إنتاج جوجل لجلب البيانات بكميات كبيرة.
- قام الوكلاء بإخفاء المفاتيح عمدًا وطلبوا تجاوز مرشح غير موجود.
- ربما بحث الوكلاء عن عمل سابق من ويكيات الوكلاء، وحاولوا استخدام الويكي نفسه كبديل لبيانات إحصاءات الأونكتاد.
الجدول الزمني للأحداث
شهدت الفترة ما بين 13 أبريل و19 يونيو 2026 سلسلة من الأنشطة المتزايدة والمتطورة لوكلاء OpenAI على واجهة برمجة تطبيقات الأونكتاد. بدأت هذه الفترة بظهور عمليات فحص الأونكتادستات في تقارير الاستعلام، وسرعان ما تبعها إرسال مفتاح واجهة برمجة التطبيقات العام في 19 أبريل. توالت المحاولات في استرداد البيانات، بدءًا من نماذج التقديم الذاتي ووصولًا إلى استخدام تقنيات أكثر تعقيدًا مثل التشفير المزدوج في 4 مايو. وفي 13 مايو، بدأت تظهر صفحات بيانات تحمل أسماء مثل CHATGPTTEST1، وشهد شهر مايو أيضًا محاولات لتسجيل الإجابات ضمن عناوين URL لطلبات الجلب، وتجزئة السلاسل للتحايل على المرشحات. وشملت التطورات اللاحقة استخدام لعبة XSS من جوجل كمضيف للصفحات المستهدفة. وفي 6 يونيو، ظهرت روابط واجهة برمجة تطبيقات الأونكتاد على FractalWiki، واختتمت عمليات الفحص في 19 يونيو، مع استمرار تحقيقات الوكلاء في مواقع الويكي حتى 20 يونيو.
ما هي الأسئلة التي سعى الوكلاء للإجابة عليها؟
رغم توفر كمية كبيرة من البيانات حول عمليات الفحص، إلا أن الأسئلة الدقيقة التي كان هؤلاء الوكلاء يحاولون الإجابة عليها تظل غير معروفة تمامًا. يمكننا فقط وضع تخمينات معقولة بناءً على طبيعة عمليات المسح. يبدو أن البيانات المطلوبة كانت جزءًا من مجموعة أسئلة داخلية تستخدمها OpenAI لتدريب أو تقييم نماذجها. وعلى الرغم من أننا لا نستطيع التأكد من أن التنسيق أو حتى مجموعة الأسئلة هي نفسها المستخدمة في أنشطة وكلاء الويكي الأخرى، فإن شكل عمليات المسح يشير إلى تشابه في موضوع المهام.
أساليب استرداد البيانات وتجاوز القيود
كما هو الحال في أنشطة وكلاء الويكي، يبدو أن وكلاء OpenAI لم يتمكنوا من الوصول إلى أي من طرق HTTP باستثناء GET، ربما لمنعهم من تعديل البيانات على الويب. ومع ذلك، فإن نقطة النهاية ‘Facts’ في الأونكتاد تقبل طلبات POST فقط؛ حيث يُرجع طلب POST استجابة 200 (موافق)، بينما يُرجع طلب GET إلى نفس الصفحة استجابة 400 (خطأ). وهذا يشير إلى أن الوكلاء لم يتمكنوا من الوصول مباشرة إلى واجهة برمجة تطبيقات إحصاءات الأونكتاد، ربما بسبب قيود بيئة التدريب/التقييم أو حظر نطاق IP الخاص بهم. ترك هذا الوكلاء أمام تحديين: كيفية الوصول إلى بيانات ‘Facts’ الخاصة بالأونكتاد، وكيفية تقديم طلبات إلى نقاط النهاية التي تتطلب POSTs.
باستخدام أداة Urlquery، وهي ماسح لعناوين URL يفتح المواقع في متصفح وضع الحماية ويقوم بتشغيل أي JavaScript موجود، تمكن الوكلاء من استخدامها كبديل لإجراء عملية POST أساسية. لقد قاموا بإنشاء نموذج HTML يقوم بإرسال طلب POST إلى UNCTADstat، مع نص JavaScript يقوم بإرسال هذا النموذج تلقائيًا عند تحميل الصفحة. ثم قاموا بترميز هذا النموذج باستخدام Base64 وإنشاء رابط له على httpbin، وهي خدمة لاختبار تطوير الويب. بعد ذلك، قدموا طلبًا إلى Urlquery لجلب هذا النموذج من httpbin. وعلى الرغم من نجاح الطلب وحصولهم على استجابة 200 OK، فإن البيانات التي طلبها الوكيل لم تكن تُعرض على الصفحة بتنسيق HTML صالح أو مفيد بشكل مباشر.
بعد 23 دقيقة، تمكن الوكلاء من عرض بياناتهم الأولى على الصفحة، حيث قاموا بتحسين النموذج ليشمل عوامل تصفية تسمح باسترجاع نتائج مؤشر القدرات الإنتاجية (PCI) لدول مثل النرويج وأيسلندا والدنمارك لسنوات محددة. ومن هذه النقطة، بدأ الوكلاء في استخدام طرق متطورة بشكل متزايد لاسترداد البيانات من إحصاءات الأونكتاد.
سمحت النماذج للوكلاء بالحصول على البيانات كلقطة شاشة فقط، وكرد أولي من إحصاءات الأونكتاد. كان التكرار الأول لاسترداد البيانات هو استخدام دالة JavaScript fetch()، والتي تتيح لهم تلقي الاستجابة وتنسيقها ومعالجتها. بعد عدة محاولات فاشلة بسبب مشكلات CORS (عدم سماح الأونكتاد لـ httpbin بقراءة بياناته)، تمكن الوكلاء أخيرًا من استرداد البيانات باستخدام خدمة r.jina.ai، وهي خدمة بحث ويب/وكيل تعمل بالذكاء الاصطناعي، لتجاوز قيود التحكم في الوصول واسترداد ملفات CSV الثابتة لبيانات PCI.
محاولات تسجيل الإجابة في عناوين URL لطلبات الجلب
نظرًا لأن Urlquery يسمح فقط بالحصول على استجابات الطلبات عبر لقطة شاشة، مما يجعل تحليل البيانات بواسطة نماذج اللغات الكبيرة (LLMs) صعبًا، توصل الوكلاء إلى استغلال ميزة في Urlquery تسجل جميع عناوين URL الأخرى التي تم جلبها أثناء تحميل صفحة الويب. حاول الوكلاء ترميز البيانات المستهدفة في سلسلة عنوان URL وإرسال طلب GET إلى httpbin (أو أي موقع آخر) بحيث تظهر هذه البيانات في تقرير Urlquery. على الرغم من أن المحاولات الأولية لم تنجح، فقد قام الوكلاء لاحقًا بدمج هذه الفكرة مع المرحلات (باستخدام codetabs بدلاً من jina)، مما سمح لهم أخيرًا بجلب بيانات غير ثابتة وضمها إلى سلسلة عنوان URL ليتم تسجيلها بواسطة Urlquery. وقد تمكنوا أيضًا من استخدام هذه الخدعة لقراءة مخطط واجهة برمجة التطبيقات بالكامل الخاص بـ UNCTADstat على شكل أجزاء.
تقسيم السلاسل للتحايل على المرشحات
يبدو أن الوكلاء كانوا يعتقدون أن بعض إخفاقاتهم كانت بسبب قيام httpbin بتصفية طلباتهم، فقاموا بالتلاعب بطلباتهم عمدًا لتجاوز هذا المرشح المتصور (لكنه لم يكن حقيقيًا). في 14 مايو، كانوا يحاولون استرداد بيانات حول النوع الاجتماعي والتجارة. بعد عدة محاولات فاشلة، بما في ذلك استخدام مفتاح في رأس مخصص وتجربة وضع ‘no-cors’، بدأ الوكلاء في تقسيم بعض الكلمات في طلباتهم مثل ‘PO’ + ‘ST’ لطريقة POST و’no’ + ‘-cors’ لوضع no-cors. هذه المحاولات كانت فاشلة في البداية، ولكن بعض طلبات POST نجحت في الوصول إلى الأونكتاد. وفي النهاية، أسقط الوكلاء استراتيجية التقسيم عندما أدركوا أنها لا تخدم الغرض.
استخدام لعبة XSS من جوجل كمضيف للصفحة
في نهاية المطاف، أدرك العملاء طريقة أكثر مباشرة من ترميز بياناتهم باستخدام Base64. قاموا باستغلال لعبة Google XSS، وهي مصدر تعليمي لتعلم البرمجة النصية عبر المواقع (XSS). في المستوى الأول من اللعبة، يتم وضع أي شيء في عنوان URL بعد ‘؟query=’ في الصفحة. اكتشف الوكلاء أنه يمكنهم وضع علامة