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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हमने इस अहम जानकारी को उस जानकारी के पहले ड्राफ़्ट में बदला है जिसे हम 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 फ़ॉर्मैट में डेटा के स्ट्रक्चर को ज़रूरी रूप से एन्कोड किया गया है. यह एक आसान भाषा में लिखा होता है. इसे पीडीएल (प्रोटोकॉल डेटा की भाषा) कहते हैं. पीडीएल का इस्तेमाल दो कामों के लिए किया जाता है. सबसे पहले, हम पीडीएल का इस्तेमाल ऐसी TypeScript परिभाषाएं जनरेट करने के लिए करते हैं जिन पर DevTools फ़्रंट-एंड भरोसा करता है. उदाहरण के लिए, ऊपर दी गई पीडीएल परिभाषा से नीचे दिया गया 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 प्रोटोकॉल (सीडीपी) को आखिरी सेक्शन में बताए गए फ़ॉर्मैट में जानकारी उपलब्ध कराने के लिए, हमें वह जगह ढूंढना था जहां वह जानकारी असल में बैक-एंड में उपलब्ध थी. अच्छी बात यह है कि सीएसपी कोड में पहले से ही एक बॉटल-नेक है, जिसे सिर्फ़ रिपोर्ट मोड के लिए इस्तेमाल किया जा सकता है. इसे इस्तेमाल करके: 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 में बदलाव करना होगा, ताकि भरोसेमंद टाइप के ऑब्जेक्ट के लिए, खास हैंडलिंग की सुविधा पेश की जा सके.

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

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

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

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

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

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

अभी क्या हुआ है और आगे क्या होगा?

यहां बताई गई समस्याओं को पहली बार पेश किए जाने के बाद, समस्याएं टैब में काफ़ी बदलाव हुए हैं:

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

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

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

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

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

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