نظرة عامة

خضع HTTP/1.1 لتطور طويل منذ 1991 حتى 2014:

• HTTP/0.9 – 1991
• HTTP/1.0 – 1996
• HTTP/1.1
  • RFC 2068 – 1997
  • RFC 2616 - 1999
  • RFC 7230 - 2014

يعني ذلك وجود مجموعة متنوعة من الخوادم والعملاء، قد تكون لديهم آراء مختلفة حول حدود الطلبات، مما يخلق فرصًا لهجمات عدم التزامن (المعروفة باسم HTTP Desync).

قد يبدو اتباع أحدث توصيات RFC أمرًا بسيطًا. ومع ذلك، بالنسبة للأنظمة الكبيرة التي كانت موجودة منذ فترة، قد يكون لها تأثير غير مقبول على التوفر.

صممت مكتبة http_desync_guardian لتحليل طلبات HTTP لمنع هجمات HTTP Desync، مع موازنة الأمان والتوفر. تصنف الطلبات إلى فئات مختلفة وتقدم توصيات حول كيفية معالجة كل مستوى.

يمكن استخدامها إما لرؤوس طلبات HTTP الخام أو التي تم تحليلها بالفعل بواسطة محرك HTTP. يمكن للمستهلكين تكوين جمع السجلات والمقاييس. السجلات محدودة المعدل ويتم إخفاء جميع بيانات المستخدم.

إذا كنت تعتقد أنك عثرت على مشكلة أمنية محتملة، فيرجى اتباع عملية الإخطار الأمني لدينا.

الأولويات

• التوحيد عبر الخدمات هو المفتاح. هذا يعني أن تصنيف الطلبات والتسجيل وجمع المقاييس يجب أن يتم تحت الغطاء وبإعدادات متاحة بأقل قدر ممكن (مثل وجهة ملف السجل).
• التركيز على قابلية المراجعة. يجب ألا تتطلب مجموعة الاختبار أي معرفة بالمكتبة/لغات البرمجة ولكن فقط ببروتوكول HTTP. مما يسهل المراجعة والمساهمة وإعادة الاستخدام.
• الأمان فعال عندما يكون سهلاً للمستخدمين. هدفنا هو جعل دمج المكتبة بسيطًا قدر الإمكان.
• خفيف جدًا. يجب أن يكون الحمل الإضافي ضئيلًا وألا يفرض ضريبة ملموسة على معالجة الطلبات (انظر المعايير).

إصدارات HTTP المدعومة

التركيز الرئيسي لهذه المكتبة هو HTTP/1.1. انظر الاختبارات لجميع الحالات المغطاة. الإصدارات السابقة لـ HTTP/1.1 لا تدعم إعادة استخدام الاتصال مما يحد من فرص HTTP Desync، إلا أن بعض البروكسيات قد ترفع هذه الطلبات إلى HTTP/1.1 وتعيد استخدام اتصالات الواجهة الخلفية، مما قد يسمح بصياغة طلبات HTTP/1.0 ضارة. لهذا يتم تحليلها باستخدام نفس معايير HTTP/1.1. بالنسبة للإصدارات الأخرى من البروتوكول، هناك الاستثناءات التالية:

• طلبات HTTP/0.9 لا تعتبر أبدًا Compliant، بل تصنف كـ Acceptable. إذا كان أي من Content-Length/Transfer-Encoding موجودًا، فإنها تكون Ambiguous.
• HTTP/1.0 – وجود Transfer-Encoding يجعل الطلب Ambiguous.
• HTTP/2+ خارج النطاق. لكن إذا قام بروكسي الخاص بتخفيض HTTP/2 إلى HTTP/1.1، تأكد من تحليل الطلب الصادر.

انظر التوثيق لمعرفة المزيد.

الاستخدام من C

هذه المكتبة مصممة للاستخدام بشكل أساسي من محركات HTTP المكتوبة بلغة C/C++.

1. قم بتثبيت cbindgen: cargo install --force cbindgen
2. قم بإنشاء ملف الرأس:
   • قم بتشغيل cbindgen --output http_desync_guardian.h --lang c لـ C.
   • قم بتشغيل cbindgen --output http_desync_guardian.h --lang c++ لـ C++.
3. قم بتشغيل cargo build --release. الملفات الثنائية موجودة في ./target/release/libhttp_desync_guardian.*.

تعرف على المزيد: أمثلة عامة و Nginx.

#include "http_desync_guardian.h"

/* 
 * http_engine_request_t - already parsed by the HTTP engine 
 */
static int check_request(http_engine_request_t *req) {
    http_desync_guardian_request_t guardian_request = construct_http_desync_guardian_from(req); 
    http_desync_guardian_verdict_t verdict = {0};

    http_desync_guardian_analyze_request(&guardian_request, &verdict);

    switch (verdict.tier) {
        case REQUEST_SAFETY_TIER_COMPLIANT:
            // The request is good. green light
            break;
        case REQUEST_SAFETY_TIER_ACCEPTABLE:
            // Reject, if mode == STRICTEST
            // Otherwise, OK
            break;
        case REQUEST_SAFETY_TIER_AMBIGUOUS:
            // The request is ambiguous.
            // Reject, if mode == STRICTEST 
            // Otherwise send it, but don't reuse both FE/BE connections.
            break;
        case REQUEST_SAFETY_TIER_SEVERE:
            // Send 400 and close the FE connection.
            break;
        default:
            // unreachable code
            abort();
    }
}

الاستخدام من Rust

انظر المعايير كمثال على الاستخدام من Rust.

إخطارات المشكلات الأمنية

إذا اكتشفت مشكلة أمنية محتملة في http_desync_guardian، نطلب منك إخطار AWS Security عبر صفحة الإبلاغ عن الثغرات. يُرجى عدم إنشاء مشكلة عامة على github.

الأمان

انظر المساهمة لمزيد من المعلومات.

الترخيص

هذا المشروع مرخص بموجب رخصة Apache-2.0.