एप्लिकेशन परत में 'फायरशेप' हमले को मिटाना?

Question

वेबसाइट अनुप्रयोगों के लिए 'फायरशेप' विधि को कम करने के लिए लोगों की क्या प्रक्रियाएं हैं?

हमने इस बारे में सोचा है कि किसी साइट पर सभी ट्रैफ़िक एन्क्रिप्ट करने के अलावा, हमले को कम करने के अलावा वेब डेवलपर्स के लिए कुछ समस्या हो सकती है।

एक सुझाव जो हमने साथ आया था, पथ आधारित कुकीज़ का उपयोग करना था, और एक विशिष्ट पथ के लिए यातायात एन्क्रिप्ट करना था जहां खाता संचालन या व्यक्तिगत बातचीत होती है। हालांकि यह उपयोगिता को जटिल बनाता है, हालांकि, शेष साइट (अन-एन्क्रिप्टेड - अन-प्रमाणीकृत) बिट में यह नहीं पता कि उपयोगकर्ता कौन होगा।

क्या किसी के पास इस वेक्टर के हमले को कम करने के लिए कोई अन्य सुझाव है, जबकि उपयोगिता के उपयोग योग्य स्तर को बनाए रखते हुए?

Answer 1

Firesheep कुछ भी नया नहीं है। सत्र अपहरण दो दशकों से अधिक समय से चल रहा है। आपको अपनी कुकी परत "एन्क्रिप्ट" की आवश्यकता नहीं है, जो आपकी परिवहन परत से नियंत्रित होती है। कुकीज़ हमेशा cryptographic nonce होना चाहिए।

आमतौर पर हैकर्स ने पता बार javascript:document.cookie='SOME_COOKIE' में टाइप करके अपनी स्वयं की कुकी सेट की है, फायरशीप स्क्रिप्ट किड्स के लिए है जो जावास्क्रिप्ट की 1 पंक्ति से डरता है। लेकिन यह वास्तव में इस हमले को निष्पादित करने में आसान नहीं बनाता है।

यदि आप सत्र के पूरे जीवन के लिए HTTPS का उपयोग नहीं करते हैं तो कुकीज़ को अपहृत किया जा सकता है और यह OWASP A9 - Insufficient Transport Layer Protection के अलावा है। लेकिन आप एक्सएसएस के साथ एक सत्र को हाइजैक भी कर सकते हैं।

1) httponly cookies का प्रयोग करें। (ऐसा करता है कि जावास्क्रिप्ट document.cookie तक नहीं पहुंच सकता है, लेकिन आप अभी भी xss के साथ सवारी कर सकते हैं)

2) "secure cookies" का उपयोग करें (भयानक नाम, लेकिन यह एक ध्वज है जो ब्राउजर को केवल कुकी HTTPS बनाने के लिए मजबूर करता है।)

3) Sitewatch(free) या wapiti (open source)

इसके अलावा का उपयोग कर CSRF के बारे में भूल नहीं है XSS के लिए अपने वेब अनुप्रयोग के लिए स्कैन! (कौन सा फ़ायरशेप पता नहीं है)

Answer 2

किसी ने भी साझा कुंजी को संग्रहीत करने के लिए एचटीएमएल 5 में "वेब स्टोरेज" का लाभ उठाने का प्रयास किया (प्रमाणीकरण के दौरान एसएसएल-एन्क्रिप्टेड प्रतिक्रियाओं के दौरान पारित) जिसका उपयोग सत्र कुकी में बदलने के लिए जावास्क्रिप्ट द्वारा किया जाता है अधिक समय तक?

इस तरह, चोरी (अनएन्क्रिप्टेड) ​​सत्र कुकीज़ केवल थोड़े समय के लिए मान्य होगी।

मेरा अनुमान है कि वेब संग्रहण पोर्ट द्वारा होस्ट किया गया है (मेजबान के अतिरिक्त), इसलिए यह संभव नहीं होगा। अगर कोई इसके साथ भागना चाहता है तो बस उस विचार को फेंक दें।

Answer 3

खैर मुझे लगता है कि Firesheep हमले को कम करने की एक विधि का वर्णन करता है GitHub पर एक दिलचस्प लेख पाया।

https://github.com/blog/737-sidejack-prevention

Answer 4

जब उपयोगकर्ता के लॉग-इन में, सत्र में आईपी पते की दुकान।

इस सत्र से प्रत्येक अनुवर्ती अनुरोध पर, जाँच करें कि आईपी पते के सत्र में संग्रहीत से मेल खाता है।