Google, VK और अन्य के उदाहरणों का उपयोग करते हुए WEB हमलों के खिलाफ प्रमाणीकरण विधियों और कुछ सुरक्षा तंत्रों पर शोध परिणाम

विषय किस बारे में है?

इस लेख में मैं एक उदाहरण के रूप में आधुनिक आईटी उद्योग के "दिग्गज" का उपयोग करके उपयोगकर्ता सुरक्षा सुनिश्चित करने के लिए विभिन्न कार्यात्मकताओं (मुख्य रूप से वेब सेवाओं पर) के कार्यान्वयन के बारे में बात करूंगा। यह सामग्री डेवलपर्स, वास्तुकारों, टीम के नेताओं और प्रबंधकों के लिए उपयोगी होगी जब वे समान कार्यक्षमता के कार्यों को स्थापित करेंगे। लेख में कार्यान्वयन पेशेवर टीमों द्वारा विकसित किए गए थे, समय और लाखों उपयोगकर्ताओं (साथ ही बड़ी संख्या में हैकर्स) द्वारा परीक्षण किया गया था, हालांकि इस बात की कोई गारंटी नहीं है कि यह विशेष कार्यान्वयन विकल्प बिल्कुल सही है और 100% सुरक्षित है, बिल्कुल नहीं। जानकारी इन संसाधनों के एक व्यक्तिगत विश्लेषण पर आधारित है।

प्राधिकरण

सबसे सफल और दिलचस्प विकल्प वीके में लागू किया गया है। यहाँ संक्षेप में बताया गया है । पासवर्ड साइट के मुख्य पृष्ठ पर दर्ज किया जाता है, लेकिन फ़ॉर्म की कार्रवाई उपडोमेन (login.vk.com) की ओर ले जाती है, कुकी को वर्तमान डोमेन (login.vk.com) और vk.com (रीमिक्सडीड) के लिए सेट किया जाता है। अगर "मुख्य" डोमेन पर कुकी के साथ कुछ गलत है (बदला हुआ, अंतिम आईपी मेल नहीं खाता, आदि), तो login.vk.com पर एक रीडायरेक्ट स्वचालित रूप से होता है। और अगर इस ब्राउज़र में पासवर्ड वास्तव में दर्ज किया गया था, तो इसमें एक स्थायी कुकी होगी (जो पासवर्ड दर्ज करते समय सेट की गई थी), जो स्वचालित रूप से लॉग इन होगी। यदि यह नहीं है (उदाहरण के लिए, XSS के माध्यम से कुकीज़ को ले जाया गया था) तो इसे खाते की अनुमति नहीं दी जाएगी। अंतिम सक्रिय सत्र भी दर्ज किए गए हैं - 6 टुकड़े, जिन्हें "लाइव" माना जाता है और जिसे आपके व्यक्तिगत खाते में पूरा किया जा सकता है, जो बहुत सुविधाजनक है। Google के पास प्राधिकरण के लिए एक अलग डोमेन भी है। और चूंकि इसमें कई अलग-अलग सेवाएं हैं, इसलिए प्राधिकरण के दौरान सेवाओं की एक सूची अभी भी स्थानांतरित की गई है, जहां इन कुकीज़ के साथ शुरू करना है।

द्वि-कारक प्राधिकरण

वे इसे बाएं और दाएं के बारे में बात करते हैं, और सामान्य स्थिति में एसएमएस के माध्यम से भेजकर ओटीपी को लागू करने की प्रथा है। फिर से, उदाहरण के लिए Google को लें। और पहली समस्या: संचार उपलब्ध नहीं है, उपयोगकर्ता को क्या करना चाहिए? इसके लिए दो समाधान लागू किए गए:

• मोबाइल डिवाइस पर एप्लिकेशन के माध्यम से ऑफ़लाइन ओटीपी पीढ़ी। पहला कदम वेबसाइट और मोबाइल एप्लिकेशन को एक विशेष कोड दर्ज करके सिंक्रनाइज़ करना है। सर्वर पर और मोबाइल फोन के पासवर्ड समय के साथ मेल खाते हैं (यह बेहतर है कि फोन NTP के माध्यम से सिंक्रनाइज़ किया गया है)। यानी मोबाइल डिवाइस पर, ऑफ़लाइन, एक पासवर्ड प्रदर्शित किया जाता है, जो ओटीपी (हर मिनट - एक नया पासवर्ड) के रूप में उपयुक्त है। परिणामस्वरूप, कहीं भी, एक कार्यशील मोबाइल डिवाइस के साथ, हम बिना एसएमएस प्राप्त किए / Google से कॉल प्राप्त किए बिना लॉग इन कर सकते हैं।
• एक बार का पासवर्ड पहले ही जनरेट हो गया है। Account.google.com/b/0/SmsAuthSettings पृष्ठ पर, आप पासवर्ड प्राप्त कर सकते हैं और प्रिंट कर सकते हैं जो हमेशा (एक बार) ओटीपी कोड का अनुरोध करने के लिए उपयुक्त होगा। प्रिंट कर सकते हैं और वॉलेट में डाल सकते हैं

अपने आंतरिक पोर्टल login.corp.google.com पर Google कर्मचारियों का प्राधिकरण भी दो-कारक प्रमाणीकरण का उपयोग करके होता है, लेकिन आप अभी भी प्राधिकरण के लिए एक यूएसबी टोकन (बैंकों के साथ सादृश्य) का उपयोग कर सकते हैं।

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

पासवर्ड वसूली

एक तार्किक निरंतरता यह बिंदु होगा। मेल को लिंक भेजने के साथ एक मानक योजना का उपयोग करना, क्या करना बेहतर है, एक नया पासवर्ड स्वयं उत्पन्न करें या उपयोगकर्ता को इसे दर्ज करने का अवसर दें? सामान्य तौर पर, दूसरी विधि (Google) अधिक बेहतर होती है। लेकिन अगर आप पहले एक का उपयोग करने का निर्णय लेते हैं - कम से कम 7-8 वर्ण (अक्षर / संख्या / कम से कम एक विशेष वर्ण) द्वारा पासवर्ड उत्पन्न करें। दूसरे दिन, मैंने उपयोगकर्ताओं और पासवर्डों के साथ एक तालिका का विश्लेषण किया, जहां पासवर्ड स्वचालित रूप से सेट किया गया था (md5, 6 वर्ण, [a-zA-Z0-9])। और एक पैसे के लिए मैं उन्हें शुद्ध रूप में मिला। वैसे भी, यह अनुशंसित है: श * और दो "लवण"। (यानी शा * की तरह ($ stat_salt। $ पासवर्ड। $ ईमेल)), यानी जब, एक पूर्ण डेटाबेस डंप के साथ, तब भी कोई पासवर्ड डिक्रिप्ट नहीं किया जा सकता है, क्योंकि स्थिर "नमक" (जो, उदाहरण के लिए, कोड में वायर्ड है) ज्ञात नहीं होगा। लेकिन यह एक और बातचीत का विषय है।

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

CSRF सुरक्षा

CSRF के खिलाफ संरक्षण "छिपी" टोकन (<इनपुट प्रकार = "छिपा">) का उपयोग करके सही ढंग से लागू किया गया है। लेकिन उन्हें सही तरीके से कैसे उत्पन्न किया जाए? प्रत्येक प्राधिकरण के साथ Google, सत्र के लिए टोकन जारी करता है और इसे कुकी में संग्रहीत करता है। यानी कुकी को देखता है, जो रूप में आया है उसे देखता है, अगर सब कुछ ठीक है, तो हम आगे काम करते हैं। यही है, एक सत्र में सभी कार्यों के लिए एक टोकन। उपयोगकर्ता से यह पूछना गलत है कि यदि टोकन वास्तव में इस कार्रवाई ("इस लेख में स्वयं को पहचानने वाले सेवा डेवलपर्स को" हैलो करना चाहते हैं) के संयोग नहीं है, क्योंकि यह बहुत ही संदिग्ध है (उपयोगकर्ता स्वचालित रूप से क्लिक कर सकता है + ऐसे स्पष्टीकरण के लिए अनुरोधों के लिए वर्कअराउंड हैं) "। Vkontakte ने अलग तरह से काम किया - वे प्रत्येक क्रिया के लिए एक टोकन उत्पन्न करते हैं, जो वर्तमान उपयोगकर्ता की आईडी, कार्रवाई आईडी और "लक्ष्य" (उपयोगकर्ता, समुदाय / सार्वजनिक नंबर, आदि) की कुछ आईडी पर आधारित है। लेकिन, दुर्भाग्य से, यह हर जगह जाँच नहीं है।

सामग्री के लिए अलग डोमेन

सभी उपयोगकर्ता सामग्री को एक अलग डोमेन पर अपलोड किया जाना चाहिए । यह आपको कई खतरों से बचा सकता है। Google के पास googleusercontent.com है, VK के पास vk.me है। फेसबुक, Google, VKontakte से सॉफ़्टवेयर के उदाहरण का उपयोग करके XSS'im iOS डिवाइस का उपयोग करते समय, जब भेद्यता का दोहन करने के लिए पूरे प्लेटफ़ॉर्म का "फ़ीचर" कोई नुकसान नहीं कर सकता है - उपयोगकर्ता सामग्री के लिए एक अलग (पृथक, कोई कुकी) डोमेन के महत्व का एक और संकेतक ।

सामग्री सुरक्षा नीति

अब सीएसपी को ध्यान में रखते हुए कई संसाधन सक्रिय रूप से विकसित हो रहे हैं। उदाहरण के लिए, यैंडेक्स ने हाल ही में पूर्ण सीएसपी समर्थन के साथ एक मेल विकल्प लागू किया है। CSP एक शीर्षक है जो ब्राउज़र को बताता है कि (कहां से पते) और क्या सामग्री (चित्र, स्क्रिप्ट) आप से डाउनलोड कर सकते हैं। नतीजतन, जब हमलावर XSS हमले का एक तरीका खोजता है, तो वह किसी भी डेटा को सीधे दूसरे सर्वर पर भेजने में असमर्थ होता है, या इनलाइन स्क्रिप्ट को निष्पादित करने में भी असमर्थ होता है। बेशक, वर्कअराउंड्स भी हैं, उदाहरण के लिए, आप एक चित्र उत्पन्न कर सकते हैं और इसमें जेएस एम्बेड कर सकते हैं और यदि संभव हो तो, किसी एक स्वीकृत डोमेन पर अपलोड करें। और इसे देखें <script src "... image.gif>, एक उदाहरण ।

HSTS

HTTP हेडर ( लेख ) के बारे में फिर से बोलते हुए, हम HSTS का उल्लेख नहीं कर सकते हैं। इसे भेजना एक बात है।
एक और बात यह है कि क्रोम और फ़ायरफ़ॉक्स में एक पूर्व-साझा सूची है, जिसके बीच उन डोमेन को सूचीबद्ध किया गया है जिन्हें HTTPS - src.chromium.org/viewvc/chrome/trunk/src/net/http-transport_security_state_static.json के माध्यम से जाना चाहिए।
आप अपने संसाधन को मेल में जोड़ने के लिए अनुरोध भेज सकते हैं

3 पार्टी खाते

अन्य सेवाओं (डोमेन पंजीकरण, निगरानी, ​​आदि) तक पहुंचने के लिए अक्सर (और कभी-कभी यह आवश्यक होता है)। और ऐसा लगता है कि ऐसे सभी संसाधनों पर पासवर्ड बदलने पर एक चक्र (उदाहरण के लिए, हर 3 महीने में एक बार) होता है। अच्छा अभ्यास।

शायद कहीं और "दिग्गज" (मुझे कोई जानकारी नहीं है) वीपीएन का उपयोग कार्य संसाधनों (छोटी कंपनियों में लगातार अभ्यास) और कुछ अन्य सुरक्षा तंत्रों के लिए करते हैं। यदि आप उन लोगों को जानते हैं - टिप्पणियों में साझा करें :)

अपडेट: Apple वीपीएन का उपयोग कर सकता है।