Content-Security-Policyमेटा टैग आप के जोखिम को कम करने की अनुमति देता XSS जहां संसाधनों से लोड किया जा सकता, किसी भी अन्य स्थानों से डेटा लोड होने से ब्राउज़र को रोकने आप को परिभाषित करने की अनुमति देकर हमला करता है। इससे हमलावर के लिए आपकी साइट में दुर्भावनापूर्ण कोड इंजेक्ट करना कठिन हो जाता है।
मैंने एक ईंट की दीवार के खिलाफ अपना सिर पीटा, यह जानने की कोशिश कर रहा था कि मुझे एक के बाद एक सीएसपी त्रुटियां क्यों हो रही थीं, और यह कोई संक्षिप्त, स्पष्ट निर्देश नहीं था कि यह कैसे काम करता है। इसलिए यहाँ सीएसपी के कुछ बिंदुओं को संक्षेप में समझाने का मेरा प्रयास है , ज्यादातर उन चीज़ों पर ध्यान केंद्रित करना जिन्हें मैंने हल करना मुश्किल पाया।
संक्षिप्तता के लिए मैं प्रत्येक नमूने में पूर्ण टैग नहीं लिखूंगा। इसके बजाय मैं केवल contentसंपत्ति दिखाऊंगा , इसलिए एक नमूना जो कहता content="default-src 'self'"है कि इसका मतलब है:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
1. कई स्रोतों की अनुमति कैसे दें?
आप अंतरिक्ष अलग सूची के रूप में एक निर्देश के बाद बस अपने स्रोतों को सूचीबद्ध कर सकते हैं:
content="default-src 'self' https://example.com/js/"
ध्यान दें कि विशेष के अलावा मापदंडों के आसपास कोई उद्धरण नहीं है, जैसे 'self'। साथ ही, :निर्देश के बाद कोई कॉलन ( ) नहीं है । बस निर्देश, फिर मापदंडों की एक अलग-अलग सूची।
निर्दिष्ट मापदंडों के नीचे सब कुछ निहित है। इसका मतलब है कि इन उदाहरणों के ऊपर मान्य स्रोत होंगे:
https://example.com/js/file.js
https://example.com/js/subdir/anotherfile.js
हालांकि, ये मान्य नहीं होंगे:
http://example.com/js/file.js
^^^^ wrong protocol
https://example.com/file.js
^^ above the specified path
2. विभिन्न निर्देशों का उपयोग कैसे करें, वे प्रत्येक क्या करते हैं?
सबसे आम निर्देश हैं:
default-src जावास्क्रिप्ट, छवियों, सीएसएस, फोंट, AJAX अनुरोधों आदि को लोड करने के लिए डिफ़ॉल्ट नीतिscript-src जावास्क्रिप्ट फ़ाइलों के लिए वैध स्रोतों को परिभाषित करता हैstyle-src सीएसएस फ़ाइलों के लिए वैध स्रोतों को परिभाषित करता हैimg-src छवियों के लिए वैध स्रोतों को परिभाषित करता हैconnect-srcXMLHttpRequest (AJAX), WebSockets या EventSource के लिए मान्य लक्ष्यों को परिभाषित करता है। यदि एक कनेक्शन का प्रयास उस होस्ट को किया जाता है जिसे यहां अनुमति नहीं है, तो ब्राउज़र एक 400त्रुटि का अनुकरण करेगा
अन्य हैं, लेकिन ये वे हैं जिनकी आपको सबसे अधिक संभावना है।
3. कई निर्देशों का उपयोग कैसे करें?
आप अपने सभी निर्देशों को एक मेटा-टैग के अंदर एक अर्धविराम ( ;) के साथ समाप्त करके परिभाषित करते हैं :
content="default-src 'self' https://example.com/js/; style-src 'self'"
4. बंदरगाहों को कैसे संभालें?
अनुमत डोमेन के बाद पोर्ट नंबर या तारांकन जोड़कर सब कुछ लेकिन डिफ़ॉल्ट बंदरगाहों को स्पष्ट रूप से अनुमति देने की आवश्यकता है:
content="default-src 'self' https://ajax.googleapis.com http://example.com:123/free/stuff/"
उपरोक्त परिणाम होगा:
https://ajax.googleapis.com:123
^^^^ Not ok, wrong port
https://ajax.googleapis.com - OK
http://example.com/free/stuff/file.js
^^ Not ok, only the port 123 is allowed
http://example.com:123/free/stuff/file.js - OK
जैसा कि मैंने उल्लेख किया है, आप सभी बंदरगाहों को स्पष्ट रूप से अनुमति देने के लिए एक तारांकन चिह्न का उपयोग कर सकते हैं:
content="default-src example.com:*"
5. विभिन्न प्रोटोकॉल को कैसे संभालना है?
डिफ़ॉल्ट रूप से, केवल मानक प्रोटोकॉल की अनुमति है। उदाहरण के लिए WebSockets की अनुमति देने के लिए ws://आपको इसे स्पष्ट रूप से अनुमति देना होगा:
content="default-src 'self'; connect-src ws:; style-src 'self'"
^^^ web sockets are now allowed on all domains and ports
6. फाइल प्रोटोकॉल की अनुमति कैसे दें file://?
यदि आप इसे परिभाषित करने की कोशिश करेंगे जैसे कि यह काम नहीं करेगा। इसके बजाय, आप इसे filesystemपैरामीटर के साथ अनुमति देंगे :
content="default-src filesystem"
7. इनलाइन स्क्रिप्ट और स्टाइल परिभाषा का उपयोग कैसे करें?
जब तक स्पष्ट रूप से अनुमति नहीं दी जाती है, आप इनलाइन शैली परिभाषाओं का उपयोग नहीं कर सकते, कोड <script>टैग के अंदर या जैसे टैग गुणों में onclick। आप उन्हें ऐसा करने की अनुमति देते हैं:
content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"
आपको इनलाइन, बेस 64 एनकोडेड छवियों को स्पष्ट रूप से अनुमति देना होगा:
content="img-src data:"
8. कैसे अनुमति दें eval()?
मुझे यकीन है कि बहुत से लोग कहेंगे कि आप नहीं करते हैं, क्योंकि 'बुराई बुराई है' और दुनिया के आसन्न अंत का सबसे संभावित कारण है। वे लोग गलत होंगे। निश्चित रूप से, आप अपनी साइट की सुरक्षा में बड़े छेद को निश्चित रूप से निकाल सकते हैं, लेकिन इसमें पूरी तरह से वैध उपयोग के मामले हैं। बस आपको इसे इस्तेमाल करने में होशियार रहना होगा। आप इसे ऐसा करने की अनुमति देते हैं:
content="script-src 'unsafe-eval'"
9. वास्तव में क्या 'self'मतलब है?
आप 'self'स्थानीय होस्ट, स्थानीय फाइल सिस्टम या समान होस्ट पर कुछ भी ले सकते हैं । इसका कोई मतलब नहीं है। इसका मतलब उन स्रोतों से है जिनके पास समान योजना (प्रोटोकॉल), समान होस्ट और फ़ाइल नीति में परिभाषित की गई फ़ाइल के समान पोर्ट है, आपकी साइट को HTTP पर सेवा दे रहा है? तब तक आपके लिए कोई https नहीं, जब तक आप इसे स्पष्ट रूप से परिभाषित नहीं करते हैं।
मैंने 'self'ज्यादातर उदाहरणों में उपयोग किया है क्योंकि यह आमतौर पर इसे शामिल करने के लिए समझ में आता है, लेकिन यह अनिवार्य नहीं है। यदि आपको इसकी आवश्यकता नहीं है, तो इसे छोड़ दें।
लेकिन एक मिनट रुको! क्या मैं इसका उपयोग नहीं कर सकता content="default-src *"और इसके साथ किया जा सकता है?
स्पष्ट सुरक्षा कमजोरियों के अलावा, यह भी काम नहीं करेगा जैसा कि आप उम्मीद करेंगे। हालांकि कुछ डॉक्स दावा करते हैं कि यह कुछ भी अनुमति देता है, यह सच नहीं है। यह इनलाइनिंग या अपवित्र की अनुमति नहीं देता है, इसलिए वास्तव में, वास्तव में आपकी साइट को अतिरिक्त रूप से कमजोर बना देता है, आप इसका उपयोग करेंगे:
content="default-src * 'unsafe-inline' 'unsafe-eval'"
... लेकिन मुझे विश्वास है कि आप नहीं करेंगे।
आगे की पढाई:
http://content-security-policy.com
http://en.wikipedia.org/wiki/Content_Security_Policy