منع وصول المستخدم إلى الأجزاء الداخلية للموقع باستخدام HTTP_REFERER

Question

لدي سيطرة على HttpServer ولكن ليس على ApplicationServer أو تطبيقات Java الموجودة هناك ولكني بحاجة إلى منع الوصول المباشر إلى صفحات معينة على تلك التطبيقات.على وجه التحديد، لا أريد للمستخدمين الوصول تلقائيًا إلى النماذج التي تصدر طلبات GET/POST HTTP المباشرة إلى servlet المناسب.

لذلك، قررت حظر المستخدمين بناءً على قيمة HTTP_REFERER.بعد كل شيء، إذا كان المستخدم يتنقل داخل الموقع، فسيكون لديه ملف مناسب HTTP_REFERER.حسنًا، هذا ما اعتقدته.

لقد قمت بتطبيق قاعدة إعادة الكتابة في ملف htaccess الذي ينص على ما يلي:

RewriteEngine on 

# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteRule (servlet1|servlet2)/.+\?.+ - [F]

كنت أتوقع منع الوصول إلى المستخدمين الذين لم يتنقلوا في الموقع ولكنهم أصدروا طلبات GET مباشرة إلى servlet1 أو servlet2 باستخدام سلاسل الاستعلام.لكن توقعاتي انتهت فجأة بسبب التعبير العادي (servlet1|servlet2)/.+\?.+ لم يعمل على الإطلاق.

لقد شعرت بخيبة أمل حقًا عندما غيرت هذا التعبير إلى (servlet1|servlet2)/.+ وقد نجح الأمر بشكل جيد لدرجة أنه تم حظر المستخدمين بغض النظر عما إذا كانوا يتنقلون في الموقع أم لا.

إذن سؤالي هو:كيف يمكنني تحقيق هذا الشيء المتمثل في عدم السماح "للروبوتات" بالوصول المباشر إلى صفحات معينة إذا لم يكن لدي وصول/امتيازات/وقت لتعديل التطبيق؟

Answer 1

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

أولاً، أريد أن أكرر ما أعتقد أنك تقوله وأتأكد من أنني واضح.تريد عدم السماح بطلبات servlet1 وservlet2 لأن الطلب لا يحتوي على المرجع المناسب وهو يفعل لديك سلسلة استعلام؟لست متأكدًا من أنني أفهم (servlet1|servlet2)/.+\?.+ لأنه يبدو أنك تحتاج إلى ملف ضمن servlet1 و2.أعتقد أنك ربما تقوم بدمج PATH_INFO (قبل "؟") مع سلسلة استعلام GET (بعد "؟").يبدو أن الجزء PATH_INFO سيعمل لكن اختبار استعلام GET لن يعمل.لقد أجريت اختبارًا سريعًا على الخادم الخاص بي باستخدام script1.cgi وscript2.cgi ونجحت القواعد التالية في تحقيق ما تطلبه.من الواضح أنه تم تعديلها قليلاً لتتناسب مع بيئتي:

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]

اكتشف ما سبق جميع طلبات الإحالة الخاطئة إلى script1.cgi وscript2.cgi التي حاولت إرسال البيانات باستخدام سلسلة استعلام.ومع ذلك، يمكنك أيضًا إرسال البيانات باستخدام path_info وعن طريق نشر البيانات.لقد استخدمت هذا النموذج للحماية من استخدام أي من الطرق الثلاث مع مُحيل غير صحيح:

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]

بناءً على المثال الذي كنت تحاول العمل فيه، أعتقد أن هذا هو ما تريده:

RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule (servlet1|servlet2)\b - [F]

نأمل أن يجعلك هذا على الأقل أقرب إلى هدفك.من فضلك اسمح لنا أن نعرف كيف يعمل، أنا مهتم بمشكلتك.

(راجع للشغل، أوافق على أن حظر المُحيل يمثل ضعفًا أمنيًا، لكنني أفهم أيضًا أن الترابط يفرض حلولًا غير كاملة وجزئية في بعض الأحيان، وهو ما يبدو أنك تعترف به بالفعل.)

Answer 2

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

Answer 3

لا يمكنك التمييز بين المستخدمين والنصوص البرمجية الضارة من خلال طلب http الخاص بهم.ولكن يمكنك تحليل المستخدمين الذين يطلبون عددًا كبيرًا جدًا من الصفحات في وقت قصير جدًا، وحظر عناوين IP الخاصة بهم.

Answer 4

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

يمكنك استخدام اختبار CAPTCHA، أو تعيين نوع من ملفات تعريف الارتباط أو ملفات تعريف الارتباط للجلسة التي تتتبع الصفحة التي زارها المستخدم آخر مرة (سيكون من الصعب انتحال الجلسة) وتتبع سجل عرض الصفحة، وتسمح فقط للمستخدمين الذين تصفحوا الصفحات المطلوبة للوصول إلى الصفحة التي تريد حظرها.

من الواضح أن هذا يتطلب منك الوصول إلى التطبيق المعني، إلا أنها الطريقة الأكثر ضمانًا (ليست تمامًا، ولكنها "جيدة بما يكفي" في رأيي.)

Answer 5

تعد Javascript أداة مفيدة أخرى لمنع (أو على الأقل تأخير) تجريف الشاشة.لا تحتوي معظم أدوات الكشط التلقائية على مترجم جافا سكريبت، لذا يمكنك القيام بأشياء مثل تعيين الحقول المخفية وما إلى ذلك.

يحرر:شيء على غرار هذه المقالة لفيل هاك.

Answer 6

أعتقد أنك تحاول منع تجريف الشاشة؟

في رأيي الصادق، من الصعب حل هذه المشكلة ومحاولة إصلاحها عن طريق التحقق من أن قيمة HTTP_REFERER هي مجرد مادة لاصقة.أي شخص سيكلف نفسه عناء أتمتة عمليات الإرسال سيكون ذكيًا بدرجة كافية لإرسال المرجع الصحيح من "الجهاز الآلي" الخاص به.

يمكنك تجربة تحديد المعدل ولكن دون تعديل التطبيق فعليًا لفرض نوع من التحقق من صحة هذا الإنسان (CAPTCHA) في مرحلة ما، فستجد صعوبة في منع ذلك.

Answer 7

إذا كنت تحاول منع روبوتات محرك البحث من الوصول إلى صفحات معينة، فتأكد من أنك تستخدم ملفًا منسقًا بشكل صحيح. ملف robots.txt ملف.

استخدام HTTP_REFERER غير موثوق به لأنه كذلك مزورة بسهولة.

هناك خيار آخر وهو التحقق من سلسلة وكيل المستخدم بحثًا عن الروبوتات المعروفة (قد يتطلب هذا تعديل التعليمات البرمجية).

Answer 8

لجعل الأمور أكثر وضوحا قليلا:

1. نعم، أعلم أن استخدام HTTP_REFERER أمر غير موثوق به تمامًا وصبياني إلى حد ما ولكني متأكد تمامًا من أن الأشخاص الذين تعلموا (مني ربما؟) إجراء عمليات التشغيل الآلي باستخدام Excel VBA لن يعرفوا كيفية تخريب HTTP_REFERER خلال الفترة الزمنية اللازمة الحل النهائي.

2. ليس لدي حق الوصول/الامتياز لتعديل رمز التطبيق.سياسة.هل تصدق ذلك؟لذا، لا بد لي من الانتظار حتى يقوم صاحب الحقوق بإجراء التغييرات التي طلبتها.

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

4. هذا هو التطبيق الإنترانت.لذلك ليس لدي الكثير من الشباب الذين يحاولون تقويض هيبتي.لكنني صغير بما يكفي لمحاولة تقويض هيبة "الخدمات الاستشارية العالمية الفاخرة التي تأتي من الهند" ولكن من الغريب أنه لا يوجد هندي واحد يعمل هناك.

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

Answer 9

قد تتمكن من استخدام رمز مضاد لـ CSRF لتحقيق ما تبحث عنه.

وهذا المقال يشرح ذلك بمزيد من التفصيل: تزوير الطلبات عبر المواقع