Chrome DevTools में सीएसपी और भरोसेमंद टाइप को डीबग करना लागू करना

Kateryna Prokopenko
Kateryna Prokopenko
GitHub
Alfonso Castaño
Alfonso Castaño

यह ब्लॉग पोस्ट हाल ही में पेश की गई समस्याएं टैब की मदद से कॉन्टेंट की सुरक्षा नीति (सीएसपी) की समस्याओं को डीबग करने के लिए, DevTools सहायता को लागू करने के बारे में है.

लागू करने का काम दो इंटर्नशिप के दौरान किया गया था: 1. पहले नियम में, हमने सामान्य रिपोर्टिंग फ़्रेमवर्क बनाया था. साथ ही, सीएसपी के उल्लंघन से जुड़ी तीन समस्याओं के लिए, समस्या के मैसेज डिज़ाइन किए थे. 2. दूसरे चरण में, हमने भरोसेमंद टाइप की डीबग करने की सुविधा के लिए, DevTools की कुछ खास सुविधाओं के साथ-साथ, भरोसेमंद टाइप से जुड़ी समस्याएं भी जोड़ी हैं.

कॉन्टेंट की सुरक्षा के बारे में नीति क्या है?

कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी) की मदद से, किसी वेबसाइट की कुछ खास गतिविधियों पर पाबंदी लगाई जा सकती है, ताकि उसकी सुरक्षा बढ़ाई जा सके. उदाहरण के लिए, सीएसपी का इस्तेमाल इनलाइन स्क्रिप्ट को अस्वीकार करने या eval को अनुमति न देने के लिए किया जा सकता है. ये दोनों तरीके, क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों के लिए, अटैक सरफ़ेस को कम करते हैं. सीएसपी के बारे में ज़्यादा जानकारी के लिए, यहां पढ़ें.

खास तौर पर, एक नया सीएसपी, भरोसेमंद टाइप(टीटी) की नीति है. इससे डाइनैमिक विश्लेषण की सुविधा मिलती है, जिससे वेबसाइटों पर बड़ी संख्या में इंजेक्शन वाले हमलों को रोका जा सकता है. इसे हासिल करने के लिए, TT अपने JavaScript कोड की निगरानी करने के लिए किसी वेबसाइट का समर्थन करता है, ताकि वह innerHTML जैसे कुछ खास प्रकार की चीज़ों को ही DOM सिंक को असाइन कर सके.

कोई वेबसाइट एक खास एचटीटीपी हेडर शामिल करके कॉन्टेंट की सुरक्षा नीति को चालू कर सकती है. उदाहरण के लिए, हेडर content-security-policy: require-trusted-types-for 'script'; trusted-types default अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी पेज के लिए TT नीति सक्रिय करता है.

हर नीति को इनमें से किसी एक मोड में लागू किया जा सकता है:

  • लागू होने वाला मोड - जहां हर नीति के उल्लंघन की स्थिति एक गड़बड़ी होती है,
  • रिपोर्ट-ओनली मोड - यह मोड, गड़बड़ी के मैसेज को चेतावनी के तौर पर रिपोर्ट करता है, लेकिन वेब पेज के काम करने के तरीके को नुकसान नहीं पहुंचाता.

समस्याएं टैब में जाकर, कॉन्टेंट की सुरक्षा के बारे में नीति से जुड़ी समस्याएं लागू करना

इस काम का मकसद, सीएसपी से जुड़ी समस्याओं के लिए डीबग करने के अनुभव को बेहतर बनाना था. नई समस्याओं पर विचार करते समय, DevTools टीम करीब-करीब इस प्रक्रिया को अपनाती है:

  1. लोगों की स्टोरी के बारे में जानकारी. DevTools फ़्रंट-एंड में, उपयोगकर्ता की कहानियों के ऐसे सेट की पहचान करें जिसमें बताया गया हो कि वेब डेवलपर को समस्या की जांच कैसे करनी होगी.
  2. फ़्रंट-एंड लागू करना. उपयोगकर्ताओं की कहानियों के आधार पर, यह तय करें कि फ़्रंट-एंड में समस्या की जांच करने के लिए, कौनसी जानकारी ज़रूरी है. उदाहरण के लिए, कोई मिलता-जुलता अनुरोध, किसी कुकी का नाम, स्क्रिप्ट या एचटीएमएल फ़ाइल की कोई लाइन वगैरह.
  3. समस्या का पता लगाना. ब्राउज़र में उन जगहों की पहचान करें जहां Chrome पर समस्या का पता लगाया जा सकता है. फिर, वह जगह बताएं जहां समस्या की शिकायत की जा सकती है. इसमें, दूसरे चरण में दी गई ज़रूरी जानकारी भी शामिल करें.
  4. समस्याओं को सेव करें और दिखाएं. समस्याओं को सही जगह पर सेव करें और ऐप्लिकेशन खोलने पर, उन्हें DevTools में उपलब्ध कराएं
  5. समस्या का टेक्स्ट डिज़ाइन करना. ज़्यादा जानकारी देने वाला ऐसा टेक्स्ट बनाओ जिससे वेब डेवलपर को समस्या को समझने और उसे हल करने में मदद मिले

पहला चरण: सीएसपी से जुड़ी समस्याओं के लिए उपयोगकर्ता की स्टोरी तय करना

लागू करने से पहले, हमने उपयोगकर्ताओं की कहानियों के साथ एक डिज़ाइन दस्तावेज़ बनाया. इससे हमें यह समझने में मदद मिली कि आगे क्या करना है. उदाहरण के लिए, हमने इस उपयोगकर्ता की कहानी लिखी:

एक डेवलपर के तौर पर, जिसे अभी-अभी पता चला कि मेरी वेबसाइट का कुछ हिस्सा ब्लॉक किया गया है, मैं चाहता/चाहती हूं कि:- - ...पता लगाएं कि क्या सीएसपी मेरी वेबसाइट पर ब्लॉक किए गए iframe / इमेज की वजह है - ...जानें कि किस सीएसपी डायरेक्टिव की वजह से, किसी खास रिसॉर्स को ब्लॉक किया जाता है - ...अपनी वेबसाइट के सीएसपी को बदलने का तरीका जानें, ताकि ब्लॉक किए गए मौजूदा संसाधनों को दिखाने या मौजूदा ब्लॉक किए गए js को चलाने की अनुमति मिल सके.

उपयोगकर्ता की इस कहानी के बारे में जानने के लिए, हमने उदाहरण के तौर पर कुछ ऐसे वेब पेज बनाए हैं जिनमें हमारी दिलचस्पी के मुताबिक, सीएसपी के उल्लंघन के बारे में जानकारी दी गई है. साथ ही, हमने इस प्रोसेस के बारे में जानने के लिए उदाहरण वाले पेजों को भी एक्सप्लोर किया है. यहां कुछ वेब पेजों के उदाहरण दिए गए हैं (समस्याएं टैब खुला हुआ डेमो खोलें):

इस प्रोसेस का इस्तेमाल करके, हमें पता चला कि सीएसपी से जुड़ी समस्याओं को डीबग करने के लिए, सोर्स की जगह की जानकारी सबसे अहम है. हमें इससे जुड़े iframe को तुरंत ढूंढने में भी मदद मिली. साथ ही, अगर किसी संसाधन को ब्लॉक किया गया था, तो अनुरोध भी किया जा सकता है. साथ ही, DevTools के Elements पैनल में एचटीएमएल एलिमेंट का सीधा लिंक भी काम आ सकता है.

दूसरा चरण: फ़्रंट-एंड को लागू करना

इस अहम जानकारी को, हमने उस जानकारी के पहले ड्राफ़्ट में बदल दिया है जिसे हम Chrome DevTools प्रोटोकॉल (सीडीपी) की मदद से DevTools को उपलब्ध कराना चाहते थे:

नीचे third_party/blink/public/devtools_protocol/browser_protocol.pdl का एक छोटा सा हिस्सा है

 type ContentSecurityPolicyIssueDetails extends object
   properties
     # The url not included in allowed sources.
     optional string blockedURL
     # Specific directive that is violated, causing the CSP issue.
     string violatedDirective
     boolean isReportOnly
     ContentSecurityPolicyViolationType contentSecurityPolicyViolationType
     optional AffectedFrame frameAncestor
     optional SourceCodeLocation sourceCodeLocation
     optional DOM.BackendNodeId violatingNodeId

ऊपर दी गई परिभाषा, ज़रूरी है कि JSON डेटा-स्ट्रक्चर को कोड में बदला गया हो. इसे PDL (प्रोटोकॉल डेटा लैंग्वेज) नाम की आसान भाषा में लिखा गया है. पीडीएल का इस्तेमाल दो कामों के लिए किया जाता है. सबसे पहले, हम पीडीएल का इस्तेमाल करके टाइपस्क्रिप्ट डेफ़िनिशन जनरेट करते हैं, जिस पर DevTools फ़्रंट-एंड भरोसा करता है. उदाहरण के लिए, ऊपर दी गई PDL परिभाषा इस टाइपस्क्रिप्ट इंटरफ़ेस को जनरेट करती है:

export interface ContentSecurityPolicyIssueDetails {
  /**
  * The url not included in allowed sources.
  */
  blockedURL?: string;
  /**
  * Specific directive that is violated, causing the CSP issue.
  */
  violatedDirective: string;
  isReportOnly: boolean;
  contentSecurityPolicyViolationType: ContentSecurityPolicyViolationType;
  frameAncestor?: AffectedFrame;
  sourceCodeLocation?: SourceCodeLocation;
  violatingNodeId?: DOM.BackendNodeId;
}

दूसरा, C++ लाइब्रेरी को उस डेफ़िनिशन से बनाया गया है जो C++ Chromium के बैक-एंड से DevTools फ़्रंट-एंड तक, डेटा स्ट्रक्चर को जनरेट और भेजने का काम मैनेज करती है. उस लाइब्रेरी का इस्तेमाल करके, C++ कोड के इस हिस्से का इस्तेमाल करके ContentSecurityPolicyIssueDetails ऑब्जेक्ट बनाया जा सकता है:

protocol::Audits::ContentSecurityPolicyIssueDetails::create()
  .setViolatedDirective(d->violated_directive)
  .setIsReportOnly(d->is_report_only)
  .setContentSecurityPolicyViolationType(BuildViolationType(
      d->content_security_policy_violation_type)))
  .build();

यह तय करने के बाद कि हमें कौनसी जानकारी उपलब्ध करानी है, हमें यह पता लगाना था कि Chromium से यह जानकारी कहां से ली जाए.

तीसरा चरण: समस्या का पता लगाना

पिछले सेक्शन में बताए गए फ़ॉर्मैट में, Chrome DevTools प्रोटोकॉल (सीडीपी) में जानकारी उपलब्ध कराने के लिए, हमें वह जगह ढूंढनी थी जहां बैक-एंड में जानकारी उपलब्ध थी. अच्छी बात यह है कि सीएसपी कोड में पहले से ही रिपोर्ट-ओनली मोड के लिए एक बॉटल-नेक उपलब्ध है, जहां से हम इसकी जांच कर सकते हैं: ContentSecurityPolicy::ReportViolation रिपोर्टिंग के आखिरी पॉइंट से जुड़ी समस्याओं की रिपोर्ट (ज़रूरी नहीं) करता है. इस रिपोर्ट को सीएसपी एचटीटीपी हेडर में कॉन्फ़िगर किया जा सकता है. हम जिस जानकारी की रिपोर्ट करना चाहते थे, वह पहले से ही उपलब्ध थी, इसलिए हमारे इंस्ट्रुमेंट के काम करने के लिए बैक-एंड में कोई बड़ा बदलाव करने की ज़रूरत नहीं थी.

चौथा चरण: समस्याओं को सेव करना और दिखाना

इसमें एक छोटी सी समस्या यह है कि हम उन समस्याओं की भी शिकायत करना चाहते थे जो DevTools खोलने से पहले हुई थीं. यह ठीक उसी तरह होता है जैसे कंसोल मैसेज को हैंडल किया जाता है. इसका मतलब है कि हम समस्याओं की शिकायत सीधे फ़्रंट-एंड नहीं करते. हालांकि, हम ऐसे स्टोरेज का इस्तेमाल करते हैं जिसमें समस्याओं की जानकारी अपने-आप भरी जाती है. इससे कोई फ़र्क़ नहीं पड़ता कि DevTools खुला है या नहीं. DevTools खुलने के बाद (या इस मामले में, कोई दूसरा सीडीपी क्लाइंट अटैच होने पर), पहले रिकॉर्ड की गई सभी समस्याओं को स्टोरेज से फिर से देखा जा सकता है.

इसके बाद, बैक-एंड पर काम खत्म हो गया. अब हमें इस बात पर फ़ोकस करना था कि इस समस्या को फ़्रंट-एंड (प्रज़ेंटेशन लेयर) के ज़रिए कैसे दिखाया जाए.

पांचवां चरण: समस्याओं के लिए टेक्स्ट डिज़ाइन करना

समस्याओं का टेक्स्ट डिज़ाइन करना एक ऐसी प्रोसेस है जिसमें हमारी अनुमतियों के अलावा, कई टीमें शामिल होती हैं. उदाहरण के लिए, हम अक्सर किसी सुविधा (इस मामले में सीएसपी टीम) को लागू करने वाली टीम से मिली जानकारी पर भरोसा करते हैं. साथ ही, हम DevRel टीम की मदद से डिज़ाइन करते हैं, जो किसी खास तरह की समस्या से निपटने के लिए वेब डेवलपर को डिज़ाइन करती है. आम तौर पर, समस्या वाले टेक्स्ट को बेहतर बनाने में कुछ समय लगता है. ऐसा तब तक होता है, जब तक वह पूरा नहीं हो जाता.

आम तौर पर, DevTools टीम अपनी कल्पना के बारे में एक रफ़ ड्राफ़्ट के साथ शुरुआत करती है:


## Header
Content Security Policy: include all sources of your resources in content security policy header to improve the functioning of your site

## General information
Even though some sources are included in the content security policy header, some resources accessed by your site like images, stylesheets or scripts originate from sources not included in content security policy directives.

Usage of content from not included sources is restricted to strengthen the security of your entire site.

## Specific information

### VIOLATED DIRECTIVES
`img-src 'self'`

### BLOCKED URLs
https://imgur.com/JuXCo1p.jpg

## Specific information
https://web.dev/strict-csp/

फिर से करने के बाद, हम यहां पहुंच गए:

ALT_TEXT_HERE

जैसा कि आपको दिख रहा है, फ़ीचर टीम और DevRel को शामिल करने से वीडियो का ब्यौरा ज़्यादा साफ़ और सटीक हो जाता है!

आपके पेज पर सीएसपी की समस्याएं, खास तौर पर सीएसपी के उल्लंघनों के लिए बने टैब में भी देखी जा सकती हैं.

भरोसेमंद टाइप की समस्याओं को डीबग करना

सही डेवलपर टूल के बिना, TT के साथ बड़े स्तर पर काम करना चुनौती भरा हो सकता है.

कंसोल से प्रिंट करने की बेहतर सुविधा

जब हम भरोसेमंद ऑब्जेक्ट के साथ काम करते हैं, तो हम कम से कम उतनी ही जानकारी दिखाना चाहते हैं जितनी गैर-भरोसेमंद समकक्ष के लिए होती है. माफ़ करें, फ़िलहाल किसी भरोसेमंद ऑब्जेक्ट को दिखाते समय, रैप किए गए ऑब्जेक्ट के बारे में कोई जानकारी नहीं दिखती.

ऐसा इसलिए होता है, क्योंकि कंसोल में दिखाई जाने वाली वैल्यू, डिफ़ॉल्ट रूप से ऑब्जेक्ट पर .valueOf() को कॉल करने से ली जाती है. हालांकि, भरोसेमंद टाइप के मामले में, दिखाई गई वैल्यू ज़्यादा काम की नहीं होती. इसके बजाय, हम आपसे कुछ मिलती-जुलती जानकारी चाहते हैं. यह सुविधा आपको .toString() पर कॉल करने पर मिलती है. इसे पाने के लिए, हमें V8 और Blink में बदलाव करना होगा, ताकि भरोसेमंद टाइप के ऑब्जेक्ट के लिए खास तरीके से हैंडलिंग की सुविधा शुरू की जा सके.

हालांकि, पुरानी वजहों से V8 में कस्टम हैंडलिंग का इस्तेमाल किया गया था. हालांकि, इस तरीके के अहम नुकसान हैं. ऐसे कई ऑब्जेक्ट हैं जिन्हें कस्टम तरीके से दिखाने की ज़रूरत होती है, लेकिन उनका टाइप JS लेवल पर एक जैसा है. V8 पूरी तरह JS है. इसलिए, यह Web API से जुड़े कॉन्सेप्ट को अलग नहीं कर सकता, जैसे कि ट्रस्टेड टाइप. इस वजह से, V8 को इन दोनों के बीच के अंतर से जुड़ी मदद पाने के लिए, अपने एम्बेडर (ब्लिंक) से मदद लेनी होगी.

इसलिए, कोड के उस भाग को Blink या किसी एम्बेडर पर ले जाना एक तार्किक विकल्प की तरह लगता है. इस समस्या के अलावा, इसके और भी कई फ़ायदे हैं:

  • हर एम्बेडर के पास जानकारी जनरेट करने की सुविधा हो सकती है
  • Blink API की मदद से, जानकारी को आसानी से जनरेट किया जा सकता है
  • ब्लिंक के पास ऑब्जेक्ट की ओरिजनल डेफ़िनिशन का ऐक्सेस है. इसलिए, अगर हम जानकारी जनरेट करने के लिए .toString() का इस्तेमाल करते हैं, तो .toString() को फिर से तय किए जाने का कोई जोखिम नहीं है.

उल्लंघन करके उल्लंघन करना (रिपोर्ट सिर्फ़ रिपोर्ट मोड में)

फ़िलहाल, टीटी के उल्लंघनों को डीबग करने का सिर्फ़ एक तरीका JS अपवादों पर ब्रेकपॉइंट सेट करना है. चूंकि TT नीति उल्लंघन के मामले में एक अपवाद ट्रिगर होगा, इसलिए यह सुविधा किसी भी तरह से उपयोगी हो सकती है. हालांकि, असल दुनिया में आपको TT के उल्लंघनों पर ज़्यादा बारीकी से कंट्रोल करने की ज़रूरत होती है. खास तौर पर, हम सिर्फ़ TT के उल्लंघन (अन्य अपवाद नहीं) को तोड़ना चाहेंगे, सिर्फ़ रिपोर्ट मोड में तोड़ना चाहते हैं, और अलग-अलग तरह के TT के उल्लंघनों में अंतर करना चाहते हैं.

DevTools पहले से ही कई तरह के ब्रेकपॉइंट के लिए काम करता है. इसलिए, इसका आर्किटेक्चर बहुत बड़ा है. नया ब्रेकपॉइंट टाइप जोड़ने के लिए, बैकएंड (Blink), सीडीपी, और फ़्रंटएंड में बदलाव करना ज़रूरी है. हमें एक नया सीडीपी कमांड लागू करना चाहिए. चलिए, इसे setBreakOnTTViolation कहते हैं. फ़्रंटएंड को यह बताने के लिए इस निर्देश का इस्तेमाल किया जाएगा कि टीटी को किस तरह के उल्लंघन होने चाहिए. खास तौर पर InspectorDOMDebuggerAgent, बैकएंड में एक "जांच" होगी. onTTViolation() इसे हर बार टीटी का उल्लंघन होने पर कॉल किया जाएगा. इसके बाद, InspectorDOMDebuggerAgent जांच करेगा कि इस उल्लंघन से ब्रेकपॉइंट ट्रिगर होना चाहिए या नहीं. अगर ऐसा है, तो यह ऐक्शन को रोकने के लिए फ़्रंटएंड को मैसेज भेजेगा.

इस बदलाव को लागू करने के लिए क्या किया जा सकता है और आगे क्या करना है?

यहां बताई गई समस्याएं सामने आने की वजह से, समस्याएं टैब में कुछ बदलाव किए गए हैं:

आने वाले समय में, हम और ज़्यादा समस्याएं दिखाने के लिए, समस्याएं टैब का इस्तेमाल करेंगे. इससे, गड़बड़ी के मैसेज के उस फ़्लो के Console को अनलोड किया जा सकेगा जिसे लंबे समय तक नहीं पढ़ा जा सकता.

झलक दिखाने वाले चैनलों को डाउनलोड करें

Chrome Canary, Dev या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. झलक दिखाने वाले इन चैनलों की मदद से, DevTools की नई सुविधाओं को ऐक्सेस किया जा सकता है और वेब प्लैटफ़ॉर्म के बेहतरीन एपीआई की जांच की जा सकती है. साथ ही, उपयोगकर्ताओं से पहले ही अपनी साइट की समस्याओं का पता लगाया जा सकता है!

Chrome DevTools की टीम से संपर्क करना

पोस्ट में नई सुविधाओं और बदलावों या DevTools से जुड़ी किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, नीचे दिए गए विकल्पों का इस्तेमाल करें.

  • crbug.com के ज़रिए हमें कोई सुझाव या फ़ीडबैक सबमिट करें.
  • ज़्यादा विकल्प   ज़्यादा दिखाएँ > का इस्तेमाल करके DevTools से जुड़ी समस्या की शिकायत करें सहायता > DevTools में DevTools से जुड़ी समस्याओं की शिकायत करें.
  • @ChromeDevTools पर ट्वीट करें.
  • DevTools YouTube वीडियो या DevTools के बारे में सलाह YouTube वीडियो में नया क्या है, इस पर टिप्पणी करें.