2008-09-15 4 views
24

मेरे पास कुछ वेबसाइट है जिसके लिए लॉगऑन की आवश्यकता होती है और संवेदनशील जानकारी दिखाती है।क्या कोई व्यक्ति लॉग आउट करने के बाद किसी पृष्ठ को प्रतिपादित करने का कोई तरीका है लेकिन "बैक" बटन दबाएं?

व्यक्ति पृष्ठ पर जाता है, लॉग इन करने के लिए कहा जाता है, फिर जानकारी देखने के लिए मिलता है।

व्यक्ति साइट से लॉग आउट करता है, और उसे वापस लॉगिन पृष्ठ पर रीडायरेक्ट किया जाता है।

तब व्यक्ति "वापस" हिट कर सकता है और उस पृष्ठ पर वापस जा सकता है जहां संवेदनशील जानकारी निहित है। चूंकि ब्राउज़र बस एचटीएमएल के रूप में इसके बारे में सोचता है, यह उन्हें कोई समस्या नहीं दिखाता है।

क्या उस जानकारी को प्रदर्शित होने से रोकने का कोई तरीका है जब व्यक्ति लॉग आउट स्क्रीन से "बैक" बटन हिट करता है? मैं बैक बटन को स्वयं अक्षम करने की कोशिश नहीं कर रहा हूं, मैं सिर्फ संवेदनशील जानकारी को फिर से प्रदर्शित होने की कोशिश कर रहा हूं क्योंकि व्यक्ति अब साइट में लॉग इन नहीं है।

तर्क के लिए, उपर्युक्त साइट/परिदृश्य फॉर्म प्रमाणीकरण के साथ एएसपी.नेट में है (इसलिए जब उपयोगकर्ता पहले पृष्ठ पर जाता है, जो वह पृष्ठ है जो वे चाहते हैं, तो उन्हें लॉगऑन पेज पर रीडायरेक्ट किया जाता है - अगर इससे कोई फर्क पड़ता है)।

उत्तर

13

संक्षिप्त उत्तर यह है कि इसे सुरक्षित रूप से नहीं किया जा सकता है।

हालांकि, बहुत सारी चालें लागू की जा सकती हैं ताकि उपयोगकर्ताओं को वापस हिट करना और संवेदनशील डेटा प्रदर्शित करना मुश्किल हो सके।

Response.Cache.SetCacheability(HttpCacheability.NoCache); 
Response.Cache.SetExpires(Now.AddSeconds(-1)); 
Response.Cache.SetNoStore(); 
Response.AppendHeader("Pragma", "no-cache"); 

इस ग्राहक पक्ष पर कैशिंग को निष्क्रिय कर देगा, लेकिन इस सभी ब्राउज़रों द्वारा समर्थित नहीं है।

आप AJAX तो संवेदनशील डेटा उपयोग करने का विकल्प एक UpdatePanel कि ग्राहक कोड से अद्यतन किया जाता है का उपयोग कर प्राप्त किया जा सकता है और इसलिए यह जब वापस मार जब तक ग्राहक अभी भी में लॉग ऑन है प्रदर्शित नहीं किया जाएगा है।

+2

लंबा उत्तर: बैक बटन पर क्लिक करने के लिए लक्ष्य मशीन तक पहुंचने वाला एक दुर्भावनापूर्ण व्यक्ति भी इस उपाय को रोकने में सक्षम होने की संभावना है। यह उस जानकारी को प्राप्त करने के लिए केवल सबसे आकस्मिक प्रयास रोक देगा। एक बार लक्ष्य मशीन की जानकारी हो जाने के बाद, वह मशीन नियंत्रण में है, न कि आप। – Dustman

3
aspdev.org से

:

Page_Load ईवेंट हैंडलर के शीर्ष पर निम्न पंक्ति जोड़ें और अपने ASP.NET पेज उपयोगकर्ताओं ब्राउज़रों में संचित नहीं किया जाएगा:

Response.Cache.SetCacheability(HttpCacheability.NoCache) 

सेटिंग्स इस संपत्ति है कि अगर यह सुनिश्चित करता है उपयोगकर्ता बैक-बटन हिट करता है, सामग्री समाप्त हो जाएगी, और यदि वह "रीफ्रेश" दबाता है तो उसे लॉगिन-पेज पर रीडायरेक्ट कर दिया जाएगा।

0

आप नो कैश निर्देश के लिए देख रहे हैं:

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> 

आप एक मास्टर पेज डिजाइन, जा रहा है कि यह एक हथकंडा का एक छोटा सा हो सकता है मिल गया है, लेकिन मेरा मानना ​​है कि आप इस निर्देश डाल सकते हैं एक ही पृष्ठ पर, आपकी बाकी की साइट को प्रभावित किए बिना (मान लीजिए कि आप यही चाहते हैं)।

यदि आपको यह निर्देश सेट मिला है, तो ब्राउज़र पृष्ठ की एक नई नई प्रतिलिपि की तलाश में सर्वर पर वापस कर्तव्य करेगा, जिससे आपके सर्वर को यह पता चल जाएगा कि उपयोगकर्ता प्रमाणित नहीं है और उसे टक्कर देता है लॉगिन वाला पन्ना।

0

लॉगआउट ऑपरेशन POST है। फिर ब्राउज़र "क्या आप वाकई फॉर्म को दोबारा पोस्ट करना चाहते हैं" के लिए संकेत देंगे? पेज दिखाने के बजाए।

0

मैं कैसे ASP.NET में यह करने के लिए पता नहीं है, लेकिन PHP में मैं की तरह कुछ करना होगा:

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); 
header("Cache-Control: no-cache"); 
header("Pragma: no-cache"); 

कौन सा ब्राउज़र बलों पुनः जाँच करने के लिए है कि आइटम है, तो आपके प्रमाणीकरण की जाँच शुरू हो जाना चाहिए , उपयोगकर्ता का उपयोग अस्वीकार कर दिया।

0

सही उत्तर में प्रतिक्रिया पर HTTP कैश-नियंत्रण शीर्षलेख सेट करने का उपयोग शामिल है। यदि आप यह सुनिश्चित करना चाहते हैं कि कभी भी आउटपुट कैश करें, तो आप कैश-कंट्रोल: नो-कैश कर सकते हैं। यह अक्सर नो-स्टोर के समन्वय में भी प्रयोग किया जाता है।

अन्य विकल्प, यदि आप सीमित कैशिंग चाहते हैं, तो समय समाप्ति समय निर्धारित करना और पुन: संशोधित करना शामिल है, लेकिन ये संभावित रूप से सभी को कैश किए गए पृष्ठ को फिर से प्रदर्शित करने का कारण बन सकता है।

देखें http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

0

यह एक तनाव का एक सा है, लेकिन अगर आप था एक जावा एप्लेट या एक फ्लैश अनुप्रयोग है कि एम्बेडेड और प्रमाणीकरण किया गया था कि के माध्यम से किया गया था आप इतना है कि वे में प्रमाणित करने के लिए किया था, ईआरएम यह कर सकता है , जब भी वे जानकारी देखना चाहते थे, सर्वर के साथ 'रीयल-टाइम'।

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

हमेशा यह संभावना है कि कोई व्यक्ति संवेदनशील स्थिति के साथ पृष्ठ को सहेज सकता है, इस स्थिति के आसपास कोई कैश नहीं होने वाला है (लेकिन फिर एक स्क्रीनशॉट हमेशा फ़्लैश या जावा एप्लिकेशन से लिया जा सकता है)।

0

पूर्णता के लिए:

Response.Cache.SetCacheability(HttpCacheability.NoCache); 
Response.Cache.SetNoStore(); 
Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1)); 
1

DannySmurf, < मेटा> तत्वों अत्यंत अविश्वसनीय है जब यह विशेष रूप से Pragma भी ज्यादा नियंत्रित कैशिंग करने के लिए आता है, और कर रहे हैं। Reference

1

डैनीप और अन्य, नो-कैश संवेदनशील संसाधनों को संग्रहित करने से कैश को रोकता नहीं है। इसका मतलब केवल यह है कि एक कैश किसी संसाधन को सेवा नहीं दे सकता है जिसे इसे पहले पुन: वैध किए बिना संग्रहीत किया गया है। यदि आप संवेदनशील संसाधनों को कैश होने से रोकना चाहते हैं, तो आपको नो-स्टोर निर्देश का उपयोग करने की आवश्यकता है।

0

वैसे, एक प्रमुख ब्राजीलियाई बैंक निगम (बानको डो ब्रासिल) में जो दुनिया के सबसे सुरक्षित और कुशल घरेलू बैंकिंग सॉफ्टवेयर में से एक होने के कारण जाना जाता है, उन्होंने बस प्रत्येक पृष्ठ में history.go (1) डाल दिया। , यदि आप बैक बटन दबाते हैं, तो आप वापस आ जाएंगे। सरल।

+0

मुझे लगता है कि इस तरह के जावास्क्रिप्ट हैक को डीबगर या ऐसा कुछ उपयोग करके इस कमांड को छोड़ना संभव है। –

+0

हाँ, लेकिन क्या होता है यदि उपयोगकर्ता 3 चरणों में वापस जाने के लिए छोटे बैक तीर का उपयोग करता है? चीजों को करने के लिए मुश्किल से एक अच्छा तरीका है। – LordOfThePigs

0

कृपया देखो HTTP प्रतिक्रिया शीर्षलेख में। अधिकांश एएसपी कोड जो लोग पोस्ट कर रहे हैं उन्हें सेट करना प्रतीत होता है। सुनिश्चित हो।

chipmunk book from O'Reilly HTTP का बाइबल है, और Chris Shiflett's HTTP book भी अच्छा है।

9

Cache and history are independent और किसी एक को प्रभावित नहीं करना चाहिए।

एकमात्र अपवाद made for banks यह है कि इतिहास में नेविगेट करते समय HTTPS और Cache-Control: must-revalidate ताकतों का संयोजन ताज़ा होता है।

सादे HTTP में ब्राउज़र बग का शोषण करके इसे करने का कोई तरीका नहीं है।

आप जावास्क्रिप्ट का उपयोग करके इसके आसपास हैक कर सकते हैं जो document.cookie की जांच करता है और "हत्यारा" कुकी सेट होने पर रीडायरेक्ट करता है, लेकिन मुझे लगता है कि यह ब्राउज़र गंभीर रूप से गलत हो सकता है जब ब्राउज़र अपेक्षाकृत कुकीज़ को सेट/साफ़ नहीं करता है।

0

आपके पास संवेदनशील पृष्ठ के साथ वेब पेज HTTP पोस्ट के रूप में वापस किया जा सकता है, तो ज्यादातर मामलों में ब्राउज़र आपको यह संदेश देगा कि आप डेटा को पुनः सबमिट करना चाहते हैं या नहीं। (दुर्भाग्य से मुझे इस व्यवहार के लिए एक कैनोलिक स्रोत नहीं मिल रहा है।)

0

मेरे पास बैंकिंग उदाहरण दिमाग में था।

अपने बैंक के पेज उस में यह है:

<meta http-equiv="expires" content="0" /> 

यह इस मुझे लगता है के बारे में होना चाहिए।

1

आपके पास जावास्क्रिप्ट फ़ंक्शन एक त्वरित सर्वर चेक (AJAX) हो सकता है और यदि उपयोगकर्ता लॉग इन नहीं है, तो वर्तमान पृष्ठ मिटा देता है और इसे एक संदेश के साथ बदल देता है। यह स्पष्ट रूप से उपयोगकर्ता के लिए कमजोर होगा जो जावास्क्रिप्ट बंद है, लेकिन यह बहुत दुर्लभ है। ऊपर की तरफ, यह ब्राउजर और सर्वर प्रौद्योगिकी (एएसपी/पीएचपी आदि) दोनों अज्ञेयवादी है।

संबंधित मुद्दे

 संबंधित मुद्दे