إعادة التوجيه في HTTP

لماذا يهم

تقع إعادة التوجيه على مسارات حرجة: الانتقال من HTTP إلى HTTPS، والروابط القديمة بعد إعادة التصميم، وتسجيل الدخول والخروج، والعودة من الدفع، وتغيير إصدار الواجهة البرمجية. وعندما تخطئ تكون الأعراض محيّرة: بيانات نموذج تضيع لأن POST صار GET، وصفحة تعيد التوجيه حتى يستسلم المتصفح، وروابط قديمة تنتهي عند 404، أو إعادة توجيه دائمة خاطئة يظل المتصفح يتبعها بعد الإصلاح لأنه خزّنها مؤقتاً.

وإعادة التوجيه موضوع أمني أيضاً: فالتطبيق الذي يعيد التوجيه إلى أي عنوان يحمله أحد المعاملات يتيح لأي شخص أن يبني رابطاً على نطاقك الموثوق ينتهي بصفحة تصيّد احتيالي (Phishing). ولأن المتصفح يتبع إعادة التوجيه بصمت، تبقى هذه العيوب خفية ما لم ينظر المختبِر إلى كل قفزة.

خمسة رموز وسؤالان

يعرّف المعيار RFC 9110 رموز إعادة التوجيه. فالدائم (301 و308) يعني أن للمورد عنواناً دائماً جديداً ينبغي أن تستخدمه كل الإشارات اللاحقة إليه: فتحدّث محركات البحث وبرامج الزحف الأخرى روابطها إليه، ويجوز لذاكرات التخزين المؤقت أن تخزّن إعادة التوجيه حتى دون ترويسات تخزين مؤقت. والمؤقت (302 و307) يعني أن العنوان الأصلي يبقى صالحاً. أما 303 فليس هذا ولا ذاك: إنه يشير إلى مورد آخر يحمل جواب هذا الطلب. ولا تُخزَّن الرموز المؤقتة والرمز 303 مؤقتاً إلا إذا سمحت بذلك ترويسات التخزين المؤقت.

وفي ما يخص الطريقة، يذكر RFC 9110 أنه لأسباب تاريخية يجوز للعميل أن يغيّر POST إلى GET عندما يتبع 301 أو 302، والمتصفحات تفعل ذلك وفق معيار Fetch، فتُسقط جسم الطلب. ويمنع الرمزان 307 و308 ذلك: يجب على العميل أن يكرر الطريقة نفسها بالجسم نفسه.

• 301 Moved Permanently: دائم؛ وقد يصير POST طلب GET. للصفحات التي انتقلت نهائياً.
• 302 Found: مؤقت؛ وقد يصير POST طلب GET. لتحويلة قصيرة، مثل التحويل إلى صفحة تسجيل الدخول.
• 303 See Other: الطلب التالي GET (ويبقى HEAD طلب HEAD). لصفحة النتيجة بعد إرسال نموذج بطريقة POST (نمط Post/Redirect/Get)، حتى لا يعيد تحديث الصفحة إرسال النموذج.
• 307 Temporary Redirect: مؤقت؛ وتبقى الطريقة والجسم كما هما. لانتقال مؤقت لنقطة نهاية تستقبل POST.
• 308 Permanent Redirect: دائم؛ وتبقى الطريقة والجسم كما هما. لنقطة نهاية في واجهة برمجية انتقلت نهائياً.
• 304 Not Modified من الفئة 3xx أيضاً، لكنه لا يرسل العميل إلى عنوان جديد: لا يحمل Location، بل يطلب من العميل أن يعيد استخدام نسخته المخزّنة بعد طلب مشروط (ويسمّيه RFC 9110 إعادة توجيه إلى نتيجة مخزّنة سابقاً)، كما في درس التخزين المؤقت.

جرّبها: مرجع رموز حالة HTTP

مثال تطبيقي: طلب شراء ضاع في إعادة توجيه

تعرّفت إلى هذا العيب في الصف R8 من تمرين رموز حالة HTTP: اتبع التطبيق إعادة التوجيه 301 بطلب GET، وانتهت السلسلة باستجابة 200 مضلِّلة. وإليك كيف يظهر في المتصفح، قفزةً بعد قفزة. ينقل متجر إلكتروني واجهة API الخاصة بالطلبات من /api/v1/orders إلى /api/v2/orders، ويضيف 301 من المسار القديم من أجل الصفحات التي ما زالت مفتوحة في متصفحات العملاء. ثم يضغط هؤلاء العملاء «إتمام الطلب» فيرون «حدث خطأ ما». وفي أدوات المطوّرين (DevTools)، مع تفعيل «Preserve log»، تُظهر لوحة الشبكة (Network) طلبين لنقرة واحدة (السجل في آخر هذا القسم).

اتبع المتصفح إعادة التوجيه 301 كما يقتضي معيار Fetch لطلب POST: أرسل GET بلا جسم، ولم ترَ الصفحة إلا الاستجابة الأخيرة 405. يذكر تقرير الخطأ القفزتين ويسمّي السبب المرجّح: 301 بدلاً من 308. وبعد الإصلاح يتحقق اختبار التأكيد من أن POST يصل إلى v2 بجسمه، ويعيد 201 Created، وينشئ طلباً واحداً بالضبط.

وخارج المتصفح يُظهر الأمر curl -i استجابة إعادة التوجيه نفسها، لأن curl لا يتبع إعادة التوجيه إلا مع -L؛ وتعرض أداة Redirect Checker كل قفزة لعنوان عام، وتطلب كل قفزة بطريقة GET. وفي كل إعادة توجيه تحقّق مما يلي:

• الحالة: الرمز الذي يحتاجه المتطلب بالضبط، لا أي رمز من الفئة 3xx.
• Location: الوجهة الصحيحة، على https، مع الاحتفاظ بالمسار وسلسلة الاستعلام (Query String) حين يلزم (/old?id=7 ← /new?id=7).
• القفزات: أقل عدد ممكن، والأفضل قفزة واحدة.
• النهاية: الصفحة أو المورد المتوقع، لا 404 ولا صفحة تسجيل الدخول.
• الطريقة والجسم: ما الذي وصل فعلاً بعد إعادة توجيه طلب POST.

--- request 1 (the click) ---
POST /api/v1/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{"sku":"A-100","qty":2}

HTTP/1.1 301 Moved Permanently
Location: /api/v2/orders

--- request 2 (sent by the browser: method changed, body dropped) ---
GET /api/v2/orders HTTP/1.1
Host: shop.example.com

HTTP/1.1 405 Method Not Allowed
Allow: POST

جرّبها: مولّد أوامر cURL جرّبها: محلّل ترويسات HTTP

سلاسل إعادة التوجيه وحلقاتها

سلسلة إعادة التوجيه (Redirect Chain) عدة عمليات إعادة توجيه متتالية: http://example.com/shoes ← https://example.com/shoes ← https://www.example.com/shoes ← https://www.example.com/shoes/. وكل قفزة رحلة ذهاب وإياب إضافية، وقاعدة أخرى قد تنكسر. وتنمو السلاسل طبقة فوق طبقة: موازن الأحمال يحوّل إلى HTTPS، وخادم الويب يضيف www، والتطبيق يضيف الشرطة المائلة الختامية. والحل أن يُرسَل كل عنوان قديم مباشرةً إلى عنوانه النهائي.

حلقة إعادة التوجيه (Redirect Loop) سلسلة لا تنتهي. وتستسلم المتصفحات (يتوقف معيار Fetch عند 20 إعادة توجيه) وتعرض خطأ مثل ERR_TOO_MANY_REDIRECTS في Chrome. وتنشأ الحلقات من مكوّنين لا يتفقان:

• وكيل (Proxy) أو موازن أحمال يستقبل الطلب عبر HTTPS لكنه يمرّره إلى التطبيق عبر HTTP العادي؛ والتطبيق، الذي يفرض HTTPS هو أيضاً، يرى HTTP فيعيد التوجيه إلى عنوان https نفسه من جديد، في كل طلب.
• خادم الويب يضيف الشرطة المائلة الختامية والتطبيق يحذفها.
• صفحة تسجيل الدخول ترسل المستخدم المسجَّل إلى لوحة التحكم، ولوحة التحكم تعيد من تعدّه غير مسجَّل إلى صفحة الدخول، مثلاً لأن ملف تعريف الارتباط الخاص بالجلسة ضُبط لنطاق أو مسار آخر.

جرّبها: فاحص إعادة التوجيه

خطر إعادة التوجيه المفتوحة

تعيد تطبيقات كثيرة التوجيه إلى عنوان مأخوذ من الطلب: بعد تسجيل الدخول يعيد ?next=/orders/15 المستخدم إلى الصفحة التي أرادها. فإذا قُبلت أي قيمة، أرسل https://shop.example.com/login?next=https://example.org/ المستخدمين من نطاقك الموثوق إلى أي موقع. هذه إعادة توجيه مفتوحة (Open Redirect)، وتُسمّى أيضاً إعادة توجيه غير متحقَّق منها (Unvalidated Redirect)، ويستغلها المهاجمون في التصيّد الاحتيالي لأن الرابط يبدأ بنطاقك الحقيقي.

توصي ورقة OWASP الإرشادية الخاصة بإعادة التوجيه غير المتحقَّق منها بتجنّب الوجهات التي يقدّمها المستخدم، أو ربط معرّف قصير بعنوان محفوظ على الخادم، أو مطابقة الوجهة مع قائمة سماح (Allow-list). لا تختبر إلا أنظمة تملكها أو لديك إذن مكتوب باختبارها، في بيئة الاختبار، مع النطاق المحجوز example.org وجهةً خارجية. جرّب كل قيمة مما يلي في المعامل؛ والنتيجة المتوقعة دائماً صفحة من موقعك أو وجهة افتراضية آمنة.

• عنوان مطلق: https://example.org/.
• عنوان نسبي للبروتوكول، يعدّه المتصفح خارجياً: //example.org/.
• عنوان مشابه يبدأ بنطاقك: https://shop.example.com.example.org/.
• نطاقك بوصفه معلومات مستخدم قبل @، ويظل يقود إلى example.org: https://shop.example.com@example.org/.
• أماكن أخرى: معاملات مثل returnUrl أو redirect، وصفحات تسجيل الخروج والعودة من الدفع.

جرّبها: محلّل عناوين URL

أسئلة شائعة

المراجع

• RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.
• Fetch StandardWHATWGيعرّف CORS: طلبات التحقق المسبق وترويسات Access-Control-* والاستجابات التي يسمح المتصفح للصفحة برؤيتها.
• OWASP Cheat Sheet Series: Unvalidated Redirects and ForwardsOWASP Foundationإعادة التوجيه المفتوحة: لماذا يجب ألا تأتي وجهة إعادة التوجيه من مدخلات المستخدم، والدفاعات — ربط المعرّفات بالروابط في الخادم، وقوائم السماح، وصفحات التأكيد.
• Redirections in HTTP — MDNMDN Web Docs (Mozilla)إعادة التوجيه في HTTP: رموز الحالة 3xx مع ترويسة Location، والدائمة (301 و308) مقابل المؤقتة (302 و303 و307)، وكيف تنشأ حلقات إعادة التوجيه.