NileOverFlow

HTTP

13 min read

بروتوكول HTTP — الأساس الذي يقوم عليه أمن الويب

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

المحتويات

  1. ما هو بروتوكول HTTP؟
  2. مكوّنات نظام HTTP
  3. كيف يعمل HTTP؟ — رحلة الطلب والاستجابة
  4. طلب HTTP — HTTP Request
  5. استجابة HTTP — HTTP Response
  6. رموز حالة HTTP — Status Codes
  7. ملفات تعريف الارتباط — HTTP Cookies
  8. Stateless مقابل Stateful — الفرق الجوهري
  9. HTTP من منظور أمني
  10. المصادر والمراجع

1. ما هو بروتوكول HTTP؟

HTTP هو اختصار لـ HyperText Transfer Protocol، أي بروتوكول نقل النص التشعبي. وهو البروتوكول الذي يُشكّل العمود الفقري لأي عملية تبادل بيانات على شبكة الويب. يعمل HTTP وفق نموذج العميل-الخادم (Client-Server)، حيث يكون الطلب دائماً صادراً من طرف العميل — عادةً المتصفح — والاستجابة صادرة من الخادم.

بعبارة مبسّطة: HTTP هو اللغة المشتركة التي يتحدث بها متصفحك وأي خادم ويب في العالم. كل مرة تفتح فيها موقعاً أو تضغط على رابط أو ترسل نموذجاً، فأنت في الحقيقة تُرسل رسالة HTTP وتنتظر الرد.

🔐 الصلة بأمن الويب: بما أن HTTP هو القناة الوحيدة التي تمر من خلالها جميع البيانات بين المتصفح والخادم، فإن أغلب ثغرات تطبيقات الويب تُستغل عبر التلاعب بهذا البروتوكول مباشرةً. أدوات مثل Burp Suite و**OWASP ZAP** تعمل بالأساس كوسيط (Proxy) يعترض رسائل HTTP ويُمكّن الباحث الأمني من تعديلها وإعادة إرسالها.

2. مكوّنات نظام HTTP

يقوم نظام HTTP على ثلاثة أطراف رئيسية:

2.1 العميل (Client) — وكيل المستخدم

وكيل المستخدم (User-Agent) هو أي برنامج يتصرف نيابةً عن المستخدم لإرسال طلبات HTTP. في معظم الحالات يكون هذا هو المتصفح (Chrome، Firefox، Safari…)، لكنه يمكن أن يكون أيضاً:

  • أداة سطر أوامر مثل curl أو wget
  • برنامج زحف لمحركات البحث (Web Crawler)
  • سكريبت Python يستخدم مكتبة requests
  • أداة اختبار اختراق مثل Burp Suite أو sqlmap

المتصفح هو دائماً الطرف الذي يبدأ الاتصال — الخادم لا يُرسل بيانات من تلقاء نفسه ما لم يُطلب منه ذلك (باستثناء تقنيات حديثة مثل WebSockets وServer-Sent Events التي خرجت عن هذا النمط).

2.2 الخادم (Server)

الخادم هو الطرف الذي يستقبل الطلبات ويُعيد الاستجابات. من الناحية التقنية، قد لا يكون الخادم جهازاً واحداً، بل قد يكون:

  • مجموعة خوادم تتوزع عليها الأحمال (Load Balancing)
  • خادم قواعد بيانات خلفي
  • خادم تخزين مؤقت (Cache Server)
  • بنية Microservices تتعاون معاً

🔐 الصلة بأمن الويب: من منظور الـ Bug Bounty، معرفة أن “الخادم” قد يكون في الواقع عشرة خوادم مختلفة تُقنّعها واجهة واحدة (Reverse Proxy) كـ Nginx أو Cloudflare، يُفيد كثيراً في فهم لماذا قد يختلف سلوك التطبيق من طلب لآخر. بعض الثغرات كـ HTTP Request Smuggling تستغل بالضبط الاختلافات في كيفية تفسير كل خادم وسيط لطلبات HTTP.

2.3 البروكسيات (Proxies)

بين المتصفح والخادم توجد عادةً كيانات وسيطة تُسمى بروكسي (Proxy)، تؤدي وظائف مثل:

الوظيفةالوصف
التخزين المؤقت (Caching)حفظ نسخ من الاستجابات لتسريع التصفح
الفلترة (Filtering)حجب محتوى معين كما تفعل أنظمة الرقابة
موازنة الأحمال (Load Balancing)توزيع الطلبات على عدة خوادم
التشفير (TLS Termination)فك تشفير HTTPS وإعادة توجيه الطلب داخلياً

🔐 الصلة بأمن الويب: تمنحك أداة Burp Suite وظيفة بروكسي محلي على جهازك، مما يُمكّنك من رؤية وتعديل كل طلب HTTP قبل أن يصل إلى الخادم. هذه هي نقطة الانطلاق الأولى لأي اختبار اختراق لتطبيق ويب.

3. كيف يعمل HTTP؟ — رحلة الطلب والاستجابة

فيما يلي ما يحدث خلف الكواليس عندما تكتب عنواناً في متصفحك وتضغط Enter:

المتصفح                    DNS                     الخادم
   |                        |                          |
   |--- (1) DNS Lookup ----->|                          |
   |<-- (2) IP Address ------|                          |
   |                         |                          |
   |---------- (3) HTTP Request (GET /) --------------->|
   |                         |                          |
   |<--------- (4) HTTP Response (200 OK + HTML) -------|
   |                         |                          |
   |--- (5) عرض الصفحة في المتصفح ---                   |

شرح الخطوات:

  1. فتح المتصفح وكتابة URL: تكتب www.example.com في شريط العنوان. المتصفح الآن يحتاج لمعرفة عنوان IP الخاص بهذا الموقع.

  2. البحث في DNS (Domain Name System): المتصفح يسأل خادم DNS: “ما عنوان IP الخاص بـ www.example.com؟“. النتيجة مثلاً: 93.184.216.34. فكّر في DNS كدليل الهواتف — يُحوّل الاسم المقروء إلى رقم يفهمه الكمبيوتر.

  3. إرسال طلب HTTP: بعد الحصول على عنوان IP، يُرسل المتصفح طلب HTTP إلى الخادم يطلب فيه الصفحة الرئيسية.

  4. استجابة الخادم: الخادم يُعالج الطلب ويُرسل الاستجابة التي تحتوي على ملفات HTML وCSS وJavaScript اللازمة لعرض الصفحة.

  5. عرض الصفحة: المتصفح يستقبل البيانات ويُحوّلها إلى الصفحة المرئية التي تراها. بعد اكتمال العملية، تُغلق الاتصال. وإذا طلبت صفحة جديدة — يبدأ كل شيء من جديد.

🔐 الصلة بأمن الويب: خطوة DNS Lookup هي هدف لثغرة تُعرف بـ DNS Rebinding Attack، حيث يخدع المهاجم المتصفح للتحدث مع خادم مختلف عن الذي يعتقد أنه يتحدث إليه. كذلك، التحكم في خادم DNS يُمكّن من تنفيذ هجمات Man-in-the-Middle (MITM).

4. طلب HTTP — HTTP Request

طلب HTTP هو الرسالة التي يُرسلها العميل إلى الخادم. إليك مثالاً حقيقياً:

GET /login HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: ar,en;q=0.9
Cookie: session_id=abc123xyz; theme=dark
Connection: keep-alive

يتكون الطلب من العناصر التالية:

4.1 HTTP Method — فعل الطلب

يُحدّد نوع العملية المطلوبة. أبرز الأفعال:

الفعلالوصفمثال الاستخدام
GETجلب موردتحميل صفحة ويب
POSTإرسال بيانات إلى الخادمتسجيل الدخول، إرسال نموذج
PUTاستبدال مورد كاملتحديث ملف المستخدم بالكامل
PATCHتعديل جزئي لموردتغيير كلمة المرور فقط
DELETEحذف موردحذف حساب
OPTIONSالاستفسار عن الأفعال المدعومةيُستخدم في CORS
HEADجلب الرؤوس فقط دون الجسمالتحقق من وجود مورد

🔐 الصلة بأمن الويب: أحد الأخطاء الشائعة في التطبيقات هو التحكم في الصلاحيات بناءً على نوع الفعل فقط. مثلاً، الخادم قد يمنع POST /admin/deleteUser لكن لا يتحقق من DELETE /admin/deleteUser. هذا ما يُعرف بـ HTTP Verb Tampering وهو ثغرة ضمن نطاق كثير من برامج Bug Bounty.

4.2 URL — عنوان المورد

العنوان الكامل يتكون من:

https://www.example.com:443/profile?id=42&tab=settings#bio
  │           │           │     │        │                │
  │           │           │     │        │                └── Fragment (المرساة)
  │           │           │     │        └── Query Parameters (معاملات الاستعلام)
  │           │           │     └── Path (المسار)
  │           │           └── Port (المنفذ)
  │           └── Domain (النطاق)
  └── Protocol/Scheme (البروتوكول)

🔐 الصلة بأمن الويب: معاملات الاستعلام (Query Parameters) مثل ?id=42 هي من أكثر نقاط الدخول شيوعاً لثغرات كـ SQL Injection و**IDOR (Insecure Direct Object Reference)**. عندما ترى ?id=42 في عنوان ما، جرّب تغييره إلى ?id=43 أو ?id=1 — قد تجد نفسك تصل إلى بيانات مستخدم آخر!

4.3 Request Headers — رؤوس الطلب

الرؤوس هي بيانات وصفية (Metadata) تُرفق بالطلب. أهمها من الناحية الأمنية:

الرأسالوصفالأهمية الأمنية
Hostالنطاق المستهدفثغرة Host Header Injection
User-Agentمعلومات المتصفحيمكن تزويره بسهولة
Cookieملفات تعريف الارتباطبيانات الجلسة الحساسة
Authorizationبيانات المصادقةJWT tokens, API Keys
Refererالصفحة السابقةتسريب معلومات حساسة
Originمصدر الطلبآلية CORS
Content-Typeنوع محتوى الجسمالتحقق الضروري قبل معالجة البيانات

4.4 Request Body — جسم الطلب

يُرفق بالطلبات التي تحمل بيانات (مثل POST وPUT). يمكن أن يكون بصيغ مختلفة:

POST /api/login HTTP/1.1
Content-Type: application/json
 
{
  "username": "ahmed",
  "password": "MyPassword123"
}

أو بصيغة HTML Form:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
 
username=ahmed&password=MyPassword123

5. استجابة HTTP — HTTP Response

استجابة HTTP هي الرد الذي يُرسله الخادم. مثال حقيقي:

HTTP/1.1 200 OK
Date: Wed, 25 Mar 2026 10:00:00 GMT
Server: nginx/1.24.0
Content-Type: text/html; charset=UTF-8
Content-Length: 4523
Set-Cookie: session_id=xyz987; HttpOnly; Secure; SameSite=Strict
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
 
<!DOCTYPE html>
<html>
  <body>مرحباً أحمد!</body>
</html>

تتكون الاستجابة من:

5.1 رمز الحالة (Status Code)

سيُشرح في القسم التالي بالتفصيل.

5.2 Response Headers — رؤوس الاستجابة

الرؤوس التي يُرسلها الخادم تحمل معلومات بالغة الأهمية من ناحية أمنية:

الرأسالوصفالأهمية الأمنية
Set-Cookieيُعيّن ملفات تعريف الارتباطإذا غاب HttpOnly → ثغرة XSS
X-Frame-Optionsيمنع تضمين الصفحة في <iframe>حماية من Clickjacking
Content-Security-Policyسياسة المحتوى المسموح بهحماية من XSS
X-Content-Type-Optionsيمنع تخمين نوع المحتوىحماية من MIME Sniffing
Strict-Transport-Securityيُجبر المتصفح على HTTPSحماية من SSL Stripping
Serverاسم وإصدار الخادمتسريب معلومات — يجب إخفاؤه!

🔐 الصلة بأمن الويب: في أي اختبار اختراق أو برنامج Bug Bounty، من أولى خطواتك فحص رؤوس الاستجابة. غياب رأس Content-Security-Policy أو X-Frame-Options قد يكون بحد ذاته ثغرة مقبولة في بعض البرامج. كذلك، وجود رأس Server: Apache/2.2.3 يُخبر المهاجم بالإصدار القديم الضعيف الذي يُشغّله الخادم.

5.3 Response Body — جسم الاستجابة

المحتوى الفعلي المُرسل: صفحة HTML، بيانات JSON، صورة، ملف… إلخ.

6. رموز حالة HTTP — Status Codes

رموز الحالة هي أرقام ثلاثية تُخبرك بنتيجة الطلب. تنقسم إلى خمس فئات:

6.1 الفئة 1xx — إعلامية

(Informational)

الطلب مستلم ومعالجته جارية.

الرمزالاسمالوصف
100Continueاستمر في إرسال الطلب
101Switching Protocolsالتبديل إلى بروتوكول آخر (مثل WebSocket)

6.2 الفئة 2xx — نجاح

(Successful)

الطلب تمّ بنجاح.

الرمزالاسمالوصف
200OKالطلب ناجح والبيانات مُرسلة
201Createdتم إنشاء مورد جديد بنجاح
204No Contentالطلب ناجح لكن لا توجد بيانات للإرجاع

6.3 الفئة 3xx — إعادة التوجيه (Redirection)

المتصفح يحتاج إلى اتخاذ خطوة إضافية.

الرمزالاسمالوصف
301Moved Permanentlyالصفحة انتقلت نهائياً لعنوان جديد
302Foundإعادة توجيه مؤقتة
304Not Modifiedالمحتوى لم يتغير — استخدم النسخة المخزّنة

🔐 الصلة بأمن الويب: ثغرة Open Redirect تحدث عندما يأخذ الخادم وجهة إعادة التوجيه من مدخلات المستخدم دون تحقق. مثلاً: https://example.com/redirect?url=https://evil.com — إذا وجّه الخادم المستخدم للـ URL الخارجي مباشرةً، فهذه ثغرة يمكن توظيفها في هجمات Phishing وفي بعض الحالات لسرقة OAuth tokens.

6.4 الفئة 4xx — خطأ من طرف العميل (Client Error)

مشكلة في الطلب نفسه.

الرمزالاسمالوصف
400Bad Requestصيغة الطلب خاطئة
401Unauthorizedتسجيل الدخول مطلوب
403Forbiddenليس لديك صلاحية
404Not Foundالصفحة غير موجودة
405Method Not Allowedالفعل المستخدم غير مسموح
429Too Many Requestsتجاوزت الحد المسموح من الطلبات

🔐 الصلة بأمن الويب:

  • الفرق بين 401 و403 مهم: الأول يعني “من أنت؟” (لم تُثبت هويتك)، والثاني يعني “أعرف من أنت لكنك غير مُخوَّل”. إذا حصلت على 403، فهذا دليل على أن المورد موجود — ما يساعدك في رسم خريطة التطبيق (Recon).
  • غياب 429 يعني أن الخادم لا يُطبّق Rate Limiting، وهذا يفتح الباب لهجمات Brute Force على تسجيل الدخول.
  • 404 الصادر عن صفحات لم تطلبها قد يدلّ على وجود Hidden Endpoints يمكن استكشافها بأدوات مثل ffuf وdirsearch.

6.5 الفئة 5xx — خطأ من طرف الخادم (Server Error)

مشكلة على جانب الخادم.

الرمزالاسمالوصف
500Internal Server Errorخطأ غير متوقع في الخادم
502Bad Gatewayالخادم الوسيط تلقّى استجابة خاطئة
503Service Unavailableالخادم غير متاح مؤقتاً

🔐 الصلة بأمن الويب: 500 Internal Server Error الذي يظهر عند إدخال بيانات غير متوقعة (مثل علامة ' في حقل نصي) هو مؤشر ممتاز على احتمال وجود ثغرة SQL Injection أو خطأ في معالجة المدخلات. الخطأ نفسه لا يُعدّ ثغرة، لكنه باب للتحقيق.

7. ملفات تعريف الارتباط — HTTP Cookies

ملف تعريف الارتباط (HTTP Cookie) — ويُعرف أيضاً بـ web cookie أو browser cookie — هو قطعة صغيرة من البيانات يُرسلها الخادم إلى متصفح المستخدم عبر رأس Set-Cookie، فيحتفظ بها المتصفح ويُعيد إرسالها تلقائياً مع كل طلب لاحق إلى نفس النطاق عبر رأس Cookie.

يُستخدم الـ Cookie بشكل رئيسي لـ:

  • إدارة الجلسات: الحفاظ على حالة تسجيل الدخول
  • التخصيص: حفظ تفضيلات المستخدم (اللغة، الثيم…)
  • التتبع والتحليل: تتبع سلوك المستخدم لأغراض إحصائية أو إعلانية
المتصفح                                   الخادم
   |                                          |
   |-------- GET /login ---------------------->|
   |                                          |
   |<-- HTTP/1.1 200 OK                        |
   |    Set-Cookie: session=abc123; HttpOnly  |
   |    Set-Cookie: theme=dark               ---|
   |                                          |
   |  [المتصفح يحفظ الـ Cookies]              |
   |                                          |
   |-------- GET /profile ---------------------->|
   |    Cookie: session=abc123; theme=dark    |
   |                                          |
   |<-- HTTP/1.1 200 OK (بيانات المستخدم) ----|

عند إنشاء الـ Cookie، يمكن للخادم تحديد خصائص تتحكم في سلوكه وتُعزّز أمانه:

Set-Cookie: session_id=abc123xyz;
            Expires=Thu, 01 Jan 2027 00:00:00 GMT;
            Path=/;
            Domain=example.com;
            HttpOnly;
            Secure;
            SameSite=Strict
الخاصيةالوصفماذا يحدث عند غيابها؟
HttpOnlyيمنع JavaScript من قراءة الـ Cookieثغرة XSS تسمح بسرقة الجلسة
Secureيُرسل الـ Cookie عبر HTTPS فقطسرقة الجلسة عبر Man-in-the-Middle
SameSite=Strictيمنع إرسال الـ Cookie من نطاق خارجيثغرة CSRF
Expires/Max-Ageتاريخ انتهاء صلاحية الـ Cookieجلسة لا تنتهي أبداً
Pathيُحدد المسارات التي يُرسل لها الـ Cookieتسريب الـ Cookie لمسارات لا تحتاجه
Domainالنطاقات المسموح لها باستقبال الـ Cookieمشاركة غير مقصودة مع نطاقات فرعية

🔐 الصلة بأمن الويب: الـ Cookies هي الهدف الأول في كثير من هجمات الويب:

  • Session Hijacking: سرقة الـ Cookie لانتحال هوية المستخدم
  • XSS → Cookie Theft: إذا غاب HttpOnly، يكفي حقن سكريبت document.cookie لسرقة الجلسة
  • CSRF: خداع متصفح المستخدم لإرسال طلبات لا يريدها بحكم أن الـ Cookie يُرسل تلقائياً
  • Cookie Injection: في بعض الحالات، يمكن التلاعب بمحتوى الـ Cookie إذا لم يُتحقق منه الخادم بشكل صحيح

8. Stateless مقابل Stateful — الفرق الجوهري

8.1 HTTP بطبيعته Stateless (عديم الحالة)

البروتوكول HTTP في جوهره عديم الحالة (Stateless)، أي أن كل طلب مستقل تماماً عن الطلبات السابقة — الخادم لا يحتفظ بأي ذاكرة بين الطلبات.

مثال توضيحي: تخيّل أنك تتصل بموظف خدمة عملاء يُصاب بفقدان الذاكرة بين كل مكالمة ومكالمة. في كل مرة تتصل، عليك إعادة تعريف نفسك من الصفر: “أنا فلان، لدي طلب رقم كذا، اتصلت بالأمس وقلت لي…“. هذا بالضبط هو HTTP Stateless — كل طلب يبدأ من نقطة الصفر.

كود يوضّح المشكلة:

الطلب 1:  GET /products → الخادم: "حسناً، إليك المنتجات"
الطلب 2:  GET /cart     → الخادم: "من أنت؟ ما سلة التسوق؟ لا أعرفك!"

8.2 لماذا نحتاج Stateful؟

معظم تطبيقات الويب الحديثة تحتاج لـ”ذاكرة” بين الطلبات:

  • تسجيل الدخول مرة واحدة والبقاء مُسجّلاً
  • سلة التسوق التي تتراكم فيها المنتجات
  • تذكّر تفضيلات المستخدم

8.3 كيف نُحوّل HTTP إلى Stateful؟

بما أن HTTP نفسه لا يدعم الحالة، تُستخدم عدة آليات لإضافتها من الخارج:

الآليةالوصفالإيجابياتالسلبيات
Cookiesالخادم يُرسل معرّف الجلسة، المتصفح يُعيدهتلقائي، شفاف للمستخدمعُرضة لـ CSRF وXSS
Session Tokens in URL?session=abc123 في العنوانلا يحتاج Cookiesخطير جداً — يظهر في Logs وReferer
JWT (JSON Web Token)رمز مشفّر يحمل بيانات المستخدمStateless كامل، مناسب للـ APIsمشكلة الإلغاء (Revocation)
Local Storageتخزين في المتصفح عبر JavaScriptمرنلا تُرسل تلقائياً، عُرضة لـ XSS

مثال توضيحي للـ Stateful: الآن تخيّل أن موظف الخدمة يُعطيك بطاقة عضوية برقم فريد عند أول اتصال. في كل مرة تتصل لاحقاً، تذكر رقم البطاقة، وهو يبحث في السجلات ويجد كل تاريخ تعاملاتك. الـ Cookie هو هذه “البطاقة” التي يحملها متصفحك وتُعرّفك للخادم في كل طلب.

9. HTTP من منظور أمني

9.1 HTTP مقابل HTTPS

HTTPHTTPS
التشفيرلا يوجد — كل شيء نص صريحTLS/SSL يُشفّر كل شيء
المصادقةلا يوجد — لا تعرف إن كنت تتحدث للخادم الصحيحشهادة رقمية تُثبت هوية الخادم
المنفذ الافتراضي80443
الخطرMan-in-the-Middle، التنصتأقل بكثير (لكن ليس صفراً)

ملاحظة مهمة: HTTPS يُشفّر القناة، لكنه لا يحمي من الثغرات في منطق التطبيق نفسه. تطبيق يستخدم HTTPS ولكن به ثغرة SQL Injection لا يزال ثغرة خطيرة.

9.2 الثغرات الأكثر شيوعاً المرتبطة بـ HTTP

HTTP Vulnerabilities
│
├── معالجة المدخلات (Input Handling)
│   ├── SQL Injection       ← بيانات خبيثة في Query Parameters / Body
│   ├── XSS                 ← سكريبتات خبيثة في مدخلات تُعرض لاحقاً
│   └── Command Injection   ← أوامر نظام في مدخلات غير محصّنة
│
├── التحكم في الوصول (Access Control)
│   ├── IDOR                ← تغيير id في URL للوصول لبيانات آخرين
│   ├── Missing Auth        ← Endpoints لا تتحقق من تسجيل الدخول
│   └── HTTP Verb Tampering ← استخدام PUT/DELETE بدل POST للتحايل
│
├── إدارة الجلسات (Session Management)
│   ├── Session Hijacking   ← سرقة Cookie
│   ├── CSRF                ← تزوير طلبات عبر المتصفح
│   └── Weak Session IDs    ← معرّفات جلسة يمكن تخمينها
│
└── رؤوس HTTP (Headers)
    ├── Clickjacking        ← غياب X-Frame-Options
    ├── MIME Sniffing       ← غياب X-Content-Type-Options
    └── Information Leakage ← تسريب إصدار الخادم في رأس Server

9.3 أدوات أساسية للباحث الأمني

الأداةالوظيفة
Burp Suiteاعتراض وتعديل طلبات HTTP (الأداة الأساسية)
OWASP ZAPبديل مجاني لـ Burp Suite
curlإرسال طلبات HTTP من سطر الأوامر
Postmanاختبار APIs
ffuf / dirsearchاكتشاف Endpoints المخفية
sqlmapاختبار ثغرات SQL Injection تلقائياً

10. المصادر والمراجع

Backlinks