justinas/nosurf-cve-2025-46721إثبات المفهوم وتحليل لـ CVE-2025-46721، وهي ثغرة من نوع CSRF في مكتبة nosurf للغة Go بسبب فشل فحوصات نفس المصدر، مع عرض استغلال عملي.
جميع إصدارات nosurf قبل 1.2.0 فشلت في تطبيق عمليات التحقق من نفس المصدر (same-origin checks) للطلبات الواردة.
حدث هذا بسبب الاعتماد على الحقل .URL.Scheme من نوع net/http.Request الخاص بمكتبة Go القياسية
للتأكد أولاً من أن الطلب يُقدّم عبر HTTPS، وعندها فقط يتم تطبيق عمليات التحقق من نفس المصدر.
الحقل المذكور Scheme لا يتم تعبئته بواسطة خادم HTTP الخاص بلغة Go للطلبات الواردة:
بالنسبة لطلبات الخادم، يتم تحليل URL من URI المقدّم في سطر الطلب (Request-Line) المخزّن في RequestURI. بالنسبة لمعظم الطلبات، ستكون الحقول الأخرى غير Path و RawQuery فارغة.
حيث أنه في الحالة العامة، لا يمكن لـ Go تحديد ما إذا كان الطلب يحدث عبر TLS (بسبب وجود وكيل عكسي يُنهي TLS، وما إلى ذلك).
قد يسمح هذا للمهاجمين بإرسال طلبات عبر الأصل (cross-origin) غير آمنة إلى موقعك الإلكتروني.
بالإضافة إلى تنفيذ عمليات التحقق من نفس المصدر، يحمي nosurf أيضًا من CSRF باستخدام نمط إرسال ملف تعريف الارتباط المزدوج (double-submit cookie pattern).
هذا يعني أنه، لتنفيذ طلب عبر الأصل يُغيّر البيانات بنجاح،
يحتاج المهاجم أيضًا إلى التحكم في محتويات صفحة على موقعك الإلكتروني،
أو على نطاق فرعي لموقعك الإلكتروني.
يمكن تحقيق ذلك عبر ثغرة XSS، أو إذا منحت التحكم في محتوى HTML للمستخدمين على موقعك الإلكتروني عمدًا
(على سبيل المثال، أنت مزود استضافة example.com يسمح للمستخدمين باستضافة مواقعهم على alice.example.com).
يوضح إثبات المفهوم (PoC) في هذا المستودع مثل هذا الهجوم في الحالة الأخيرة، حيث يتحكم المهاجم في المحتوى على نطاق فرعي من النطاق الرئيسي للموقع.
يتطلب Go و Caddy. قم بتشغيل الخوادم يدويًا:
$ go run attacker.go & go run target.go & caddy run
أو عبر Process Compose:
$ process-compose
قم بزيارة https://attacker.target.localhost.
انقر على الزر لإرسال النموذج إلى https://target.localhost ولاحظ أن الطلب يتم بنجاح.
تم إصدار إصلاح لهذه المشكلة في nosurf 1.2.0.
شكرًا لـ Patrick O'Doherty على الإبلاغ عن المشكلة.