अपने उपयोगकर्ताओं की सुरक्षा कैसे करें

100 बिलियन अमेरिकी डॉलर - एक बड़ी राशि, है ना? 2012 में वे ऑनलाइन विज्ञापन के विश्व बाजार का मूल्यांकन करते हैं। आपको यह समझने के लिए बहुत दूर नहीं जाना पड़ेगा कि इस पैसे को कौन प्राप्त करेगा। बेशक, ये Google, फेसबुक, याहू जैसी कंपनियां हैं! आदि लेकिन इस राशि का लगभग 20% स्पैमर्स को प्राप्त होगा। यह विशाल धन एक बहुत अच्छी तरह से संगठित व्यवसाय और प्रतिभाशाली लोगों को आकर्षित करता है।



Facebook, Odnoklassniki, VKontakte और अन्य सामाजिक नेटवर्क के आगमन से पहले, मेल स्पैम वितरित करने का सबसे लोकप्रिय तरीका था। लेकिन अब सोशल नेटवर्क आधिकारिक चैनलों को दरकिनार करते हुए कष्टप्रद विज्ञापनों को वितरित करने के लिए बड़ी संख्या में उपकरण प्रदान करते हैं। मैं उनमें से प्रत्येक के बारे में विवरणों में नहीं जाऊंगा, यह इस पोस्ट का विषय नहीं है, मैं सिर्फ उन लोगों को सूचीबद्ध करता हूं जो हम ओडनोक्लासनिक में मुठभेड़ करते हैं।

निजी संदेशों के माध्यम से पहला और शायद सबसे महत्वपूर्ण स्पैम है। सोशल नेटवर्क पर पोस्ट करने से आसान कुछ भी नहीं है, है ना?

दूसरा - विभिन्न वस्तुओं (फोटो, वीडियो, आदि) पर टिप्पणियों के माध्यम से।

तीसरा स्पैम समूहों, या नियमित समूहों में प्रासंगिक समाचार और विषयों के निर्माण के लिए निमंत्रण है।

तस्वीरों में चौथा स्पैम है, यानी जब एक विज्ञापन संदेश एक तस्वीर पर लिखा जाता है और फिर साइट पर अपलोड किया जाता है।

पांचवीं किस्म को सशर्त रूप से "एरोक्लास्नीटसी" कहा जाता है। वे आधे-नग्न रूप में एक आकर्षक व्यक्ति का एक खाता स्थापित करते हैं, उपयुक्त स्थिति डालते हैं या रद्दी विज्ञापन के साथ तस्वीरें जोड़ते हैं, और यात्रा करना शुरू करते हैं।

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

दुर्भाग्य से, खातों के अवैध उपयोग से जुड़ी कई समस्याओं को सेवा के डेवलपर्स की ओर से हल नहीं किया जा सकता है, क्योंकि उनकी घटना का कारण उपयोगकर्ता प्रशिक्षण का निम्न स्तर है। बहुत से लोग यह नहीं जानते हैं कि यह सरल पासवर्ड सेट करने के लिए सुरक्षित नहीं है, कि आपको अज्ञात निर्माताओं से सॉफ़्टवेयर डाउनलोड और इंस्टॉल करने की आवश्यकता नहीं है, कि सार्वजनिक रूप से उपलब्ध कंप्यूटरों से साइट तक पहुंचते समय आपको "पासवर्ड याद रखें" चेकबॉक्स पर क्लिक करने की आवश्यकता नहीं है। केवल एक चीज जो एक डेवलपर कर सकता है, वह उन्हें जटिल पासवर्ड का उपयोग करने और सुरक्षा सिफारिशें देने के लिए मजबूर करता है, जिससे उपयोगकर्ता प्रशिक्षण का स्तर बढ़ जाता है। लेकिन ये सभी समस्याएं सिर्फ हिमशैल की टिप हैं, और इससे कभी भी बड़े पैमाने पर चोरी नहीं होगी। ऐसी समस्याएं हैं जो उपयोगकर्ताओं के लिए कहीं अधिक खतरनाक हैं - उदाहरण के लिए, प्रोग्रामर की योग्यता का निम्न स्तर जिसने सेवा विकसित की है, या अपर्याप्त रूप से अच्छी तरह से स्थापित परीक्षण प्रक्रिया। यह ठीक ऐसी समस्याएं हैं जिनकी चर्चा इस पोस्ट में की जाएगी।

कुछ समय पहले, हमने वेब सुरक्षा समस्याओं के बारे में गंभीरता से भविष्यवाणी की, कार्यक्षमता के विकास और परीक्षण की आंतरिक प्रक्रियाओं का मानकीकरण किया, ग्राहक डेटा की सुरक्षा के लिए आवश्यकताओं को ध्यान में रखते हुए, हम पोर्टल पर कमजोरियों की संख्या को कम करने में सक्षम थे। पोस्ट में आगे मैं आपके साथ उन कुछ समस्याओं को साझा करना चाहूंगा जिनका हमने सामना किया, और बात की कि हमने उन्हें कैसे हल किया।

क्रॉस-साइट स्क्रिप्टिंग

सबसे आम कमजोरियों में से एक जो आपको दस्तावेज़ के शरीर में अपना कोड एम्बेड करने की अनुमति देता है।

इसका उपयोग कैसे करें:

• कुकीज़ या अन्य उपयोगकर्ता डेटा चोरी हो सकते हैं;
• आप साइट की उपस्थिति और व्यवहार को बदल सकते हैं;
• आप उपयोगकर्ता की ओर से कार्य कर सकते हैं (विंडोज़ खोलें, संदेश भेजें, आदि)।

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

उदाहरण 1:
उपयोगकर्ता द्वारा दर्ज किया गया डेटा: name = “ /> ”;
डेटा कैसे आउटपुट है: ${name}

जब हम उपयोगकर्ता सामग्री को सीधे DOM दस्तावेज़ के शरीर में आउटपुट करते हैं, तो हम आसानी से ऐसी स्थिति में आ सकते हैं जिसमें ब्राउज़र आउटपुट कोड में HTML कोड को कोड के रूप में अनुभव करेगा, न कि स्ट्रिंग के रूप में।



आंकड़ा दिखाता है कि फोटो के लिए कैप्शन को HTML ऑब्जेक्ट चयन के रूप में प्रदर्शित किया गया है (मैंने स्क्रिप्ट टैग को चयन के लिए स्पष्टता से बदल दिया है)। इस बग का शिकार कोई भी हो सकता है जिसने फोटो खोला, विशेष रूप से पटाखा द्वारा हस्ताक्षरित।

संघर्ष का तरीका:
उपयोगकर्ता के डेटा के लिए चौकस, हर जगह जब दस्तावेज़ शरीर के लिए खतरनाक पात्रों का उत्पादन। बदलें & <> "'के साथ & lt; & gt; & quot; & # 39;

उदाहरण 2:
उपयोगकर्ता द्वारा दर्ज किया गया डेटा: name=” '>/ ”;
डेटा कैसे आउटपुट है:



प्रभाव पहले उदाहरण के समान होगा, सुरक्षा के तरीके समान हैं।

उदाहरण 3:
उपयोगकर्ता द्वारा दर्ज किया गया डेटा: name=”Madonna'); doSomeKillingAndStealing(' ”; name=”Madonna'); doSomeKillingAndStealing(' ”;
डेटा कैसे आउटपुट है: Search

यह समस्या संगीत की स्थिति में थी: जब आप कलाकार के नाम पर क्लिक करते हैं, तो आप अपना कोड स्थानापन्न कर सकते हैं।

संघर्ष का तरीका:
जैसा कि पहले दो उदाहरणों में, खतरनाक पात्रों को बच जाना चाहिए, लेकिन जावास्क्रिप्ट के लिए वे थोड़ा अलग हैं। आउटपुट पर \ / "" को \\ \ "\" से प्रतिस्थापित करना आवश्यक है

मुख्य नियम उपयोगकर्ता डेटा पर कभी भी भरोसा नहीं करना है।

कुकीज़

कुकीज़ ब्राउज़र में कुंजी / मूल्य भंडारण हैं, जिसका उपयोग सत्र और सत्र आईडी के बीच उपयोगकर्ता डेटा को संग्रहीत करने के लिए किया जाता है। डिफ़ॉल्ट रूप से, कुकीज़ तक पहुंच के लिए जावास्क्रिप्ट है, जो उपरोक्त कमजोरियों को देखते हुए, उन्हें डेटा स्टोर करने के लिए एक खतरनाक जगह बनाता है। लेकिन कुकीज़ की सुरक्षा कैसे करें, यह बताने से पहले, मैं ध्यान देना चाहता हूं कि वे कैसे सेट होते हैं।

तो, कुकीज़ को एक विशेष डोमेन के लिए, सभी उप डोमेन के लिए और आमतौर पर सभी डोमेन के लिए सेट किया जा सकता है। लगभग हमेशा आपको एक विशिष्ट डोमेन के लिए कुकीज़ सेट करने की आवश्यकता होती है। लेकिन कभी-कभी ऐसे समय होते हैं जब डोमेन के बीच स्विच करते समय कुकीज़ से डेटा का उपयोग करने में सक्षम होना आवश्यक होता है। इसलिए, उदाहरण के लिए, Odnoklassniki पर, जब मुख्य साइट और मोबाइल संस्करण के बीच स्विच किया जाता है, तो पासवर्ड फिर से दर्ज करने की आवश्यकता नहीं है। यह .odnoklassniki.ru डोमेन पर सत्र कुकी सेट करके किया जाता है। लेकिन इस सुविधा के लिए आप महंगा भुगतान कर सकते हैं। यदि एक कमजोर उपडोमेन odnoklassniki.ru पर दिखाई देता है, तो इस डोमेन के माध्यम से मुख्य पोर्टल की कुकी तक पहुंचना संभव होगा।

कुकीज़ की सुरक्षा करने का सबसे अच्छा तरीका है कि उनके HttpOnly विशेषता को सेट किया जाए। यह विशेषता जावास्क्रिप्ट के माध्यम से कुकीज़ तक पहुंच से इनकार करती है। 99% मामलों में ऐसी सुरक्षा काम करेगी, सिवाय उन लोगों के जहां पटाखा XMLHttpRequest भेज सकता है और एक प्रतिक्रिया प्राप्त कर सकता है जो कुकीज़ सेट करता है। फिर, GetAllResponseHeaders विधि का उपयोग करके, आप उन्हें एक्सेस कर सकते हैं।

लेकिन उपयोगकर्ता डेटा के बारे में बातचीत जारी रखें। डेटा न केवल पाठ, बल्कि फ़ाइलों के रूप में भी हो सकता है। यदि आपकी सेवा आपको फ़ाइलों को अपने आप को अपलोड करने की अनुमति देती है, तो बेहद सावधान रहें: आपको उन फ़ाइल स्वरूपों को स्पष्ट रूप से परिभाषित करना होगा जिन्हें आप अपने सर्वर पर अपलोड करने की अनुमति देते हैं, और इन फ़ाइलों को वापस करते समय, उनके लिए सही हेडर सेट करें। आगे मैं समझाऊंगा कि क्यों।

एसवीजी

सर्वर पर अपलोड करने के लिए एसवीजी वेक्टर ग्राफिक्स प्रारूप खतरनाक स्वरूपों में से एक है। फ़ाइल में ही जावास्क्रिप्ट हो सकता है। इसे पेज से ठीक से जोड़ने के 5 तरीके हैं।

• वस्तु
• iframe
• एम्बेड
• img
• सीएसएस पृष्ठभूमि

कनेक्ट होने पर पहले 3 तरीके फ़ाइल में मौजूद जावास्क्रिप्ट को निष्पादित करेंगे। सर्वर पर ऐसी फाइल खोजने का तथ्य एक निश्चित खतरे को बढ़ाता है। आखिरकार, एक हमलावर निजी संदेश द्वारा एक फ़ाइल के लिए एक सीधा लिंक भेज सकता है, जिसे खोलकर उपयोगकर्ता फ़ाइल के अंदर स्क्रिप्ट निष्पादित करेगा।

एसवीजी एकमात्र संभावित खतरनाक प्रारूप नहीं है। उपयोगकर्ता द्वारा अपलोड किए गए किसी भी फ़्लैश या HTML दस्तावेज़ को एक अलग डोमेन में जोड़ा जाना चाहिए, जहां से आपके पोर्टल पर कुकीज़ तक पहुंच नहीं है।

सामग्री और चरित्र सूँघना

ब्राउज़रों में ऐसी एक दिलचस्प विशेषता होती है: यदि भेजी गई फ़ाइल की सामग्री सामग्री-प्रकार हेडर में निर्दिष्ट एक से भिन्न होती है, तो ब्राउज़र फ़ाइल इंटर्नल द्वारा खोजेगा कि यह वास्तव में किस प्रारूप के लिए है। यदि ब्राउज़र अचानक HTML के अंदर मिल जाता है, तो यह फ़ाइल को बिल्कुल HTML के रूप में व्याख्या करता है। यानी यदि आपकी सेवा आपको JPEG और PNG प्रारूप में फ़ाइलें अपलोड करने की अनुमति देती है, और किसी कारण से आउटपुट करते समय, सामग्री-प्रकार: छवि / jpeg सेट करता है, तो, PNG फ़ाइलों को लौटाता है, ब्राउज़र समझेगा कि फ़ाइल प्रारूप वास्तव में क्या है। यहां तक ​​कि अगर आप सर्वर पर छवियों का अनुकूलन कर रहे हैं, तो यह बिल्कुल भी गारंटी नहीं देता है कि अनुकूलन के बाद एचटीएमएल वैध हो जाएगा या किसी भी तरह बदल जाएगा। छवि को इस तरह से आकार देने के लिए उपकरण हैं कि फ़ाइल के अंदर HTML का अनुकूलन करने के बाद, यह अपरिवर्तित रहता है।
समस्याओं से बचने के लिए, आपको 3 बुनियादी नियमों का पालन करना चाहिए:

• हमेशा उस सामग्री-प्रकार के साथ फाइल लौटाएं जो वास्तव में उसके पास है
• पाठ / सादा और अनुप्रयोग / ओकटेट-स्ट्रीम, के रूप में उपयोग न करें इन प्रारूपों के लिए, ब्राउज़र हमेशा देखते हैं कि अंदर क्या है
• हेडर को X-Content-Options में सेट करें: nosniff। यह हेडर ब्राउज़रों को सामग्री को देखने से रोकता है।

क्लिकजैकिंग

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

इस समस्या से निपटने के दो तरीके हैं:

• फ्रेम में साइट के खुलने पर रोक लगाने वाला शीर्षक (X-FRAME-OPTIONS = DENY)
• जावास्क्रिप्ट कोड

उदाहरण जावास्क्रिप्ट जिसका उपयोग Odnoklassniki पर किया जाता है:

 try{ top.location.toString(); if(top != self) { throw new Error(''); } } catch(e){ top.location = location; } 

हमारे मामले में, हम पोर्टल के कुछ वास्तुशिल्प विशेषताओं के कारण शीर्षक का उपयोग नहीं कर सकते हैं, इसलिए हम जावास्क्रिप्ट द्वारा संरक्षित हैं।

क्रॉस-साइट अनुरोध जालसाजी

यह सबसे सरल कमजोरियों में से एक है। यह आपको उपयोगकर्ता की ओर से कार्रवाई करने की अनुमति देता है, उदाहरण के लिए, संदेश, दर तस्वीरें आदि भेजें। बेशक, Odnoklassniki पर ऐसी कोई समस्या नहीं है, लेकिन वे कुछ अन्य ज्ञात संसाधनों पर देखे जाते हैं। इन संसाधनों की सुरक्षा के लिए, मैं उनके नामों को आवाज नहीं दूंगा। मैं एक उदाहरण द्वारा इस समस्या का सार बताऊंगा: मान लीजिए कि आपके पास एक बहुत लोकप्रिय मंच है, और आप जानना चाहते हैं कि वास्तव में आपकी साइट पर कौन जाता है। आप Odnoklassniki के साथ एक खाता पंजीकृत कर सकते हैं और एक अदृश्य iframe में अपनी प्रोफ़ाइल का लिंक एम्बेड कर सकते हैं। फिर, जब आप अपने फ़ोरम में लॉग इन करते हैं, तो Odnoklassniki पर सभी अधिकृत उपयोगकर्ता स्वचालित रूप से आपके पास जाएंगे, अर्थात। इसे महसूस किए बिना यात्रा पर जाने की क्रिया करें।

इस पर, मैं शायद अपने बड़े पद को समाप्त कर दूंगा। यदि कोई इस विषय में रुचि रखता है, तो यहां जानकारी के कुछ अच्छे स्रोत हैं:

बुक - माइकल ज़ल्वस्की द्वारा "द टैंगल्ड वेब"
www.owasp.org

ओडनोक्लासनिक टीम