हब्रब्र पर 6 XSS और उनके परिणामों के साथ सुरक्षा के तरीके

किसी तरह मैं सोच रहा था कि हबराब्र पर कॉरपोरेट ब्लॉग की लागत कितनी है। मैं इस पेज पर गया और ऑर्डर लिंक पर क्लिक किया। स्वचालित रूप से, अपेक्षित आंकड़ों के बजाय, मैंने XSS परीक्षण के लिए एक वेक्टर पेश किया और अपने ब्राउज़र में JS निष्पादन प्राप्त किया। लेकिन यह सब इतना दिलचस्प नहीं है, क्योंकि एक्सबीएस के परिणामों से हैबर पर सुरक्षा के तरीके।

संरक्षण। HTTP केवल

चरण 2 और चरण 3 में दो क्षेत्रों में XSS का प्रदर्शन करने के बाद, यह दिलचस्प हो गया कि इस बारे में क्या किया जा सकता है। XSS का संचालन करने के लिए संभव होने पर सबसे मानक हमला वेक्टर प्राधिकरण सत्र को "मर्ज" करना और इसे अपने लिए स्थानापन्न करना है। कुकीज़ की ओर मुड़ते हुए, मैंने देखा कि PHPSSESID के लिए HTTP केवल ध्वज का उपयोग किया जाता है, जो JS के माध्यम से इस कुकी तक पहुँचने पर रोक लगाता है। यानी यहां तक ​​कि दुर्भावनापूर्ण जेएस कोड को लागू करने के बाद, हम उपयोगकर्ता सत्र को "मर्ज" नहीं कर सकते हैं और इसे प्रतिस्थापित कर सकते हैं (उपयोगकर्ता के तहत अधिकृत होने के लिए, क्लासिक हमला वेक्टर)। Apache (और यहाँ nginx, इसलिए यह गायब हो जाता है) के कुछ संस्करणों पर और ब्राउज़र में प्लग-इन के उपयोग के माध्यम से इस सुरक्षा को बायपास करने के तरीके हैं, लेकिन अगला पैराग्राफ सभी वैक्टर को तोड़ता है।

संकेत: phpsessid के लिए HTTP केवल ध्वज है, इसके लिए php.ini में निम्न मान सेट करें: session.cookie_httponly = true

संरक्षण। एंटी-सीएसआरएफ सुरक्षा

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

लेख में एक सुरक्षित वेब संसाधन की ओर। भाग 1 - सर्वर सॉफ्टवेयर मैंने निगनेक्स में निम्नलिखित नियम पर विचार किया (जिसे सीधे वेब एप्लिकेशन स्तर पर लागू किया जा सकता है) एक गंदे हैक के रूप में:

# ANTI CSRF HACK valid_referers blocked example.com www.example.com; if ($invalid_referer) { set $possible_csrf 1; } if ($request_method = POST) { set $possible_csrf "${possible_csrf}2"; } if ($possible_csrf = 12) { return 403; } 

और यहाँ वह एक आकर्षक उदाहरण है - हैब्राह्ब, इस नियम का उपयोग करता है। यानी हम किसी अन्य साइट से सर्वर पर एक POST अनुरोध नहीं भेज सकते हैं - हमें 403 मिलेगा। नतीजतन, हम केवल हमारे ब्राउज़र में JS कोड निष्पादित कर सकते हैं।

संकेत: CSRF के खिलाफ सुरक्षा, POST के माध्यम से XSS के परिणामों से बचाता है, जो भेद्यता को कम करता है।

हमला। कुकी इंजेक्शन

लेकिन फिर भी, क्या अब भी खामियां हो सकती हैं? प्रपत्र कैसे काम करता है, यह अध्ययन करने के लिए जारी रखते हुए, मुझे पता चला कि एप्लिकेशन फॉर्म में भरा डेटा अस्थायी रूप से सर्वर (शायद मेमकाचे) पर किसी तरह के कैश में संग्रहीत किया जाता है। यह कैश उपयोगकर्ता सत्र (PHPSESSID) से संबद्ध नहीं है, लेकिन अन्य के साथ - habrsession_id। यानी पहले से ही एक XSS वेक्टर के साथ एक फॉर्म जनरेट किया गया है और हमारे कुकी habrsession_id को किसी अन्य उपयोगकर्ता को प्रतिस्थापित करते हुए, हम सैद्धांतिक रूप से एक हमले को अंजाम दे सकते हैं। लेकिन हम (मानक शर्तों के तहत) किसी अन्य डोमेन पर कुकी मान सेट नहीं कर सकते हैं। लेकिन एक तरीका है - कुकी इंजेक्शन।

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

संकेत: लेख में लूपहोल्स की तलाश: डोम गाइड पर आधारित XSS , क्षणों का वर्णन किया गया है जहां DOM XSS के साथ कैच की प्रतीक्षा करनी है।

PS और विषय विषय का संकेत: विषय लिखते समय, इसे सहेजे नहीं और गलती से f5 दबा दिया। परिणामस्वरूप, एक बिंदु पर, मैंने लेख का पूरा पाठ खो दिया (जब मैंने इसे लगभग समाप्त कर दिया था, तो "पुनर्स्थापना" बटन ने मदद नहीं की)। एक नियमित कार्य प्रबंधक के माध्यम से प्रक्रिया को तुरंत डंप किया, इसे एचएक्सडी के माध्यम से खोला, अपने कीवर्ड द्वारा लेख का पाठ पाया (रूसी पाठ जस में था) और इसे यहां प्रतिस्थापित किया। लेख के शेर को पुनर्स्थापित किया।