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 किसी पेज के लिए टीटी नीति को चालू करता है.

हर नीति इनमें से किसी एक मोड में काम कर सकती है:

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

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

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

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

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

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

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

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

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

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

हमने इस अहम जानकारी को, Chrome DevTools Protocol (CDP) के ज़रिए 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 का इस्तेमाल दो कामों के लिए किया जाता है. सबसे पहले, हम PDL का इस्तेमाल करके TypeScript की परिभाषाएं जनरेट करते हैं. DevTools का फ़्रंट-एंड इन परिभाषाओं पर निर्भर करता है. उदाहरण के लिए, ऊपर दी गई PDL परिभाषा, TypeScript इंटरफ़ेस को जनरेट करती है:

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 प्रोटोकॉल (CDP) के लिए जानकारी उपलब्ध कराने के लिए, हमें वह जगह ढूंढनी थी जहां बैक-एंड में जानकारी उपलब्ध थी. अच्छी बात यह है कि सीएसपी कोड में पहले से ही रिपोर्ट-ओनली मोड के लिए एक बॉटल-नेक उपलब्ध है, जहां से हम इसकी जांच कर सकते हैं: 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

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

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

Trusted Types से जुड़ी समस्याओं को डीबग करना

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

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

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

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

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

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

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

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

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

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

क्या हो चुका है और आगे क्या करना है?

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

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

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

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

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

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