إعادة توجيه عنوان URL

📅 آخر تحديث: ١٨ يوليو ٢٠٢٦
✍️ نُشر في: ١٨ يوليو ٢٠٢٦
الموسوعة الحرة

إعادة توجيه عنوان URL ، أو ما يُعرف أيضًا بإعادة توجيه عنوان URL ، هي تقنية في شبكة الإنترنت العالمية تتيح الوصول إلى صفحة ويب عبر أكثر من عنوان URL . فعندما يحاول متصفح الويب فتح عنوان URL تمت إعادة توجيهه، يتم فتح صفحة بعنوان URL مختلف. وبالمثل، فإن إعادة توجيه النطاق أو إعادة توجيه النطاق هي عملية إعادة توجيه جميع الصفحات ضمن نطاق URL إلى نطاق مختلف، كما هو الحال عند إعادة توجيه wikipedia.com و wikipedia.net تلقائيًا إلى wikipedia.org .

يتم إعادة توجيه عنوان URL لأسباب مختلفة:

  • لتقصير الروابط ؛
  • لمنع الروابط المعطلة عند نقل صفحات الويب؛
  • للسماح لأسماء نطاقات متعددة تابعة لنفس المالك بالإشارة إلى موقع ويب واحد ؛
  • لتوجيه عملية التنقل داخل وخارج موقع الويب؛
  • لحماية الخصوصية (مثل إعادة توجيه روابط يوتيوب وتويتر إلى Invidious و Nitter على التوالي أو لتحويل روابط AMP إلى روابط عادية)؛ و
  • لأغراض عدائية مثل هجمات التصيد الاحتيالي أو توزيع البرامج الضارة.

الأغراض

هناك عدة أسباب لاستخدام إعادة توجيه عنوان URL:

فرض استخدام HTTPS

قد يكون من الممكن الوصول إلى موقع ويب عبر كل من مخطط URI الآمن HTTPS و HTTP العادي (URI غير آمن يبدأ بـ "http://").

إذا قام المستخدم بكتابة عنوان URI أو النقر على رابط يشير إلى النسخة غير الآمنة، فسيعيد المتصفح توجيهه تلقائيًا إلى النسخة الآمنة في حالة وجود موقع الويب في قائمة التحميل المسبق HSTS المرفقة مع التطبيق أو إذا كان المستخدم قد زار المصدر بالفعل في الماضي.

وإلا فسيتم الاتصال بالموقع الإلكتروني عبر بروتوكول HTTP. وقد يقرر مشغل الموقع تلبية هذه الطلبات عن طريق إعادة توجيه المتصفح إلى بروتوكول HTTPS بدلاً من ذلك، ومن المأمول أن يؤدي ذلك أيضاً إلى تهيئة بروتوكول HSTS لعمليات الوصول المستقبلية.

أسماء نطاقات مشابهة

قد يُخطئ المستخدم في كتابة عنوان الموقع الإلكتروني. غالبًا ما تقوم المؤسسات بتسجيل هذه النطاقات المكتوبة بشكل خاطئ وإعادة توجيهها إلى الموقع المقصود. تُستخدم هذه التقنية عادةً "لحجز" نطاقات المستوى الأعلى الأخرى (TLD) التي تحمل نفس الاسم، أو لتسهيل وصول مواقع ".edu" أو ".net" إلى المستخدمين الذين يكتبون ".com".

نقل الصفحات إلى نطاق جديد

قد يتم إعادة توجيه صفحات الويب إلى نطاق جديد لثلاثة أسباب:

  • قد يرغب موقع ما، أو يحتاج، إلى تغيير اسم نطاقه؛
  • قد يقوم المؤلف بنقل صفحاته الفردية إلى نطاق جديد؛
  • قد يندمج موقعان إلكترونيان.

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

تحتفظ سجلات الوصول لمعظم خوادم الويب بمعلومات تفصيلية حول مصادر زيارات المستخدمين وكيفية تصفحهم للموقع المُستضاف. مع ذلك، لا تُسجل هذه السجلات الروابط التي غادر منها المستخدمون. والسبب في ذلك هو أن متصفح الزائر لا يحتاج إلى التواصل مع الخادم الأصلي عند النقر على رابط خارجي. يمكن جمع هذه المعلومات بعدة طرق، إحداها إعادة توجيه عنوان URL. فبدلاً من إرسال الزائر مباشرةً إلى الموقع الآخر، يمكن للروابط الموجودة على الموقع أن تُوجه إلى عنوان URL ضمن نطاق الموقع الأصلي، والذي يُعيد التوجيه تلقائيًا إلى الوجهة المقصودة. لكن لهذه التقنية عيب يتمثل في التأخير الناتج عن الطلب الإضافي المُرسل إلى خادم الموقع الأصلي. ولأن هذا الطلب الإضافي سيترك أثرًا في سجل الخادم، كاشفًا عن الرابط الذي تم اتباعه تحديدًا، فقد يُشكل ذلك أيضًا انتهاكًا للخصوصية. [ 1 ] تستخدم بعض مواقع الشركات التقنية نفسها لتوضيح أن المحتوى اللاحق موجود على موقع آخر، وبالتالي ليس بالضرورة تابعًا للشركة. في مثل هذه الحالات، يتسبب عرض التحذير في تأخير إضافي.

أسماء مستعارة مختصرة لعناوين URL الطويلة

غالبًا ما تتضمن عناوين URL لتطبيقات الويب سمات وصفية مطولة تمثل تسلسل البيانات، وبنية الأوامر، ومسارات المعاملات، ومعلومات الجلسة. ينتج عن هذه الممارسة عنوان URL غير جذاب بصريًا ويصعب تذكره، وقد لا يتناسب مع قيود حجم مواقع التدوين المصغر . توفر خدمات اختصار عناوين URL حلاً لهذه المشكلة عن طريق إعادة توجيه المستخدم من عنوان URL أقصر إلى عنوان أطول. [ 1 ]

أسماء مستعارة ذات معنى ودائمة لعناوين URL الطويلة أو المتغيرة

أحيانًا يتغير عنوان URL للصفحة حتى وإن بقي محتواها كما هو. لذا، يُمكن أن يُساعد إعادة توجيه عنوان URL المستخدمين الذين لديهم إشارات مرجعية. ويتم ذلك بشكل روتيني على ويكيبيديا عند تغيير اسم أي صفحة.

إرسال/إعادة توجيه/استرجاع

نمط Post/Redirect/Get (PRG) هو نمط تصميم لتطوير الويب يمنع بعض عمليات إرسال النماذج المكررة إذا نقر المستخدم على زر التحديث بعد إرسال النموذج، مما يخلق واجهة أكثر سهولة لوكلاء المستخدم (المستخدمين).

استهداف الأجهزة والاستهداف الجغرافي

يمكن استخدام عمليات إعادة التوجيه بفعالية لأغراض الاستهداف، مثل الاستهداف الجغرافي . وقد ازداد استهداف الأجهزة أهميةً مع تزايد استخدام تطبيقات الجوال. هناك طريقتان لخدمة مستخدمي الجوال: إما جعل الموقع الإلكتروني متجاوبًا مع مختلف الأجهزة، أو إعادة التوجيه إلى نسخة الجوال. في حال توفير نسخة الجوال، سيتم توجيه المستخدمين الذين يستخدمون تطبيقات الجوال تلقائيًا إلى المحتوى المخصص للجوال. ولاستهداف الأجهزة، تُستخدم عمليات إعادة التوجيه من جانب العميل أو عمليات إعادة التوجيه من جانب الخادم غير القابلة للتخزين المؤقت. أما الاستهداف الجغرافي، فهو أسلوب لعرض محتوى مُخصّص محليًا، وإعادة توجيه المستخدم تلقائيًا إلى نسخة مُخصّصة محليًا من عنوان URL المطلوب. يُفيد هذا الأسلوب المواقع الإلكترونية التي تستهدف جمهورًا في أكثر من موقع و/أو لغة. عادةً ما تُستخدم عمليات إعادة التوجيه من جانب الخادم للاستهداف الجغرافي، ولكن قد تكون عمليات إعادة التوجيه من جانب العميل خيارًا متاحًا أيضًا، حسب المتطلبات. [ 2 ]

التلاعب بمحركات البحث

استُخدمت عمليات إعادة التوجيه للتلاعب بمحركات البحث لأغراض غير أخلاقية، مثل اختطاف عناوين URL . يهدف هذا الأسلوب إلى توجيه حركة البحث إلى صفحات هبوط لا تتمتع بترتيب كافٍ في نتائج البحث، أو لا ترتبط بموضوع البحث المستهدف إلا بشكل طفيف أو لا ترتبط به إطلاقًا. يتطلب هذا الأسلوب تصنيفًا لمجموعة من الكلمات المفتاحية، مع عدد من عناوين URL التي تستخدم عمليات إعادة توجيه خبيثة لإعادة توجيه الباحث إلى الصفحة المستهدفة. وقد انتشر هذا الأسلوب مجددًا مع ظهور الأجهزة المحمولة واستهدافها. يُعد اختطاف عناوين URL تقنية لإعادة التوجيه خارج النطاق [ 3 ] تستغل آلية تعامل محركات البحث مع عمليات إعادة التوجيه المؤقتة. عند مواجهة عملية إعادة توجيه مؤقتة، يتعين على محركات البحث تحديد ما إذا كانت ستُسند قيمة الترتيب إلى عنوان URL الذي بدأ عملية إعادة التوجيه أو إلى عنوان URL المستهدف. قد يُحتفظ بعنوان URL الذي بدأ عملية إعادة التوجيه ليظهر في نتائج البحث، نظرًا لأن عملية إعادة التوجيه تُشير إلى طبيعتها المؤقتة. في ظروف معينة، كان من الممكن استغلال هذا السلوك عن طريق تطبيق عمليات إعادة توجيه مؤقتة على عناوين URL ذات ترتيب عالٍ، مما يؤدي إلى استبدال عنوان URL الأصلي في نتائج البحث بعنوان URL الذي بدأ عملية إعادة التوجيه، وبالتالي "سرقة" الترتيب. عادةً ما كانت هذه الطريقة تُدمج مع عمليات إعادة توجيه خبيثة لإعادة توجيه مسار المستخدم من نتائج البحث إلى صفحة مستهدفة. وقد طورت محركات البحث تقنيات فعالة لكشف هذه الأنواع من الأساليب التلاعبية. وعادةً ما تفرض محركات البحث الرئيسية عقوبات صارمة على ترتيب المواقع التي يتم ضبطها وهي تستخدم تقنيات كهذه. [ 4 ]

التلاعب بالزوار

يُستخدم إعادة توجيه عناوين المواقع الإلكترونية أحيانًا كجزء من هجمات التصيد الاحتيالي التي تُضلل الزوار بشأن الموقع الذي يزورونه. [ 5 ] ولأن المتصفحات الحديثة تُظهر دائمًا عنوان الموقع الحقيقي في شريط العناوين، فإن هذا الخطر يقل. مع ذلك، قد تُوجه عمليات إعادة التوجيه المستخدمين إلى مواقع أخرى قد تُحاول مهاجمتهم بطرق مختلفة. على سبيل المثال، قد تُوجه عملية إعادة التوجيه المستخدم إلى موقع يُحاول خداعه لتحميل برنامج مكافحة فيروسات وتثبيت برنامج تجسس خبيث بدلاً منه.

إزالة referrerالمعلومات

عند النقر على رابط، يرسل المتصفح في طلب HTTP حقلاً يُسمى "referer" يُشير إلى مصدر الرابط. يُملأ هذا الحقل بعنوان URL للصفحة الحالية، ويُسجل في سجلات الخادم الذي يُقدم الرابط الخارجي. ولأن الصفحات الحساسة قد تحتوي على عناوين URL حساسة (على سبيل المثال، https://company.com/plans-for-the-next-release-of-our-product)، فمن غير المرغوب فيه أن referrerيخرج عنوان URL من نطاق المؤسسة. يمكن تضمين صفحة إعادة توجيه تُخفي عنوان URL المُحيل في جميع عناوين URL الخارجية، لتحويله مثلاً https://externalsite.com/pageإلى https://redirect.company.com/https://externalsite.com/page. تُزيل هذه التقنية أيضاً معلومات حساسة أخرى محتملة من عنوان URL المُحيل، مثل مُعرّف الجلسة ، وتُقلل من احتمالية التصيّد الاحتيالي من خلال الإشارة إلى المستخدم النهائي بأنه قد مرّ عبر بوابة واضحة إلى موقع آخر.

تطبيق

تؤدي أنواع مختلفة من استجابات المتصفح إلى إعادة التوجيه. وتختلف هذه الاستجابات فيما إذا كانت تؤثر على رؤوس HTTP أو محتوى HTML. وتعتمد التقنيات المستخدمة عادةً على دور الشخص الذي يُنفذها ومدى وصوله إلى أجزاء النظام المختلفة. على سبيل المثال، قد يستخدم مطور مواقع الويب الذي لا يملك صلاحية التحكم في الرؤوس علامة Refresh meta، بينما من المرجح أن يستخدم مسؤول خادم الويب الذي يُعيد توجيه جميع صفحات الموقع إعدادات الخادم.

إعادة توجيه يدوية

أبسط طريقة هي مطالبة الزائر باتباع رابط إلى الصفحة الجديدة، وعادةً ما يتم ذلك باستخدام رابط HTML مثل:

يرجى اتباع <a href="https://www.uba8d1406.com/"> هذا الرابط </a> .​ ​​​​

تُستخدم هذه الطريقة غالبًا كخيار احتياطي  - إذا كان المتصفح لا يدعم إعادة التوجيه التلقائي، فلا يزال بإمكان الزائر الوصول إلى المستند المستهدف عن طريق اتباع الرابط.

رموز حالة HTTP 3xx

في بروتوكول HTTP المستخدم في شبكة الإنترنت العالمية ، تُعرَّف إعادة التوجيه بأنها استجابة برمز حالة يبدأ بالرقم 3 ، وتؤدي إلى عرض المتصفح لصفحة مختلفة. عند مواجهة العميل لإعادة توجيه، عليه اتخاذ عدة قرارات بشأن كيفية التعامل معها. يستخدم العملاء رموز حالة مختلفة لفهم الغرض من إعادة التوجيه، وكيفية إدارة التخزين المؤقت، وطريقة الطلب المناسبة للطلب اللاحق.

يحدد بروتوكول HTTP/1.1 عدة رموز حالة لإعادة التوجيه ( RFC 7231 ):

  • 300 خيار متعدد (على سبيل المثال، تقديم لغات مختلفة)
  • تم نقل 301 بشكل دائم (إعادة التوجيه بشكل دائم من عنوان URL إلى آخر مع نقل قيمة الرابط إلى الصفحة المعاد توجيهها)
  • تم العثور على 302 (كانت في الأصل "إعادة توجيه مؤقتة" في HTTP/1.0 وكانت تستخدم بشكل شائع لبرامج CGI النصية؛ تم استبدالها بـ 303 و 307 في HTTP/1.1 ولكن تم الاحتفاظ بها من أجل التوافق مع الإصدارات السابقة)
  • 303 انظر أخرى (يفرض طلب GET إلى عنوان URL الجديد حتى لو كان الطلب الأصلي من نوع POST)
  • 305 استخدام الوكيل (يشير إلى أن المورد المطلوب من قبل العميل متاح فقط من خلال وكيل)
  • إعادة توجيه مؤقتة 307 (توفر عنوان URL جديدًا للمتصفح لإعادة إرسال طلب GET أو POST)
  • إعادة توجيه دائمة 308 (توفر عنوان URL جديدًا للمتصفح لإعادة إرسال طلب GET أو POST)

رموز الحالة 304 لم يتم تعديلها و 305 استخدام وكيل ليست عمليات إعادة توجيه.

رموز وخصائص حالة إعادة التوجيه [ 6 ]
رمز حالة HTTPإصدار HTTPمؤقت / دائمقابلة للتخزين المؤقتطريقة الطلب: طلب لاحق
301HTTP/1.0دائمنعمقد تتغير أوامر GET / POST
302HTTP/1.0مؤقتليس بشكل افتراضيقد تتغير أوامر GET / POST
303HTTP/1.1مؤقتأبداًاحصل دائمًا
307HTTP/1.1مؤقتليس بشكل افتراضيقد لا يتغير
308HTTP/1.1دائمافتراضياقد لا يتغير

تتطلب جميع رموز الحالة هذه تحديد عنوان URL لوجهة إعادة التوجيه في ترويسة "Location:" ضمن استجابة HTTP. عادةً ما تعرض خيارات 300 المتعددة جميع الخيارات في نص الرسالة، وتُظهر الخيار الافتراضي في ترويسة "Location:".

مثال على استجابة HTTP لإعادة توجيه 301

تبدو استجابة HTTP مع إعادة التوجيه 301 "تم النقل بشكل دائم" كما يلي:

HTTP / 1.1 301 تم النقل بشكل دائم الموقع : https://www.example.org/ نوع المحتوى : نص/html طول المحتوى : 174<html> <head> <title> تم النقل < / title > </head> <body>​​​​​​​​ =تم النقل= <p> تم نقل هذه الصفحة إلى <a href="https://www.example.org/"> https://www.example.org/ </a> . </p> </body> </html>​​​​​​​​​​​

استخدام البرمجة النصية من جانب الخادم لإعادة التوجيه

لا يستطيع مطورو مواقع الويب الذين ينتجون محتوى HTML عادةً إنشاء عمليات إعادة توجيه باستخدام رؤوس HTTP، حيث يتم إنشاؤها تلقائيًا بواسطة برنامج خادم الويب عند عرض ملف HTML. وينطبق الأمر نفسه عادةً على المبرمجين الذين يكتبون نصوص CGI، على الرغم من أن بعض الخوادم تسمح للنصوص بإضافة رؤوس مخصصة (مثلًا عن طريق تفعيل "non-parsed-headers"). تُصدر العديد من خوادم الويب رمز حالة 3xx إذا أخرج نص برمجي سطر رأس "Location:". على سبيل المثال، في PHP ، يمكن استخدام الدالة "header".

header ( 'HTTP/1.1 301 Moved Permanently' ); header ( 'Location: https://www.example.com/' ); exit ();

قد يلزم إضافة المزيد من الترويسات لمنع التخزين المؤقت. [ 7 ] يجب على المبرمج التأكد من إخراج الترويسات قبل نص الطلب. قد لا يتوافق هذا بسهولة مع التدفق الطبيعي للتحكم في الكود. وللمساعدة في ذلك، يمكن لبعض أطر عمل إنشاء المحتوى من جانب الخادم تخزين بيانات نص الطلب مؤقتًا. في لغة برمجة ASP ، يمكن تحقيق ذلك أيضًا باستخدام response.buffer=trueHTTP /1.1 الذي يسمح إما بمرجع URI نسبي أو مرجع URI مطلق. [ 8 ] إذا كان مرجع URI نسبيًا، يحسب العميل مرجع URI المطلق المطلوب وفقًا للقواعد المحددة في RFC 3986. [ 9 ]response.redirect "https://www.example.com/"

خادم Apache HTTP mod_rewrite

يمكن استخدام إضافة mod_alias في خادم Apache HTTP لإعادة توجيه طلبات معينة. تبدو توجيهات التكوين النموذجية كما يلي :

إعادة توجيه دائمة /oldpage.html https://www.example.com/newpage.html إعادة توجيه 301 /oldpage.html https://www.example.com/newpage.html

للحصول على مرونة أكبر في إعادة كتابة عناوين URL وإعادة التوجيه، يمكن استخدام وحدة mod_rewrite في Apache. على سبيل المثال، لإعادة توجيه الطلبات إلى اسم نطاق أساسي:

RewriteEngine on RewriteCond %{HTTP_HOST} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC] RewriteRule ^(.*)$ https://newsite.example.net/$1 [R=301,L]

يمكن تطبيق هذا التكوين على موقع واحد أو جميع المواقع على الخادم من خلال ملفات تكوين الخادم أو على دليل محتوى واحد من خلال .htaccessملف.

إعادة كتابة nginx

يحتوي Nginx على وحدة إعادة كتابة HTTP مدمجة، [ 10 ] والتي يمكن استخدامها لإجراء معالجة متقدمة لعناوين URL وحتى إنشاء صفحات ويب (باستخدام returnالتوجيه). ومن الأمثلة على هذا الاستخدام المتقدم لوحدة إعادة الكتابة موقع mdoc.su، الذي يُنفذ خدمة تقصير عناوين URL حتمية بالكامل باستخدام لغة تكوين Nginx فقط. [ 11 ] [ 12 ]

/DragonFlyBSD/HAMMER.5على سبيل المثال، إذا ورد طلب ، فسيتم أولاً إعادة توجيهه داخليًا إلى /d/HAMMER.5باستخدام توجيه إعادة الكتابة الأول أدناه (يؤثر فقط على الحالة الداخلية، دون إصدار أي ردود HTTP إلى العميل حتى الآن)، ثم باستخدام توجيه إعادة الكتابة الثاني، سيتم إصدار استجابة HTTP برمز حالة 302 Found إلى العميل لإعادة التوجيه فعليًا إلى برنامج cgi النصي الخارجي لـ web- man : [ 13 ]

location /DragonFly { rewrite ^/DragonFly(BSD)?([,/].*)? $ /d $2 last ; } location /d { set $db "https://leaf.dragonflybsd.org/cgi/web-man?command=" ; set $ds "§ion=" ; rewrite ^/./([^/]+)\.([1-9]) $ $db$1$ds$2 redirect ; }

تحديث علامة Meta وعنوان تحديث HTTP

قدّمت نتسكيب ميزة التحديث التلقائي التي تُحدّث الصفحة تلقائيًا بعد فترة زمنية محددة. يُمكن تحديد عنوان URL جديد لاستبدال صفحة بأخرى. تدعم معظم متصفحات الويب هذه الميزة. [ 14 ] [ 15 ] يؤدي انتهاء المهلة بصفر ثانية إلى إعادة توجيه فورية. يُعامل جوجل هذا كإعادة توجيه دائمة من نوع 301، مما يسمح بنقل ترتيب الصفحة إلى الصفحة المستهدفة. [ 16 ]

هذا مثال على مستند HTML بسيط يستخدم هذه التقنية:

<html> <head> < meta http - equiv = " Refresh " content = " 0 ; url = https : //www.example.com/ " / > </head> <body> <p> يرجى اتباع <a href="https://www.example.com/"> هذا الرابط </a> . </p> </body> </html>​​​​​​​​

يمكن لمطوري المواقع الإلكترونية استخدام هذه التقنية لأن الوسم الوصفي (meta tag) موجود داخل المستند نفسه. يجب وضع الوسم الوصفي في قسم "head" من ملف HTML. يمكن استبدال الرقم "0" في هذا المثال برقم آخر لتحقيق تأخير بنفس عدد الثواني. أما الرابط الموجود في قسم "body" فهو مخصص للمستخدمين الذين لا تدعم متصفحاتهم هذه الميزة.

ويمكن تحقيق نفس التأثير باستخدام refreshرأس HTTP:

HTTP / 1.1 200 OK Refresh : 0; url=https://www.example.com/ Content-Type : text/html Content-Length : 78 يرجى اتباع <a href="https://www.example.com/"> هذا الرابط </a> .​​​​​

يسهل إنشاء هذه الاستجابة بواسطة برامج CGI لأنه لا حاجة لتغيير رمز الحالة الافتراضي.

إليكم برنامج CGI بسيط يقوم بعملية إعادة التوجيه هذه:

# !/usr/bin/env perl print "Refresh: 0; url=https://www.example.com/\r\n" ; print "Content-Type: text/html\r\n" ; print "\r\n" ; print "Please follow <a href=\"https://www.example.com/\">this link</a>!"

ملاحظة: عادةً ما يقوم خادم HTTP بإضافة سطر الحالة ورأس Content-Length تلقائيًا.

لا تشجع منظمة W3C استخدام خاصية التحديث التلقائي (meta refresh)، لأنها لا تنقل أي معلومات إلى المتصفح (أو محرك البحث ) حول المورد الأصلي أو الجديد. كما تحذر إرشادات إمكانية الوصول إلى محتوى الويب (7.4) الصادرة عن W3C [ 17 ] من إنشاء صفحات تُحدَّث تلقائيًا، لأن معظم متصفحات الويب لا تسمح للمستخدم بتعطيل معدل التحديث أو التحكم فيه. ومن بين المقالات التي نشرتها المنظمة حول هذا الموضوع: إرشادات إمكانية الوصول إلى محتوى الويب (1.0): ضمان تحكم المستخدم في تغييرات المحتوى الحساسة للوقت ، واستخدام عمليات إعادة التوجيه القياسية: تجنب تعطيل زر الرجوع! [ 18 ] ، والتقنيات الأساسية لإرشادات إمكانية الوصول إلى محتوى الويب 1.0، القسم 7. [ 19 ]

إعادة توجيه جافا سكريبت

يمكن لـ JavaScript أن يتسبب في إعادة التوجيه عن طريق تعيين window.locationالسمة، على سبيل المثال:

window.location = ' https://www.example.com/ '

عادةً ما يقوم جافا سكريبت بإضافة عنوان URL لموقع إعادة التوجيه إلى سجل المتصفح. قد يتسبب ذلك في حلقات إعادة توجيه متكررة عند ضغط المستخدمين على زر الرجوع. باستخدام الأمر التالي، يمكنك منع هذا السلوك. [ 20 ]

window.location.replace ( ' https://www.example.com/ ' )​​

ومع ذلك، قد يفضل استخدام رؤوس HTTP أو علامة التحديث الوصفية لأسباب أمنية ولأن جافا سكريبت لن يتم تنفيذها بواسطة بعض المتصفحات والعديد من برامج زحف الويب .

إعادة توجيه الإطار

يمكن تحقيق تأثير مختلف قليلاً عن طريق إنشاء إطار مضمن :

< iframe height = " 100 % " width = " 100 % " src = " https://www.example.com/ " > يرجى اتباع <a href="https://www.example.com/"> الرابط </a> . </iframe>

يتمثل أحد الاختلافات الرئيسية عن طرق إعادة التوجيه المذكورة أعلاه في أن المتصفح، عند إعادة التوجيه عبر الإطار، يعرض عنوان URL الخاص بوثيقة الإطار وليس عنوان URL للصفحة المستهدفة في شريط العناوين. قد تُستخدم تقنية التمويه هذه لجعل عنوان URL أكثر سهولة في التذكر للمستخدم، أو لإخفاء موقع تصيد احتيالي كجزء من عملية انتحال هوية موقع الويب . [ 21 ]

قبل HTML5، [ 22 ] كان من الممكن تحقيق نفس التأثير باستخدام إطار HTML يحتوي على الصفحة المستهدفة:

< frameset rows = " 100 % " > < frame src = " https://www.example.com/ " > <noframes> <body> يرجى اتباع <a href="https://www.example.com/"> الرابط </a> . </body> </noframes> </frameset>​​​​​​​​​​​

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

قد يؤدي أحد عمليات إعادة التوجيه إلى آخر ضمن سلسلة إعادة التوجيه. وإذا أدى أحد عمليات إعادة التوجيه إلى آخر، يُعرف ذلك بإعادة التوجيه المزدوج. [ 23 ] على سبيل المثال، يُعاد توجيه عنوان URL " https://wikipedia.com " (مع نطاق "*.com") أولًا إلى https://www.wikipedia.org/ (مع نطاق ينتهي بـ .org )، حيث يمكن للمستخدم الانتقال إلى الموقع الخاص باللغة المطلوبة. هذا أمر لا مفر منه إذا كانت الروابط المختلفة في السلسلة تُخدَم من خوادم مختلفة، مع أنه يُفضَّل تقليله قدر الإمكان عن طريق إعادة كتابة عنوان URL على الخادم قبل إعادته إلى المتصفح كإعادة توجيه.

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

قد يتسبب خطأ ما أحيانًا في إعادة توجيه الصفحة إلى نفسها، ربما عبر صفحات أخرى، مما يؤدي إلى سلسلة لا نهائية من عمليات إعادة التوجيه. ينبغي للمتصفحات التوقف عن إعادة التوجيه بعد عدد معين من عمليات التوجيه وعرض رسالة خطأ.

ينص معيار HTTP/1.1 على ما يلي: [ 24 ]

ينبغي على العميل اكتشاف عمليات إعادة التوجيه الدورية والتدخل فيها (أي حلقات إعادة التوجيه "اللانهائية").

ملاحظة: أوصت نسخة سابقة من هذه المواصفة بحد أقصى خمس عمليات إعادة توجيه ( RFC 2068 ، القسم 10.3). يجب على مطوري المحتوى أن يدركوا أن بعض العملاء قد يطبقون هذا القيد الثابت.

خدمات

توجد خدمات يمكنها إجراء إعادة توجيه عناوين URL عند الطلب، دون الحاجة إلى عمل تقني أو الوصول إلى خادم الويب الذي يستضيف موقعك.

خدمات إعادة توجيه عناوين URL

خدمة إعادة التوجيه هي نظام لإدارة المعلومات، يوفر رابطًا على الإنترنت يُعيد توجيه المستخدمين إلى المحتوى المطلوب. وتتمثل الفائدة الرئيسية للمستخدم في استخدام اسم نطاق يسهل تذكره، وتقليل طول عنوان URL أو عنوان الويب. كما يمكن استخدام رابط إعادة التوجيه كعنوان دائم للمحتوى الذي يتغير خوادمه باستمرار، على غرار نظام أسماء النطاقات ( DNS ). تُستخدم الروابط التشعبية التي تتضمن خدمات إعادة توجيه عناوين URL بكثرة في رسائل البريد الإلكتروني العشوائية (السبام) الموجهة إلى المدونات ومواقع الويكي. لذا، تتمثل إحدى طرق الحد من البريد العشوائي في رفض جميع التعديلات والتعليقات التي تحتوي على روابط تشعبية لخدمات إعادة توجيه عناوين URL المعروفة؛ إلا أن هذا سيؤدي أيضًا إلى حذف التعديلات والتعليقات المشروعة، وقد لا يكون وسيلة فعالة للحد من البريد العشوائي. وقد بدأت خدمات إعادة توجيه عناوين URL مؤخرًا في استخدام تقنية AJAX كطريقة فعالة وسهلة الاستخدام لإنشاء عناوين URL مختصرة. ومن أبرز عيوب بعض خدمات إعادة توجيه عناوين URL استخدام صفحات التأخير، أو الإعلانات القائمة على الإطارات، لتحقيق الربح.

تاريخ

استغلت خدمات إعادة التوجيه الأولى نطاقات المستوى الأعلى (TLD) مثل " .to " (تونغا)، و" .at " (النمسا)، و" .is " (أيسلندا). وكان هدفها إنشاء عناوين URL يسهل تذكرها. وكانت V3.com أول خدمة إعادة توجيه واسعة الانتشار، حيث بلغ عدد مستخدميها 4 ملايين مستخدم في ذروتها عام 2000. ويعزى نجاح V3.com إلى امتلاكها مجموعة واسعة من النطاقات القصيرة سهلة التذكر، بما في ذلك "r.im" و"go.to" و"i.am" و"come.to" و"start.at". استحوذت شركة FortuneCity.com، وهي شركة استضافة مواقع مجانية كبيرة، على V3.com في أوائل عام 1999. [ 25 ] ومع انخفاض سعر بيع نطاقات المستوى الأعلى من 50 دولارًا أمريكيًا سنويًا إلى أقل من 10 دولارات أمريكية ، تراجع استخدام خدمات إعادة التوجيه. ومع إطلاق TinyURL عام 2002، ظهر نوع جديد من خدمات إعادة التوجيه، وهو اختصار عناوين URL . كان هدفهم اختصار الروابط الطويلة، لتسهيل نشرها على منتديات الإنترنت. ومنذ عام 2006، ومع فرض حد أقصى يبلغ 140 حرفًا على خدمة تويتر الشهيرة ، ازداد استخدام خدمات اختصار الروابط بشكل كبير.

إخفاء المُحيل

تُخفي خدمات إعادة التوجيه المُحيلَ من خلال وضع صفحة وسيطة بين الصفحة التي يوجد عليها الرابط والوجهة المقصودة. ورغم تشابهها من حيث المبدأ مع خدمات إعادة توجيه عناوين URL الأخرى، إلا أنها تخدم غرضًا مختلفًا، ونادرًا ما تُحاول تقصير أو إخفاء عنوان URL الوجهة (إذ يقتصر أثرها الجانبي المقصود على إخفاء معلومات المُحيل وتوفير بوابة واضحة بين المواقع الإلكترونية الأخرى). يُستخدم هذا النوع من إعادة التوجيه غالبًا لمنع الروابط الضارة المحتملة من الحصول على معلومات باستخدام المُحيل، مثل مُعرّف الجلسة في سلسلة الاستعلام. تستخدم العديد من مواقع المجتمعات الكبيرة إعادة توجيه الروابط الخارجية لتقليل احتمالية استغلالها لسرقة معلومات الحساب، ولتوضيح متى يغادر المستخدم الخدمة، ما يُقلل من فرص نجاح عمليات التصيّد الاحتيالي .

إليكم مثال بسيط على مثل هذه الخدمة، مكتوب بلغة PHP .

< ?php $ url = htmlspecialchars ( $ _GET [ ' url' ]); header ( 'Refresh: 0; url=https://' . $url ); ?> < ! -- Fallback using meta refresh. --> <html> <head> <title> إعادة التوجيه... </ title > < meta http-equiv = " refresh" content = " 0;url = https : // < ? = $ url ; ? > " > </head> <body> محاولة إعادة التوجيه إلى <a href="https://<?=$url; ?> " > https : // < ? = $ url ; ? > </a> . </body> </html>

لا يتحقق المثال أعلاه من هوية المُحيل (مثلاً، عبر المُحيل، مع إمكانية تزييف ذلك). كما أنه لا يتحقق من عنوان URL المُقدّم. هذا يعني أن بإمكان شخص خبيث الربط بصفحة إعادة التوجيه باستخدام مُعامل URL من اختياره، من أي صفحة تستخدم موارد خادم الويب.

قضايا أمنية

يمكن للمهاجمين استغلال إعادة توجيه عناوين URL لتنفيذ هجمات التصيد الاحتيالي . فإذا لم يتم التحقق من صحة وجهة إعادة التوجيه بشكل كافٍ من قِبل تطبيق ويب، يُمكن للمهاجم توجيه تطبيق الويب إلى موقع ويب عشوائي. تُعرف هذه الثغرة الأمنية بثغرة إعادة التوجيه المفتوحة. [ 26 ] [ 27 ] في بعض الحالات، عندما تحدث إعادة توجيه مفتوحة كجزء من عملية المصادقة ، تُعرف هذه الثغرة الأمنية بإعادة التوجيه الخفية. [ 28 ] [ 29 ] عند حدوث إعادة توجيه خفية، يُمكن لموقع الويب المُهاجم سرقة معلومات المصادقة من موقع الويب الضحية. [ 26 ] تُعد ثغرات إعادة التوجيه المفتوحة شائعة نسبيًا على الإنترنت. في يونيو 2022، رصد موقع TechRadar أكثر من 25 مثالًا نشطًا لثغرات إعادة التوجيه المفتوحة على الإنترنت، بما في ذلك مواقع مثل جوجل وإنستجرام . [ 30 ] لإعادة التوجيه المفتوحة مُعرّف CWE خاص بها، وهو CWE-601 . [ 31 ]

تُتيح إعادة توجيه عناوين المواقع الإلكترونية آليةً لتنفيذ هجمات تسريب البيانات عبر المواقع . فمن خلال قياس المدة التي يستغرقها موقع ويب لعرض صفحة معينة، أو من خلال التمييز بين صفحات الوجهة المختلفة، يستطيع المهاجم الحصول على معلومات مهمة حول حالة موقع ويب آخر. في عام 2021، اكتشف نيتل وزملاؤه ثغرةً أمنيةً في تطبيق واجهة برمجة تطبيقات الأداء في متصفح كروم، مما مكّنهم من رصد عمليات إعادة التوجيه عبر المصادر المختلفة بدقة. [ 32 ]

انظر أيضاً

مراجع

  1. ١ ٢ "جوجل تُعيد إحياء التجسس عبر إعادة التوجيه" . مدونة anta.net . ٢٩ يناير ٢٠٠٩. الرقم الدولي الموحد للدوريات ١٧٩٧-١٩٩٣ . مؤرشف من الأصل في ١٧ أغسطس ٢٠١١. 
  2. ^ "عمليات إعادة التوجيه وتحسين محركات البحث - الدليل الإجمالي" . أوديستو . تم الاسترجاع 29 نوفمبر 2015 .
  3. ↑ "نصائح لتحسين محركات البحث: مناقشة عمليات إعادة التوجيه 302" . مات كاتس، الرئيس السابق لفريق مكافحة البريد العشوائي في جوجل. 4 يناير 2006.
  4. ↑ "عمليات إعادة التوجيه الخفية" . شركة جوجل، 3 ديسمبر 2015.
  5. ↑ "دليل مختصر لعمليات إعادة التوجيه وإعادة التوجيه غير المُدققة" . مشروع أمان تطبيقات الويب المفتوحة (OWASP). 21 أغسطس 2014.
  6. ↑ "إعادة التوجيه وتحسين محركات البحث - الدليل الكامل" . أوديستو . تم الاطلاع عليه بتاريخ 29 نوفمبر 2015 .
  7. ↑ "إعادة توجيه PHP: من 302 إلى 301 حلٌّ قويٌّ وموثوق" . WebSiteFactors.co.uk. مؤرشف من الأصل بتاريخ 12 أكتوبر 2012.
  8. ↑ روي تي. فيلدينغ؛ جوليان إف. ريشكي، محرران (2014). "الموقع" . بروتوكول نقل النص التشعبي (HTTP/1.1): الدلالات والمحتوى . IETF . ص 68. القسم 7.1.2. doi : 10.17487/RFC7231 . RFC 7231 .   
  9. ↑ بيرنرز-لي، تيم ؛ فيلدينغ، روي تي ؛ ماسينتر، لاري (2005). "حل المراجع" . مُعرِّف الموارد الموحد (URI): بناء الجملة العام . IETF . ص 28. القسم 5. doi : 10.17487/RFC3986 . RFC 3986 .   
  10. ↑ "Module ngx_http_rewrite_module - rewrite" . nginx.org . تم الاطلاع عليه بتاريخ 24 ديسمبر 2014 .
  11. ↑ مورينين، قسطنطين أ. (18 فبراير 2013). "موقع ويب ديناميكي مكتوب بالكامل باستخدام nginx.conf؟ نقدم لكم mdoc.su!" . nginx@nginx.org (قائمة بريدية) . تم الاطلاع عليه بتاريخ 24 ديسمبر 2014 .
  12. ↑ مورينين، قسطنطين أ. (23 فبراير 2013). "mdoc.su - روابط مختصرة لصفحات الدليل لأنظمة FreeBSD وOpenBSD وNetBSD وDragonFly BSD" . تم الاطلاع عليه بتاريخ 25 ديسمبر 2014 .
  13. ↑ مورينين، قسطنطين أ. (23 فبراير 2013). "mdoc.su.nginx.conf" . تم الاطلاع عليه بتاريخ 25 ديسمبر 2014 .
  14. ↑ "علامة HTML الوصفية" . www.w3schools.com .
  15. ↑ "استكشاف الوثائق الديناميكية" . 2 أغسطس 2002. مؤرشف من الأصل في 2 أغسطس 2002.{{cite web}}: CS1 maint: bot: حالة عنوان URL الأصلي غير معروفة ( رابط )
  16. ↑ "جوجل وياهو تقبلان عمليات التحديث التلقائي للبيانات الوصفية كعمليات إعادة توجيه 301" . منشورات سيباستيان. 3 سبتمبر 2007.
  17. ↑ "إرشادات إمكانية الوصول إلى محتوى الويب 1.0" . www.w3.org .
  18. ↑ فريق ضمان الجودة. "استخدم عمليات إعادة التوجيه القياسية" . www.w3.org .
  19. ↑ "التقنيات الأساسية لإرشادات إمكانية الوصول إلى محتوى الويب 1.0" . www.w3.org .
  20. ↑ "مولد إعادة توجيه عناوين URL من جانب العميل عبر المتصفحات" . Insider Zone. مؤرشف من الأصل بتاريخ 26 يوليو 2020. تم الاطلاع عليه بتاريخ 27 أغسطس 2015 .
  21. ↑ آرون إميغ (19 يناير 2005). "تقنية مكافحة التصيد الاحتيالي". مؤرشف في 27 سبتمبر 2007 على موقع Wayback Machine (ملف PDF). مختبرات راديكس.
  22. ↑ "HTML 5.2: 11. الميزات المهملة" . www.w3.org .
  23. ↑ شوارتز، باري (18 ديسمبر 2007). "قد يستغرق جوجل وقتًا أطول لاكتشاف عمليات إعادة التوجيه المزدوجة" . منتدى محركات البحث . تم الاطلاع عليه بتاريخ 28 يناير 2024 .
  24. ↑ روي تي. فيلدينغ ؛ جوليان إف. ريشكي، محرران (2014). "إعادة التوجيه 3xx" . بروتوكول نقل النص التشعبي (HTTP/1.1): الدلالات والمحتوى . IETF . ص 54. القسم 6.4. doi : 10.17487/RFC7231 . RFC 7231 .   
  25. ↑ "مكاسب صافية لدولة صغيرة في المحيط الهادئ" . بي بي سي نيوز . 14 سبتمبر 2007. مؤرشف من الأصل في 12 مايو 2014. تم الاطلاع عليه في 27 مايو 2010 .
  26. 1 2 إينوسينتي، توماسو؛ غولينيلي، ماتيو؛ أونارلي أوغلو، كان؛ ميرهيداري، علي؛ كريسبو، برونو؛ كيردا، إنجين (4 ديسمبر 2023). "قصور التحقق من صحة عناوين URI لإعادة التوجيه في OAuth 2.0، حرفيًا" . المؤتمر السنوي لتطبيقات أمن الحاسوب . ACSAC '23. نيويورك، نيويورك، الولايات المتحدة الأمريكية: رابطة آلات الحوسبة. الصفحات 256-267 . doi : 10.1145/3627106.3627140 . hdl : 11572/399070 . ISBN  979-8-4007-0886-2.
  27. ↑ "إعادة توجيه مفتوحة" . OWASP. 16 مارس 2014. مؤرشف من الأصل في 7 ديسمبر 2014. تم الاطلاع عليه في 21 ديسمبر 2014 .
  28. ↑ "إعادة توجيه سرية" . تيتراف. 1 مايو 2014. مؤرشف من الأصل في 10 مارس 2016. تم الاسترجاع في 21 ديسمبر 2014 .
  29. ↑ «اكتشاف ثغرة أمنية خطيرة في بروتوكولي OAuth وOpenID» . سي نت. 2 مايو 2014. تم الاطلاع عليه بتاريخ 21 ديسمبر 2014 .
  30. ↑ مايك ويليامز (5 يونيو 2022). "ما هي ثغرة إعادة التوجيه المفتوح، ولماذا هي خطيرة، وكيف يمكنك الحفاظ على سلامتك؟" . TechRadar . تم الاطلاع عليه في 8 أبريل 2024 .
  31. ↑ "CWE - CWE-601: إعادة توجيه عنوان URL إلى موقع غير موثوق به ('Open Redirect') (4.14)" . cwe.mitre.org . تم الاطلاع عليه بتاريخ 8 أبريل 2024 .
  32. ↑ نيتل، لوكاس؛ ماينكا، كريستيان؛ نيميتز، ماركوس؛ نوس، دومينيك تريفور؛ شوينك، يورغ (13 نوفمبر 2021). "XSinator.com: من نموذج رسمي إلى التقييم التلقائي لتسريبات المواقع المتعددة في متصفحات الويب" . وقائع مؤتمر ACM SIGSAC لعام 2021 حول أمن الحاسوب والاتصالات . CCS '21. نيويورك، نيويورك، الولايات المتحدة الأمريكية: رابطة آلات الحوسبة. الصفحات 1771-1788 . doi : 10.1145/3460120.3484739 . ISBN  978-1-4503-8454-4.