ما هي ثغرات Open Redirect
See the English version
Open Redirect هو نوع من ثغرات تطبيق الويب التي تسمح للمهاجم بإعادة توجيه المستخدم من موقع ويب شرعي إلى موقع ويب ضار ، دون علم المستخدم أو موافقته.
في هجمات open redirect ، يصمم المهاجم عنوان URL مُعد خصيصًا يستفيد من ضعف في وظيفة إعادة توجيه موقع الويب المستهدف. ثم يخدع المهاجم المستخدم للنقر على عنوان URL ، والذي يعيد توجيه المستخدم إلى موقع ويب ضار. قد لا يدرك المستخدم أنه قد تمت إعادة توجيهه ، حيث قد يستخدم المهاجم عنوان URL يشبه عنوان URL الشرعي لموقع الويب.
بعض أنواع الثغرات الأمنية في Open Redirect مع أمثلة:
Parameter-based Open Redirect: يحدث هذا عندما يسمح موقع الويب للمستخدم بتحديد معلمة URL parameter التي تحدد المكان الذي تتم إعادة توجيه المستخدم إليه. يمكن للمهاجمين التلاعب بهذه parameters عن طريق إدخال عنوان URL ضار يعيد توجيه المستخدم إلى موقع ويب للتصيد الاحتيالي أو موقع ويب مصاب بالبرامج الضارة.
مثال: يحتوي موقع ويب على صفحة تسجيل دخول بوظيفة "العودة إلى الصفحة السابقة - return to previous page" التي تعيد توجيه المستخدم إلى الصفحة التي كان عليها قبل تسجيل الدخول.URL parameter لهذه الوظيفة هي return_to. يمكن للمهاجم إنشاء عنوان URL ضار يستخدم parameter return_to لإعادة توجيه المستخدم إلى موقع ويب ضار. على سبيل المثال:
https://www.example.com/login?return_to=http://malicious-site.comHeader-based Open Redirect: يحدث هذا عندما يستخدم موقع ويب header لإعادة توجيه المستخدمين إلى عنوان URL مختلف. يمكن للمهاجمين تعديل header لإعادة توجيه المستخدم إلى موقع ويب ضار.
مثال: يستخدم موقع الويب header لإعادة توجيه المستخدمين إلى صفحة مختلفة. يعدل المهاجم header لإعادة توجيه المستخدم إلى موقع ويب للتصيد الاحتيالي بدلاً من ذلك. على سبيل المثال ، قد يحتوي موقع الويب على رابط مثل:
<a href="/logout">Logout</a>
يمكن للمهاجم تعديل الرابط لإعادة توجيه المستخدم إلى موقع ويب ضار:<a href="https://malicious-site.com/logout">Logout</a>
JavaScript-based Open Redirect: يحدث هذا النوع من Open Redirect عندما يسمح موقع ويب باستخدام إدخال غير موثوق به untrusted input في وظيفة JavaScript التي تعيد توجيه المستخدمين إلى صفحة مختلفة.
مثال: يستخدم موقع الويب JavaScript function لإعادة توجيه المستخدمين إلى صفحة مختلفة. تأخذ الدالة argument تحدد عنوان URL المراد إعادة التوجيه إليه. يمكن للمهاجم إدخال عنوان URL ضار في function ، مما يتسبب في إعادة توجيه المستخدم إلى موقع ويب للتصيد الاحتيالي. على سبيل المثال:
<script> function redirect(url) { window.location = url; } var returnUrl = "http://malicious-site.com"; redirect(returnUrl); </script>
البحث عن Open Redirects
https://example.com/add_comment.php?return=/blog/post1234
next: تستخدم بعض مواقع الويب هذه Parameter لإعادة توجيه المستخدم إلى الصفحة التالية في series of steps أو عدة خطوات. على سبيل المثال ، قد يبدو عنوان URL على النحو التالي:
https://example.com/checkout.php?next=/checkout/step2
continue: تستخدم بعض مواقع الويب هذه Parameter لإعادة توجيه المستخدم إلى الصفحة التالية في العملية. على سبيل المثال ، قد يبدو عنوان URL على النحو التالي:
https://example.com/signup.php?continue=/dashboard.php
target: تستخدم بعض مواقع الويب هذه Parameter لإعادة توجيه المستخدم إلى صفحة معينة بعد إكمال أحد الإجراءات. على سبيل المثال ، قد يبدو عنوان URL على النحو التالي:
https://example.com/subscribe.php?target=/premium-content
go: تستخدم بعض مواقع الويب هذه Parameter لإعادة توجيه المستخدم إلى صفحة أو عنوان URL محدد. على سبيل المثال ، قد يبدو عنوان URL على النحو التالي:
https://example.com/landing.php?go=https://malicious-site.com
2- استخدم Google Dorks للعثور على Redirect Parameters
"inurl" عبارة عن Google Dorks للبحث عن كلمة رئيسية أو عبارة معينة داخل عنوان URL لصفحة ويب. باستخدام "inurl:" متبوعًا بالكلمة الرئيسية أو العبارة ، يمكنك توجيه Google لإرجاع النتائج التي تحتوي على تلك الكلمة أو العبارة المحددة في عنوان URL الخاص بها فقط.
على سبيل المثال ، إذا كنت تريد البحث عن صفحات الويب التي تحتوي على كلمة "security" في عنوان URL الخاص بها ، فيمكنك استخدام Google Dork التالي:
يمكن أن يساعدك استخدام "inurl" مع dorks بحث أخرى في تضييق نطاق نتائج البحث والعثور على أنواع معينة من مواقع الويب ونقاط الضعف.
inurl:redirect= site:example.com
inurl:return= site:example.com
inurl:returnTo= site:example.com
inurl:redirect_to= site:example.com
inurl:redirect_uri= site:example.com
inurl:redirect_url= site:example.com
inurl:redirect_page= site:example.com
inurl:target= site:example.com
inurl:out= site:example.com
inurl:go= site:example.com
inurl:to= site:example.com
inurl:link= site:example.com
inurl:next= site:example.com
inurl:file= site:example.com
inurl:uri= site:example.com
inurl:url= site:example.com
inurl:location= site:example.com
inurl:ref= site:example.com
inurl:navigateTo= site:example.com
inurl:transfer= site:example.com
inurl:path= site:example.com
inurl:domain= site:example.com
inurl:dest= site:example.com
inurl:away= site:example.com
inurl:forward= site:example.com3- Test for Parameter-Based Open Redirects
4- Test for Referer-Based Open Redirects
<html>
<a href="https://example.com/login">Click on this link!</a>
</html>استبدل عنوان linked URL بالصفحة المستهدفة. ثم أعد تحميل وزيارة صفحة HTML الخاصة بك. انقر فوق link ومعرفة ما إذا كان سيتم إعادة توجيهك إلى موقعك تلقائيًا أو بعد تفاعلات المستخدم المطلوبة.
Bypassing Open-Redirect Protection
غالبًا ما تصحح المتصفحات الحديثة عناوين URL التي لا تحتوي على المكونات الصحيحة لتصحيح عناوين URL المشوهة التي تسببها أخطاء المستخدم الإملائية.
على سبيل المثال ، سيفسر Chrome جميع عناوين URL هذه على أنها تشير إلى /http://example.com:
https:example.com https;example.com https:\/\/example.com https:/\/\example.com
يمكن أن تساعدك هذه التغيرات في تجاوز التحقق من صحة عنوان URL بالنسبة إلى blacklist.
إذا رفض validator أي عنوان URL لإعادة التوجيه يحتوي على الكلمات //:HTTPS أو //:HTTP ، فيمكنك استخدام بديل ، مثل //;HTTPS لتحقيق نفس النتائج.
تصحح معظم المتصفحات الحديثة أيضًا backslashes (\) تلقائيًا forward slashes (/) ، مما يعني أنها ستتعامل مع عناوين URL هذه كما يلي:
https:\\example.com
https://example.comإذا لم يتعرف validator على هذا السلوك ، فقد يؤدي إلى حدوث أخطاء. على سبيل المثال ، قد يمثل عنوان URL التالي مشكلة:
https: //example.com٪5C٪5C@google.com/
ولكن إذا قام المتصفح بالتصحيح التلقائي backslashes إلى forward slashes ، فسيتم إعادة توجيه المستخدم إلى موقع example.com والتعامل معgoogle.com كجزء من عنوان URL ، مما يشكل عنوان URL الصحيح التالي:
https://example.com/@google.com
Exploiting Flawed Validator Logic
يعد Exploiting Flawed Validator Logic أسلوبًا شائعًا لتجاوز حماية open redirect. في بعض الحالات ، تستخدم تطبيقات الويب التحقق من client-side للتحقق من صحة إدخال المستخدم ، مثل التحقق من تنسيق عنوان URL صالح. ومع ذلك ، يمكن تجاوز هذا التحقق من client-side ببساطة عن طريق تعديل معلمة URL لتضمين إعادة توجيه إلى موقع ويب خارجي.
على سبيل المثال ، لنفترض أن موقع الويب يستخدم عملية التحقق التالية من client-side للتأكد من أن parameter ال "redirect_url" هي عنوان URL صالح:
function isValidURL(url) { var pattern = new RegExp('^(https?:\\/\\/)?'+ // protocol '((([a-z\\d]([a-z\\d-]*[a-z\\d])*)\\.)+[a-z]{2,}|'+ // domain name '((\\d{1,3}\\.){3}\\d{1,3}))'+ // IP address '(\\:\\d+)?(\\/[-a-z\\d%_.~+]*)*'+ // port and path '(\\?[;&a-z\\d%_.~+=-]*)?'+ // query string '(\\#[-a-z\\d_]*)?$','i'); // fragment locator return pattern.test(url); } if(!isValidURL(redirect_url)) { alert('Invalid redirect URL'); return false; }
لا يتحقق مما إذا كان عنوان URL يعيد التوجيه إلى domain أو path مختلف. لذلك ، يمكن للمهاجم تجاوز هذا التحقق باستخدام عنوان URL يعيد التوجيه إلى موقع ويب خارجي.
على سبيل المثال ، قد يجتاز عنوان URL التالي عملية التحقق من جانب العميل ، ولكن يمكن استخدامه لإعادة توجيه المستخدمين إلى موقع ويب للتصيد الاحتيالي:
https://example.com/?redirect_url=https://attacker.com/redirect?url=https://phishing.com
في هذه الحالة ، يمكن للمهاجم استخدام URL parameter بالقيمة
https://attacker.com/redirect?url=https://phishing.com
لإعادة توجيه المستخدم إلى موقع التصيد الاحتيالي.
Using Data URLs
https://example.com/redirect.php?url=https://example.com/home
في هذه الحالة ، قد يتحقق script "redirect.php" من أن url" parameter" تبدأ بـ /https://example.com للتأكد من أنه domain موثوق به. ومع ذلك ، يمكن للمهاجم تجاوز هذا الفحص باستخدام data url:
https://example.com/redirect.php?url=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
يقوم عنوان URL ب encode صفحة HTML بسيطة ك base64-encoded string ، ويتضمنها كقيمة "parameter "url. عندما ينقر الضحية على الرابط ، سيقوم script redirect.php بتفسير عنوان URL data على أنه parameter URL صالحة ويعيد توجيه متصفح الضحية إلى عنوان URL data. سيقوم المتصفح بعد ذلك بفك تشفير decode ل base64-encoded string وعرض صفحة HTML مباشرةً ، bypassing أي عمليات تحقق من صحة عناوين URL الخارجية.
Exploiting URL decoding
https://example.com/redirect.php?url=https%3A%2F%2Fexample.com%2Fhome
في هذه الحالة ، تكون parameter ل "url" مشفرة URL-encoded ، مما يعني أنه يتم استبدال أحرف معينة ASCII hex codes المقابلة لها. تمثل القيمة المشفرة%3A%2F%2F الأحرف:// ، والتي تعد جزءًا من بروتوكول //:https في URL. قد يتحقق script redirect.php من أن parameter url تبدأ بـ /https://example.com للتأكد من أنه مجال موثوق به.
Double Encoding
ومع ذلك ، يمكن للمهاجم تجاوز هذا الفحص عن طريق encoding paramter URL مرتين:
https://example.com/redirect.php?url=https%253A%252F%252Fexample.com%252Fhome
Combining exploit techniques
الجمع بين تقنيات استغلال الثغرات هو نهج شائع يستخدمه المهاجمون bypass multiple layers من عمليات التحقق من الصحة وتحقيق الاستغلال الناجح لثغرات Open-Redirect. من خلال الجمع بين تقنيات مختلفة ، يمكن للمهاجمين إنشاء هجمات أكثر تعقيدًا يصعب اكتشافها والتخفيف من حدتها.
على سبيل المثال ، قد يقوم المهاجم بدمج URL encoding و data URLs لتجاوز عمليات التحقق من الصحة وتحقيق الاستغلال الناجح. خذ بعين الاعتبار المثال التالي:
https://example.com/redirect.php?url=data:text/html,<script>alert('Vulnerable')</script>
في هذه الحالة ، تحتوي parameter url على عنوان data URL الذي سينفذ "JavaScript code "alert('Vulnerable') عند إعادة توجيه أو redirect ل متصفح الضحية إلى عنوان URL. يعمل هذا الهجوم لأن ":data" بروتوكول صالح يمكن استخدامه في عمليات إعادة توجيه عناوين URL.
ومع ذلك ، قد تحظر بعض تطبيقات الويب ":data" لمنع هذا النوع من الهجوم. لتجاوز هذه الحماية ، يمكن للمهاجم تشفير data URL parameter:
https://example.com/redirect.php?url=data%3Atext%2Fhtml%2C%253Cscript%253Ealert%2528%2527Vulnerable%2527%2529%253C%252Fscript%253Eفي هذه الحالة ، قام المهاجم URL-encoded data URL parameter مرتين لتجاوز عمليات التحقق من الصحة التي تحظر ":data" بروتوكول. سيتم فك تشفير parameter بواسطة script redirect.php وتنفيذها بواسطة متصفح الضحية.
Escalating the attack
أحد الأساليب الشائعة لتصعيد هجوم Open-Redirect هو استخدامه مع هجمات التصيد الاحتيالي. في هذا السيناريو ، يرسل المهاجم رسالة بريد إلكتروني أو رسالة تصيدية phishing إلى الضحية ، تحتوي على رابط يبدو أنه يؤدي إلى موقع ويب شرعي. ومع ذلك ، فإن الرابط في الواقع يعيد توجيه المستخدم إلى موقع ويب مزيف يبدو مطابقًا للموقع الشرعي ، لكن المهاجم يتحكم فيه. يمكن للضحية بعد ذلك إدخال بيانات اعتماد تسجيل الدخول الخاصة بهم أو غيرها من المعلومات الحساسة ، والتي يتم الحصول عليها بعد ذلك من قبل المهاجم.
أسلوب آخر لتصعيد الهجوم هو استخدام الثغرة الأمنية Open-Redirect لشن هجمات cross-site scripting (XSS) ضد تطبيق الويب أو مستخدميها. في هذا السيناريو ، يقوم المهاجم injects malicious code في عنوان URL المعاد توجيهه ، والذي يتم تنفيذه بعد ذلك بواسطة متصفح الضحية عند زيارته لعنوان URL. يمكن استخدام code لسرقة البيانات الحساسة ، مثل session cookies ، أو لتنفيذ إجراءات نيابة عن الضحية.
العثور على أول Open Redirect
- ابحث عن redirect URL parameters. قد تكون هذه عرضة parameter-based open redirect.
- ابحث عن الصفحات التي تجري referer-based redirects. هؤلاء مرشحون referer-based open redirect.
- اختبر pages و parameters التي وجدتها لعمليات open redirects.
- إذا قام الخادم بحظر open redirects ، فجرّب تقنيات تجاوز الحماية المذكورة في هذا الدرس.
- فكّر في طرق استخدام open redirect في bugs الأخرى.