HTTP_REFERER का उपयोग कर साइट के आंतरिक लोगों तक उपयोगकर्ता पहुंच को अवरुद्ध करें

मेरे पास HttpServer पर नियंत्रण है लेकिन एप्लिकेशनसेवर या जावा अनुप्रयोगों पर बैठा नहीं है, लेकिन मुझे उन अनुप्रयोगों पर कुछ पृष्ठों तक सीधे पहुंच को अवरुद्ध करने की आवश्यकता है। निश्चित रूप से, मैं नहीं चाहता कि उपयोगकर्ता उपयुक्त सर्वलेट को प्रत्यक्ष GET / POST HTTP अनुरोध जारी करने वाले फॉर्मों तक पहुंच स्वचालित कर दें।

इसलिए, मैंने उपयोगकर्ताओं को HTTP_REFERER के मान के आधार पर अवरुद्ध करने का निर्णय लिया। आखिरकार, यदि उपयोगकर्ता साइट के अंदर नेविगेट कर रहा है, तो उसके पास उचित HTTP_REFERER होगा। खैर, मैंने यही सोचा था।

मैंने .htaccess फ़ाइल में एक पुनर्लेखन नियम लागू किया जो कहता है:

RewriteEngine on 

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

मुझे उन उपयोगकर्ताओं तक पहुंच प्रतिबंधित करने की उम्मीद है जिन्होंने साइट पर नेविगेट नहीं किया था, लेकिन क्वेरीस्ट्रिंग का उपयोग करके "सर्वलेट 1" या "सर्वलेट 2" सर्वलेट को सीधे GET अनुरोध जारी करें। लेकिन मेरी उम्मीदें अचानक समाप्त हो गईं क्योंकि नियमित अभिव्यक्ति (servlet1 | servlet2) / .+\?.+ बिल्कुल काम नहीं किया।

मैं वास्तव में निराश था जब मैंने उस अभिव्यक्ति को (servlet1 | servlet2) /.+ में बदल दिया और यह इतना अच्छा काम किया कि मेरे उपयोगकर्ता अवरुद्ध किए गए थे चाहे वे साइट पर नेविगेट किए हों या नहीं।

तो, मेरा सवाल यह है कि: यदि मैं एप्लिकेशन को संशोधित करने के लिए कोई एक्सेस / विशेषाधिकार / समय नहीं लेता हूं तो मैं कुछ पृष्ठों तक सीधे पहुंच के साथ "रोबोट" की अनुमति न देने की इस चीज़ को कैसे पूरा कर सकता हूं?

 0
जोड़ा संपादित
विचारों: 9
स्रोत
ro fr zh bn

9 उत्तर

आप अपने http अनुरोध से अलग उपयोगकर्ताओं और दुर्भावनापूर्ण स्क्रिप्ट को नहीं बता सकते हैं। लेकिन आप विश्लेषण कर सकते हैं कि कौन से उपयोगकर्ता बहुत कम समय में बहुत से पृष्ठों का अनुरोध कर रहे हैं, और अपने आईपी पते को अवरुद्ध कर सकते हैं।

0
जोड़ा
स्रोत

मेरे पास कोई समाधान नहीं है, लेकिन मैं शर्त लगा रहा हूं कि रेफरर पर भरोसा करना कभी काम नहीं करेगा क्योंकि उपयोगकर्ता-एजेंट इसे बिल्कुल भी भेजने के लिए स्वतंत्र नहीं हैं या उन्हें कुछ ऐसा करने के लिए धोखा दे रहे हैं जो उन्हें अंदर आने देगा।

0
जोड़ा
स्रोत

यदि आप खोज इंजन बॉट को कुछ पृष्ठों तक पहुंचने से रोकने की कोशिश कर रहे हैं, तो सुनिश्चित करें कि आप एक उचित स्वरूपित robots.txt का उपयोग कर रहे हैं फ़ाइल।

HTTP_REFERER का उपयोग अविश्वसनीय है क्योंकि यह आसानी से फ़ेक किया गया है।

एक और विकल्प ज्ञात बॉट के लिए उपयोगकर्ता एजेंट स्ट्रिंग को जांचना है (इसमें कोड संशोधन की आवश्यकता हो सकती है)।

0
जोड़ा
स्रोत

स्क्रीन स्क्रैपिंग को रोकने (या कम से कम देरी) रोकने के लिए जावास्क्रिप्ट एक और सहायक उपकरण है। अधिकांश स्वचालित स्क्रैपिंग टूल में जावास्क्रिप्ट दुभाषिया नहीं होता है, इसलिए आप छिपे हुए फ़ील्ड इत्यादि जैसी चीजें कर सकते हैं।

संपादित करें: यह फिल हैक आलेख की पंक्तियों के साथ कुछ।

0
जोड़ा
स्रोत

चीजों को थोड़ा और स्पष्ट करने के लिए:

  1. हां, मुझे पता है कि HTTP_REFERER का उपयोग पूरी तरह से अविश्वसनीय है और कुछ हद तक बचपन में है, लेकिन मुझे पूरा यकीन है कि एक्सेल वीबीए के साथ स्वचालन बनाने के लिए जो लोग (मुझसे शायद?) सीख चुके हैं, उन्हें नहीं पता होगा कि HTTP_REFERER को कैसे बदला जाए अंतिम समाधान के समय के भीतर।

  2. मेरे पास एप्लिकेशन कोड को संशोधित करने के लिए एक्सेस / विशेषाधिकार नहीं है। राजनीति। क्या आप मानते हैं कि? इसलिए, मुझे तब तक इंतजार करना होगा जब तक अधिकार धारक मेरे द्वारा अनुरोध किए गए परिवर्तन नहीं कर लेता।

  3. पिछले अनुभवों से, मुझे पता है कि अनुरोधित परिवर्तनों में उत्पादन में दो महीने लगेंगे। नहीं, उन्हें अपने सिर में एग्इल मेथोडोलॉजी बुक्स फेंकने से कुछ भी सुधार नहीं हुआ।

  4. यह एक इंट्रानेट ऐप है। तो मेरे पास मेरी प्रतिष्ठा को कमजोर करने की कोशिश करने वाले बहुत से युवा नहीं हैं। लेकिन मैं भारत से आने वाली एक बहुत ही फैंसी वैश्विक परामर्श सेवाएं "की प्रतिष्ठा को कमजोर करने की कोशिश करने के लिए पर्याप्त युवा हूं, लेकिन उत्सुकता से, वहां एक भी भारतीय काम नहीं कर रहा है।

अब तक, सबसे अच्छा जवाब "मिशेल डी मारे" से आता है: उपयोगकर्ताओं को उनके आईपी के आधार पर ब्लॉक करें। ठीक है, मैंने कल किया था। आज मैं कुछ और सामान्य बनाना चाहता था क्योंकि मेरे पास बहुत सारे कंगारू उपयोगकर्ता हैं (एक आईपी पते से दूसरे में कूदते हैं) क्योंकि वे वीपीएन या डीएचसीपी का उपयोग करते हैं।

0
जोड़ा
स्रोत

मुझे लगता है कि आप स्क्रीन स्क्रैपिंग को रोकने की कोशिश कर रहे हैं?

मेरी ईमानदार राय में HTTP_REFERER के मूल्य की जांच करके हल करने और ठीक करने का प्रयास करना मुश्किल है, केवल एक चिपकने वाला प्लास्टर है। सबमिशन स्वचालित करने की परेशानी के लिए जा रहे किसी भी व्यक्ति को अपने 'automaton' से सही रेफरर भेजने के लिए पर्याप्त समझदार होने जा रहा है।

आप सीमित सीमा का प्रयास कर सकते हैं लेकिन वास्तव में किसी भी प्रकार के किसी भी प्रकार के मानव-सत्यापन (एक कैप्चा) को मजबूर करने के लिए ऐप को संशोधित किए बिना, आपको रोकने के लिए यह कठिन लगता है।

0
जोड़ा
स्रोत

एक रेफरर का उपयोग सत्यापन की विधि के रूप में बहुत अविश्वसनीय है। जैसा कि अन्य लोगों ने उल्लेख किया है, यह आसानी से धोखा दिया जाता है। आपका सबसे अच्छा समाधान एप्लिकेशन को संशोधित करना है (यदि आप कर सकते हैं)

आप एक कैप्चा का उपयोग कर सकते हैं, या किसी प्रकार की कुकी या सत्र कुकी सेट कर सकते हैं जो ट्रैक करता है कि उपयोगकर्ता ने किस पृष्ठ पर पिछली बार विज़िट किया था (एक सत्र खराब होना कठिन होगा) और पृष्ठ दृश्य इतिहास का ट्रैक रखें, और केवल उन उपयोगकर्ताओं को अनुमति दें जिन्होंने ब्राउज़ किया है पेज को पाने के लिए आवश्यक पेज जिन्हें आप ब्लॉक करना चाहते हैं।

यह स्पष्ट रूप से आपको प्रश्न में आवेदन तक पहुंचने की आवश्यकता है, हालांकि यह सबसे मूर्खतापूर्ण तरीका है (पूरी तरह से नहीं, बल्कि मेरी राय में "पर्याप्त"।

0
जोड़ा
स्रोत

आप जो भी कर रहे हैं उसे प्राप्त करने के लिए आप एंटी-सीएसआरएफ टोकन का उपयोग करने में सक्षम हो सकते हैं।

This article explains it in more detail: Cross-Site Request Forgeries

0
जोड़ा
स्रोत

मुझे यकीन नहीं है कि मैं इसे एक बार में हल कर सकता हूं, लेकिन हम आवश्यकतानुसार आगे और आगे जा सकते हैं।

सबसे पहले, मैं जो कुछ सोच रहा हूं उसे दोहराना चाहता हूं और सुनिश्चित कर रहा हूं कि मैं स्पष्ट हूं। आप servlet1 और servlet2 के अनुरोधों को अस्वीकार करना चाहते हैं, अनुरोध में उचित रेफरर नहीं है और यह करता है क्वेरी स्ट्रिंग है? मुझे यकीन नहीं है कि मैं समझता हूं (servlet1 | servlet2) / .+\?.+ क्योंकि ऐसा लगता है कि आपको servlet1 और 2 के तहत फ़ाइल की आवश्यकता है। मुझे लगता है कि आप एक GET के साथ PATH_INFO ("?" से पहले) संयोजन कर रहे हैं क्वेरी स्ट्रिंग ("?" के बाद)। ऐसा लगता है कि PATH_INFO भाग काम करेगा लेकिन जीईटी क्वेरी टेस्ट नहीं होगा। मैंने 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]

उम्मीद है कि यह कम से कम आपको अपने लक्ष्य के करीब ले जाएगा। कृपया हमें बताएं कि यह कैसे काम करता है, मुझे आपकी समस्या में रूचि है।

(बीटीडब्लू, मैं मानता हूं कि रेफरर अवरोधन खराब सुरक्षा है, लेकिन मैं यह भी समझता हूं कि रिलायंस बलों को कभी-कभी अपूर्ण और आंशिक समाधान मिलते हैं, जिन्हें आप पहले से ही स्वीकार करते हैं।)

0
जोड़ा
स्रोत