🔼 🍂 📄 हमने ईमेल पढ़ने को कैसे सुरक्षित बनाया: Yandex.Mail में सामग्री सुरक्षा नीति 👬 👨🏾‍🚀 🛡️

Yandex.Mail टीम के लिए प्राथमिकताओं में से एक हमेशा से रही है और उपयोगकर्ता डेटा की सुरक्षा है। और यह न केवल पत्रों के भंडारण की चिंता करता है, बल्कि उनके लिए सुरक्षित पहुंच भी है। 2011 में वापस, हमने अपनी प्रॉक्सी के माध्यम से पत्रों में सभी छवियों को पारित करना शुरू कर दिया, दुर्भावनापूर्ण कोड वितरित करने के लिए चैनलों में से एक को अवरुद्ध किया, और ट्रैफ़िक को बचाने और अधिक गोपनीयता सुनिश्चित करने के लिए उन्हें कैश भी किया। इस वर्ष के नवंबर में, हम मेल प्राप्त करते और भेजते समय एन्क्रिप्शन को लागू किया जाता है, साथ ही मेल को HTTPS-only मोड में स्थानांतरित किया जाता है - अब वेब इंटरफ़ेस केवल सुरक्षित प्रोटोकॉल के माध्यम से उपलब्ध है।

और हाल ही में, हमने सामग्री सुरक्षा नीति मानक - उपयोगकर्ता डेटा की सुरक्षा के लिए एक नए तंत्र का समर्थन करना शुरू किया। इसके साथ, आप पृष्ठ पर स्क्रिप्ट को होस्ट से किसी भी संसाधन को लोड करने से रोक सकते हैं जो कि सफेद सूची में सूचीबद्ध नहीं हैं।

यह अभी भी एक दुर्लभ वस्तु है (अभी तक ज्ञात एक भी प्रमुख मेल इसे लागू नहीं करता है), और इस पोस्ट में हम मानक को लागू करने में अपना अनुभव साझा करेंगे।

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

उपयोगकर्ता इनपुट सत्यापन और वेब अनुप्रयोग फ़ायरवॉल (WAF);
विशेष पात्रों से बचकर;
HttpOnly के साथ कुकीज़ की रक्षा करना ताकि उन्हें जावास्क्रिप्ट से पढ़ा न जा सके;
उदाहरण के लिए, विभिन्न ब्राउज़र प्लगइन्स।

अब इस तरह के हमले के खिलाफ एक और रक्षा तंत्र है - सामग्री सुरक्षा नीति

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

आज यह सभी लोकप्रिय ब्राउज़रों द्वारा समर्थित है:

Chrome 25+, Firefox 23+, Opera 15+ और Yandex.Browser का पूर्ण समर्थन है और मानक शीर्षक को समझते हैं;
फ़ायरफ़ॉक्स 4-22, IE 10+ गैर-मानक एक्स-सामग्री-सुरक्षा-नीति हेडर का समर्थन करता है और मानक के लिए आंशिक समर्थन है;
क्रोम 14-24, सफारी 5-7 गैर-मानक एक्स-वेबकिट-सीएसपी हेडर का समर्थन करता है और मानक के लिए आंशिक समर्थन है।

संदर्भ के लिए, आप HTML5 रॉक्स पर मानक के डेवलपर्स में से एक, माइक वेस्ट पर लेख पढ़ सकते हैं। मानक का एक अच्छा वर्णन एमडीएन पर है ।

CSP से क्या बनता है?

CSP हेडर में साझा निर्देशों का एक सेट होता है - नीति के कुछ हिस्से जो कुछ ब्राउज़र संसाधनों को नियंत्रित करते हैं।

मानक के वर्तमान संस्करण में, निर्देशों का निम्नलिखित सेट उपलब्ध है:
डिफ़ॉल्ट-src उन मेजबानों की सूची निर्दिष्ट करता है जिन्हें डिफ़ॉल्ट रूप से अनिर्दिष्ट निर्देशों के लिए सौंपा गया है।
स्क्रिप्ट- src, style-src, object-src (फ़्लैश जैसे प्लगइन्स के लिए), img-src, मीडिया-src (ऑडियो और वीडियो), फ्रेम-src (iframe), फॉन्ट-src, कनेक्ट-src (XMLHttpRequest, WebSocket,) EventSource) - इसी ब्राउज़र संसाधनों को नियंत्रित करने वाले संकीर्ण निर्देश। प्रत्येक निर्देश के लिए, आपको मेजबानों की सूची (यूआरएल नहीं) निर्दिष्ट करनी चाहिए, जिसके साथ ब्राउज़र संवाद कर सकता है। आप * का उपयोग कर सकते हैं।
रिपोर्ट- uri - उस URL को इंगित करता है जिसमें JSON उल्लंघन की रिपोर्ट भेजी जाएगी। यह कैसा दिखता है:

{ "csp-report": { "document-uri": "https://mail.yandex.ru/neo2/", "referrer": "http://www.yandex.ru/", "violated-directive": "script-src 'unsafe-inline' 'unsafe-eval' blob: chrome-extension: *.yandex.ru *.yandex.net yandex.st", "original-policy": "....     ...", "blocked-uri": "...    ..." } }

कुछ ब्राउज़र रिपोर्ट में लिंक और जेएस लाइन को भी इंगित करते हैं, जिसके कारण सुरक्षा नीति का उल्लंघन हुआ।

इसके अलावा, निर्देशों में आप मेजबानों का उपयोग नहीं कर सकते हैं, लेकिन कीवर्ड (उद्धरण चिह्नों में आवश्यक):

'स्व' - वर्तमान होस्ट, प्रोटोकॉल और पोर्ट से मेल खाता है।
'कोई नहीं' - सब कुछ निषिद्ध है।
'असुरक्षित-इनलाइन' - स्क्रिप्ट-src में उपयोग किया जाता है और , javascript: - (onclick=""). style-src style="". , .. javascript , XSS. 'unsafe-eval' — script-src : eval, new Function, setTimeout(' var foo = "bar" ', 1).सक्षम करता है , javascript: - (onclick=""). style-src style="". , .. javascript , XSS. 'unsafe-eval' — script-src : eval, new Function, setTimeout(' var foo = "bar" ', 1)., javascript: - (onclick=""). style-src style="". , .. javascript , XSS. 'unsafe-eval' — script-src : eval, new Function, setTimeout(' var foo = "bar" ', 1).

होस्ट को केवल "yandex.st" रूप में निर्दिष्ट किया जा सकता है, और प्रोटोकॉल या पोर्ट के साथ "https://yandex.st:443" "yandex.st" "https://yandex.st:443" । याद रखें कि यदि होस्ट में प्रोटोकॉल या पोर्ट नहीं है, तो यह उसी मूल नीति के समान वर्तमान पृष्ठ से लिया गया है। इस प्रकार, "https://mail.yandex.ru:443/neo2/" पृष्ठ पर "yandex.st" होस्ट स्वचालित रूप से "https://yandex.st:443" "yandex.st" "https://yandex.st:443" फॉर्म "yandex.st" ।

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

हमने कैसे लागू किया

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

सार्वजनिक मेल के साथ यह थोड़ा अधिक कठिन था, क्योंकि एक अनियंत्रित वातावरण वाले उपयोगकर्ता हमारे पास आए थे। कई महीनों के लिए, हमने रिपोर्ट्स को छांटा, नीतियों को ठीक किया और आखिरकार, उन्हें ब्लॉकिंग मोड में गिरावट में 100% रोल आउट किया।

हमारे पास अब सबसे दिलचस्प बात वायरस, लापरवाह प्लगइन्स और एक्सटेंशन के उल्लंघन के साथ कई मिलियन दैनिक रिपोर्ट हैं जो हमारे पृष्ठों पर अपने कोड को एम्बेड करने का प्रयास करते हैं। हम इस कोड की सामग्री को नियंत्रित नहीं कर सकते हैं, जिसका अर्थ है कि हम इस बात की गारंटी नहीं दे सकते हैं कि यह हमारे उपयोगकर्ताओं के व्यक्तिगत डेटा को सावधानीपूर्वक व्यवहार करता है - और संतुष्ट हैं कि हम उनके निष्पादन को रोक रहे हैं।

इसके अलावा, कार्यान्वयन प्रक्रिया के दौरान, हमने CSP के साथ काम करने के लिए उपकरण विकसित किए:
- क्रोमियम-आधारित ब्राउज़रों के लिए एक एक्सटेंशन जो आपको एक पृष्ठ पर शीर्षक जोड़ने और नीतियों का परीक्षण करने की अनुमति देता है।
- अवरुद्ध संसाधनों की सूची प्राप्त करना आसान बनाने के लिए ब्राउज़र रिपोर्ट को पार्स करने की उपयोगिता ।
चलो मोबाइल Yandex.Mail के उदाहरण का उपयोग करके शीर्षक का विश्लेषण करें
```
 //     , yandex.st    WebSocket  xiva-daria.mail.yandex.net Content-Security-Policy: default-src 'self' wss://xiva-daria.mail.yandex.net yandex.st; //          frame-src *.yandex.ru; // 'self' data:  inline- // mc.yandex.ru — . // yandex.st —  CDN   // *.yandex.net -   https- img-src 'self' data: mc.yandex.ru *.yandex.net yandex.st; //       font-src 'none'; object-src 'none'; // 'unsafe-inline' —   inline-      // yandex.st —  CDN   style-src 'unsafe-inline' yandex.st; // self  blob —    js  blob // unsafe-eval      // mc.yandex.ru — . // yandex.st —  CDN   script-src 'self' 'unsafe-eval' blob: mc.yandex.ru yandex.st; //      report-uri /neo2/csp.jsx?from=touch 
```
एक सेवा पर सीएसपी को लागू करने के लिए एक नमूना योजना इस प्रकार है:
1. डाउनलोड करने योग्य संसाधनों की सूची का मूल्यांकन।
2. सामग्री-सुरक्षा-नीति-रिपोर्ट-केवल हेडर का कार्यान्वयन।
3. लॉग विश्लेषण।
4. नीति सुधार।
5. सामग्री-सुरक्षा-नीति शीर्षलेख (ब्लॉकिंग मोड पर स्विच करना) को लागू करना।
6. उपयोगकर्ता खुशी :)
लागू करते समय क्या विचार करें

ब्राउज़रों की विशेषताएं:
- X-Webkit-CSP शीर्षक के साथ Safari 5 और AndroidBrowser में मानक का बहुत खराब कार्यान्वयन है। और हम आपको सलाह देंगे कि आप इन ब्राउज़रों के लिए CSP का उपयोग बिल्कुल न करें। उदाहरण के लिए, वे असुरक्षित-eval और असुरक्षित-इनलाइन के नियमों को गलत समझते हैं।
- फ़ायरफ़ॉक्स की एक्स-सामग्री-सुरक्षा-नीति थोड़ा गैर-मानक निर्देशों को लागू करती है। कनेक्ट-src के बजाय, आपको xhr-src (या आप डिफ़ॉल्ट-src में नियम जोड़ सकते हैं) लिखने की आवश्यकता है। इसके अलावा, वह असुरक्षित-इनलाइन, असुरक्षित-eval नहीं समझता है, उनके बजाय आपको निर्देश "इनलाइन-स्क्रिप्ट eval-script" विकल्प जोड़ने की आवश्यकता है। मोज़िला विकि पर अपने स्वयं के हेडर कार्यान्वयन के बारे में और पढ़ें।
- फ़ायरफ़ॉक्स और एक्स-कंटेंट-सिक्योरिटी-पॉलिसी में रिपोर्ट-यूआई की समस्याएं हैं ।
- IOS6 में सफारी बहुत ही असंवेदनशील रिपोर्ट भेजता है।
हम कस्टम हेडर का उपयोग करने की अनुशंसा नहीं करते हैं। आधुनिक ब्राउज़रों के नवीनतम संस्करण (IE के अपवाद के साथ) मानक शीर्षक का समर्थन करते हैं, इसलिए केवल इसका उपयोग करके, आप दर्शकों के विशाल बहुमत को कवर करते हैं।

सीएसपी सुविधाओं को ध्यान में रखना:
- यदि आप इनलाइन चित्रों का उपयोग करते हैं, तो img-src में आपको "डेटा:" प्रोटोकॉल को सक्षम करने की आवश्यकता होती है।
- बूँद का उपयोग करना, 'स्वयं' (क्रोम के लिए) और बूँद निर्दिष्ट करें: (फ़ायरफ़ॉक्स और एक्स-वेबिट-सीएसपी के लिए)
- शीर्ष दस्तावेज़ का CSP बाल iframes को छोड़कर लागू नहीं होता है: रिक्त।
- यदि आप क्रोम एक्सटेंशन को ब्लॉक नहीं करना चाहते हैं, जो कि, नवीनतम संस्करणों से, सीएसपी पर भी रहते हैं, तो आपको "क्रोम-एक्सटेंशन:" प्रोटोकॉल को सक्षम करना होगा।
- डिफ़ॉल्ट-src सभी अनिर्दिष्ट निर्देशों पर लागू होता है, लेकिन यदि आप कुछ जोड़ना या हटाना चाहते हैं, तो आपको सभी डोमेन को फिर से निर्दिष्ट करना होगा।
- आप एक ही समय में सामग्री-सुरक्षा-नीति और सामग्री-सुरक्षा-नीति-रिपोर्ट-केवल निर्दिष्ट कर सकते हैं। दोनों हेडर स्वतंत्र रूप से काम करेंगे। यह दृष्टिकोण नई नीतियों के परीक्षण के लिए उपयोगी होगा।
- यदि आप फ़ीचर डिटेक्शन (उदाहरण के लिए, jQuery <1.8 या मॉडर्निज़र) के साथ चौखटे का उपयोग करते हैं, तो आपको स्टाइल-src के लिए 'असुरक्षित-इनलाइन' निर्दिष्ट करना होगा।
स्वाभाविक रूप से, यह हमेशा संभव नहीं होता है, लेकिन कोशिश करें * का उपयोग न करें, लेकिन डोमेन की सटीक सूची का संकेत दें। सभी निर्देशों को भी निर्दिष्ट करें, अन्यथा सभी त्रुटियों को डिफ़ॉल्ट-src में उल्लंघन के रूप में फेंक दिया जाएगा। बेशक, हेडर का आकार बढ़ जाएगा, लेकिन समस्याओं को ढूंढना बहुत आसान होगा।

दुर्भाग्य से, हम अभी तक असुरक्षित-इनलाइन को नहीं छोड़ पाए हैं। मेल में इनलाइन स्क्रिप्ट का उपयोग दो चीजों के लिए किया जाता है: सेटिंग्स जारी करना और महत्वपूर्ण जेएस (jQuery और बूटलोडर) की लोडिंग की जांच करना। और अगर हम सेटिंग्स को JSON में बदल सकते हैं, तो हम महत्वपूर्ण JS गैर-लोडिंग रिपोर्ट को मना नहीं कर सकते, और हमें 'असुरक्षित-इनलाइन' छोड़ना पड़ा। TinyMCE WYSWYG संपादक में इनलाइन विशेषताओं के उपयोग ने समस्याओं को भी जोड़ा।

यद्यपि यह नियम आपको पृष्ठ पर किसी भी इनलाइन जावास्क्रिप्ट को निष्पादित करने की अनुमति देता है, हम केवल विश्वसनीय संसाधनों के लिए कनेक्शन की अनुमति देकर खुद की रक्षा कर सकते हैं।

अपडेटेड मानक CSP 1.1

मानक का नया संस्करण वर्तमान में मसौदा चरण में है, लेकिन क्रोम और फ़ायरफ़ॉक्स पहले से ही इसकी नई विशेषताओं को पेश करना शुरू कर रहे हैं।

उदाहरण के लिए, नया गैर-निर्देश असुरक्षित-इनलाइन पर पूर्ण प्रतिबंध के साथ असुविधा का समाधान हो सकता है। कार्य योजना अभी भी चल रही है, लेकिन हम इसे निम्नानुसार बनाने के लिए प्रयास कर रहे हैं:
1. नॉन - हेडर में प्रेषित वर्णों का एक यादृच्छिक अनुक्रम;
2. यदि असुरक्षित-इनलाइन और नॉन हैं, तो नॉन असुरक्षित-इनलाइन को बंद कर देता है;
3. केवल इनलाइन स्क्रिप्ट निष्पादित की जाती हैं जो कि गैर-विशेषता वाले अक्षरों के समान अनुक्रम के साथ हस्ताक्षरित होती हैं।
एक उदाहरण:
```
 Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com 'nonce-eef8264c4994bf6409c51ac7c9614446' <script> alert(",   nonce") </script> <script nonce="22168992a8d57a5d3a64ca73bb9fc669"> alert(",    nonce  ") </script> <script nonce="eef8264c4994bf6409c51ac7c9614446"> alert(",    nonce ") </script>  <script src="https://example.com/allowed-because-of-src.js"></script>  <script nonce="22168992a8d57a5d3a64ca73bb9fc669" src="https://otherdomain.com/invalid.js"></script>  <script nonce="eef8264c4994bf6409c51ac7c9614446" src="https://otherdomain.com/valid.js"></script> 
```
CSP 1.1 में नई सुविधाएँ भी शामिल हैं:
- मेटा टैग के माध्यम से एक नीति निर्दिष्ट करना;
- नीतियों को प्राप्त करने और जांचने के लिए जावास्क्रिप्ट एपीआई;
- DOM पॉलिसी उल्लंघन घटना;
- नए निर्देश फॉर्म-एक्शन, प्लगइन-प्रकार।
निष्कर्ष में

सीएसपी केवल हमलों और अस्पष्ट अनुरोधों को रोकने के खिलाफ संरक्षण नहीं था। परीक्षण में, हमें दो चीजों से सुखद आश्चर्य हुआ:
1. संक्षेप में, CSP उपयोगकर्ताओं के कंप्यूटरों से वितरित सुरक्षा परीक्षण प्रणाली बनाना संभव बनाता है। और अगर उल्लंघन पर रिपोर्ट की संख्या तेजी से बढ़ जाती है, तो यह एक समस्या की तलाश में जाने का एक अवसर है।
2. चूंकि सभी मेल उपयोगकर्ता HTTPS का उपयोग करते हैं, इसलिए CSP ने उन एकांत स्थानों को ट्रैक करना और उन्हें ठीक करना संभव बना दिया, जिनमें अभी भी HTTP के माध्यम से अनुरोध भेजे गए थे।
CSP आज़माएं, कार्यान्वित करें, उपयोगकर्ताओं के व्यक्तिगत डेटा की सुरक्षा करें और दुनिया को बेहतर जगह बनाएं।

हमने ईमेल पढ़ने को कैसे सुरक्षित बनाया: Yandex.Mail में सामग्री सुरक्षा नीति

CSP से क्या बनता है?

हमने कैसे लागू किया

लागू करते समय क्या विचार करें

अपडेटेड मानक CSP 1.1

निष्कर्ष में

More articles: