الـ HTTP Protocol — إزاي المتصفح والسيرفر بيتكلموا مع بعض

ليه أصلاً احنا محتاجين بروتوكول زي ده؟

تخيل معايا إن المتصفح والسيرفر عبارة عن شخصين بيتكلموا مع بعض على التليفون، بس المشكلة إنهم مش بيتكلموا بنفس اللغة أو نفس الأسلوب. لازم يكون فيه “اتفاقية” واضحة بينهم: إزاي أطلب حاجة؟ إزاي ترد عليّا؟ إيه شكل الرسالة؟ الاتفاقية دي هي الـ HTTP، اختصار لـ HyperText Transfer Protocol.

الـ HTTP هو البروتوكول اللي بينقل البيانات بين المتصفح (الـ Client) والسيرفر بطريقة غير مشفرة — يعني أي حد عنده إمكانية إنه يشوف الترافيك بينك وبين السيرفر (زي هكر على شبكة WiFi عامة) يقدر يقرا كل حاجة بتتبعت: اليوزرنيم، الباسورد، حتى الكوكيز. المشكلة دي بالظبط هي اللي فتحت الباب لظهور الـ HTTPS، اللي هو نفس الـ HTTP بس متلبس طبقة تشفير اسمها SSL/TLS فوقيه، عشان محدش يقدر يقرا البيانات وهي ماشية.

الـ URL — العنوان اللي بتطلب بيه أي حاجة

قبل ما نتكلم عن الطلب نفسه، لازم نفهم شكل الـ URL (Uniform Resource Locator)، لأنه هو اللي بيوصفلك كل التفاصيل اللي هتحتاجها عشان توصل لمورد معين على الإنترنت.

خد المثال ده وشوف كل جزء بيعمل إيه:

https://user:pass@example.com:443/path/to/page?search=term#section
الجزء الوظيفة
scheme (https) البروتوكول المستخدم
user:pass بيانات مصادقة (نادراً ما تُستخدم في المتصفحات الحديثة)
host (example.com) اسم الدومين أو IP السيرفر
port (443) رقم البورت (443 لـ HTTPS، 80 لـ HTTP افتراضيًا)
path (/path/to/page) مسار المورد على السيرفر
query string (?search=term) باراميترات بتتبعت للسيرفر
fragment (#section) جزء داخل الصفحة نفسها، بيتفسّر في المتصفح فقط ومبيتبعتش للسيرفر أصلاً

لازم تلاحظ نقطة مهمة هنا: الـ fragment (اللي بعد الـ #) مبيتبعتش للسيرفر خالص — ده بيتعامل معاه الـ JavaScript في المتصفح بس. النقطة دي بتفتح باب لثغرات زي DOM-based XSS، لأن أي كود بيقرا من الـ location.hash بيكون بيتعامل مع بيانات مبتمرش على أي فحص من السيرفر.

تركيبة الطلب (Request) — إزاي المتصفح بيسأل السيرفر

لما المتصفح بيبعت طلب، الطلب ده بيتكوّن من 3 أجزاء أساسية، وكل جزء منهم هو نقطة اهتمام مختلفة بالنسبالك كـ pentester:

  1. السطر الأول (Request Line): فيه الـ Method، الـ Path، والـ HTTP version.
  2. الـ Headers: معلومات إضافية عن الطلب.
  3. الـ Body: البيانات الفعلية (موجودة بس في methods زي POST/PUT/PATCH).
POST /login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123

username=islam&password=secret

الـ HTTP Methods — كل Method ليها استخدام مختلف، وده بيفرق أمنيًا

Method الوظيفة ملاحظة أمنية
GET جلب بيانات، مفروض ميغيرش حالة السيرفر لو GET بيغيّر بيانات (زي حذف يوزر)، ده design flaw بيفتح باب لـ CSRF أسهل
POST إرسال بيانات وإنشاء موارد البيانات في الـ body، مش في الـ URL، فمابتتسجلش في server logs زي الـ GET
PUT تحديث مورد بالكامل لو مسموح بيه من غير auth، ممكن يبقى upload primitive خطير
PATCH تحديث جزئي لمورد نفس ملاحظات PUT
DELETE حذف مورد لو متاح من غير تحقق صلاحيات، دي IDOR/Broken Access Control واضحة

الـ Response — إزاي السيرفر بيرد عليك

السيرفر بيرد بنفس التركيبة: Status Code, Headers, Body.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Set-Cookie: session=xyz789; HttpOnly; Secure

<html>...</html>

أشهر الـ Status Codes اللي هتقابلها

  • 200 OK — الطلب تم بنجاح، والبيانات المطلوبة راجعة في الـ Response.
  • 201 Created — الطلب نجح وتم إنشاء مورد جديد بنجاح (زي إنشاء حساب جديد).
  • 301 Moved Permanently — المورد تم نقله نهائيًا لرابط تاني (مهم في الـ Redirection Tracking).
  • 302 Found / Temporary Redirect — إعادة توجيه مؤقتة (مفيد لو بتدور على Open Redirect vulnerabilities).
  • 400 Bad Request — الطلب فيه مشكلة في الصياغة أو Parameter مش صح، والسيرفر مش قادر يفهمه.
  • 401 Unauthorized — محتاج تعمل Authentication الأول (مش مسجل دخول أو الـ Token مش مظبوط).
  • 403 Forbidden — مسجل دخول بس مش مسموحلك توصل للمورد ده (مهم جدًا: الفرق بين 403 و401 بيدّيك معلومة عن الـ Access Control logic زي الـ IDOR/BBA).
  • 404 Not Found — المورد مش موجود على السيرفر (بيساعدك تفهم الـ Directory Enumeration).
  • 405 Method Not Allowed — الـ HTTP Method اللي استخدمته (زي POST بدل GET) مش مسموح بيه على الـ Endpoint ده.
  • 422 Unprocessable Entity — الصيغة صح بس البيانات جواه مش قابلة للتعامل (مفيد في الـ Input Validation testing).
  • 429 Too Many Requests — تعديت حد الطلبات المسموح بيه (Rate Limiting enabled).
  • 500 Internal Server Error — خطأ في السيرفر، وده غالبًا بيدّي معلومات قيّمة لو الـ Error Message مطوّل (Stack Trace Disclosure).
  • 502 Bad Gateway — خطأ في الربط بين السيرفرات (زي مشكلة في الـ Reverse Proxy أو الـ Load Balancer).
  • 503 Service Unavailable — السيرفر مؤقتًا مش قادر يتعامل مع الطلب بسبب الصيانة أو الضغط العالي.

الـ Headers

Request Headers

  • Host: اسم الدومين المطلوب — مهم جدًا في هجمات زي Host Header Injection وPassword Reset Poisoning، لأن بعض التطبيقات بتستخدم قيمة الـ Host header في بناء لينكات زي “reset password” بدون تحقق، فلو غيّرته لدومين بتاعك، ممكن تخلي التوكن الحساس يتبعت لسيرفرك انت.
  • User-Agent: بيوصف المتصفح/العميل — أحيانًا بيتفحص من السيرفر عشان يمنع bots، وده ممكن يتجاوز بسهولة بتغييره.
  • Accept: أنواع المحتوى اللي العميل يقبلها.
  • Authorization: بيانات المصادقة (Basic Auth أو Bearer Token).
  • Cookie: الكوكيز اللي بتتبعت مع الطلب.

Response Headers

  • Set-Cookie: بيحدد كوكيز جديدة (وهنا بيبان لو الـ Cookie ناقصها Flags زي HttpOnly أو Secure).
  • Content-Security-Policy: بيتحكم في مصادر الـ scripts/styles المسموح تحميلها — ضعف فيه أو غيابه بيفتح الباب لـ XSS impact أعلى.
  • X-Frame-Options: لو غايب، الموقع ممكن يتحط جوا <iframe> وتحصل Clickjacking.
  • Location: بيُستخدم في الـ Redirects — لو السيرفر بيبني القيمة دي من input المستخدم من غير تحقق، دي Open Redirect.