hacktricks/pentesting-web/browser-extension-pentesting-methodology

Browser Extension Pentesting Methodology

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Basic Information

ब्राउज़र एक्सटेंशन जावास्क्रिप्ट में लिखे जाते हैं और ब्राउज़र द्वारा बैकग्राउंड में लोड किए जाते हैं। इसका DOM होता है लेकिन यह अन्य साइटों के DOM के साथ इंटरैक्ट कर सकता है। इसका मतलब है कि यह अन्य साइटों की गोपनीयता, अखंडता और उपलब्धता (CIA) को खतरे में डाल सकता है।

Main Components

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

http://webblaze.cs.berkeley.edu/papers/Extensions.pdf

Content Scripts

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

Extension Core

एक्सटेंशन कोर में अधिकांश एक्सटेंशन विशेषाधिकार/पहुँच होती है, लेकिन एक्सटेंशन कोर केवल XMLHttpRequest और कंटेंट स्क्रिप्ट के माध्यम से वेब सामग्री के साथ इंटरैक्ट कर सकता है। इसके अलावा, एक्सटेंशन कोर के पास होस्ट मशीन तक सीधी पहुंच नहीं होती है।

Native Binary

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

Boundaries

{% hint style="danger" %} उपयोगकर्ता के पूर्ण विशेषाधिकार प्राप्त करने के लिए, एक हमलावर को एक्सटेंशन को यह मनाने की आवश्यकता होती है कि वह कंटेंट स्क्रिप्ट से दुर्भावनापूर्ण इनपुट को एक्सटेंशन के कोर में और एक्सटेंशन के कोर से नैटिव बाइनरी में पास करे। {% endhint %}

एक्सटेंशन का प्रत्येक घटक एक-दूसरे से मजबूत सुरक्षात्मक सीमाओं द्वारा अलग होता है। प्रत्येक घटक अलग ऑपरेटिंग सिस्टम प्रक्रिया में चलता है। कंटेंट स्क्रिप्ट और एक्सटेंशन कोर सैंडबॉक्स प्रक्रियाओं में चलते हैं जो अधिकांश ऑपरेटिंग सिस्टम सेवाओं के लिए अनुपलब्ध हैं।

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

manifest.json

एक क्रोम एक्सटेंशन बस एक ज़िप फ़ोल्डर है जिसमें .crx फ़ाइल एक्सटेंशन होता है। एक्सटेंशन का कोर फ़ोल्डर के रूट में manifest.json फ़ाइल है, जो लेआउट, अनुमतियों और अन्य कॉन्फ़िगरेशन विकल्पों को निर्दिष्ट करता है।

Example:

{
"manifest_version": 2,
"name": "My extension",
"version": "1.0",
"permissions": [
"storage"
],
"content_scripts": [
{
"js": [
"script.js"
],
"matches": [
"https://example.com/*",
"https://www.example.com/*"
],
"exclude_matches": ["*://*/*business*"],
}
],
"background": {
"scripts": [
"background.js"
]
},
"options_ui": {
"page": "options.html"
}
}

content_scripts

कंटेंट स्क्रिप्ट्स लोड होती हैं जब भी उपयोगकर्ता मिलते-जुलते पृष्ठ पर जाते हैं, हमारे मामले में कोई भी पृष्ठ जो https://example.com/* अभिव्यक्ति से मेल खाता है और *://*/*/business* regex से मेल नहीं खाता। ये पृष्ठ के अपने स्क्रिप्ट्स की तरह कार्यान्वित होती हैं और पृष्ठ के डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM) तक मनमाना पहुंच होती है।

"content_scripts": [
{
"js": [
"script.js"
],
"matches": [
"https://example.com/*",
"https://www.example.com/*"
],
"exclude_matches": ["*://*/*business*"],
}
],

अधिक URLs को शामिल या बाहर करने के लिए include_globs और exclude_globs का उपयोग करना भी संभव है।

यह एक उदाहरण सामग्री स्क्रिप्ट है जो पृष्ठ पर एक व्याख्या बटन जोड़ेगी जब स्टोरेज API का उपयोग करके एक्सटेंशन के स्टोरेज से message मान प्राप्त किया जाएगा।

chrome.storage.local.get("message", result =>
{
let div = document.createElement("div");
div.innerHTML = result.message + " <button>Explain</button>";
div.querySelector("button").addEventListener("click", () =>
{
chrome.runtime.sendMessage("explain");
});
document.body.appendChild(div);
});

जब इस बटन पर क्लिक किया जाता है, तो सामग्री स्क्रिप्ट द्वारा एक्सटेंशन पृष्ठों को एक संदेश भेजा जाता है, runtime.sendMessage() API का उपयोग करके। यह सामग्री स्क्रिप्ट की APIs तक सीधे पहुंच की सीमा के कारण है, जिसमें storage कुछ अपवादों में से एक है। इन अपवादों से परे कार्यक्षमताओं के लिए, संदेश एक्सटेंशन पृष्ठों पर भेजे जाते हैं जिनसे सामग्री स्क्रिप्ट संवाद कर सकती हैं।

{% hint style="warning" %} ब्राउज़र के आधार पर, सामग्री स्क्रिप्ट की क्षमताएँ थोड़ी भिन्न हो सकती हैं। क्रोमियम-आधारित ब्राउज़रों के लिए, क्षमताओं की सूची Chrome Developers documentation में उपलब्ध है, और फ़ायरफ़ॉक्स के लिए, MDN प्राथमिक स्रोत के रूप में कार्य करता है।
यह भी ध्यान देने योग्य है कि सामग्री स्क्रिप्ट के पास बैकग्राउंड स्क्रिप्ट के साथ संवाद करने की क्षमता होती है, जिससे उन्हें क्रियाएँ करने और प्रतिक्रियाएँ वापस भेजने की अनुमति मिलती है। {% endhint %}

Chrome में सामग्री स्क्रिप्ट को देखने और डिबग करने के लिए, Chrome डेवलपर टूल मेनू को Options > More tools > Developer tools से या Ctrl + Shift + I दबाकर एक्सेस किया जा सकता है।

डेवलपर टूल प्रदर्शित होने पर, Source tab पर क्लिक किया जाना चाहिए, उसके बाद Content Scripts टैब। यह विभिन्न एक्सटेंशनों से चल रही सामग्री स्क्रिप्ट को देखने और निष्पादन प्रवाह को ट्रैक करने के लिए ब्रेकपॉइंट सेट करने की अनुमति देता है।

Injected content scripts

{% hint style="success" %} ध्यान दें कि Content Scripts अनिवार्य नहीं हैं क्योंकि यह डायनामिकली inject स्क्रिप्ट करने और tabs.executeScript के माध्यम से वेब पृष्ठों में प्रोग्रामेटिकली उन्हें inject करने की भी संभावना है। यह वास्तव में अधिक granular controls प्रदान करता है। {% endhint %}

एक सामग्री स्क्रिप्ट के प्रोग्रामेटिक इंजेक्शन के लिए, एक्सटेंशन को उस पृष्ठ के लिए host permissions की आवश्यकता होती है जिसमें स्क्रिप्ट को इंजेक्ट किया जाना है। ये अनुमतियाँ या तो एक्सटेंशन के मैनिफेस्ट में उनकी मांग करके या activeTab के माध्यम से अस्थायी आधार पर सुरक्षित की जा सकती हैं।

Example activeTab-based extension

{% code title="manifest.json" %}

{
"name": "My extension",
...
"permissions": [
"activeTab",
"scripting"
],
"background": {
"service_worker": "background.js"
},
"action": {
"default_title": "Action Button"
}
}

{% endcode %}

• क्लिक पर एक JS फ़ाइल इंजेक्ट करें:

// content-script.js
document.body.style.backgroundColor = "orange";

//service-worker.js - Inject the JS file
chrome.action.onClicked.addListener((tab) => {
chrome.scripting.executeScript({
target: { tabId: tab.id },
files: ["content-script.js"]
});
});

• क्लिक पर एक फ़ंक्शन इंजेक्ट करें:

//service-worker.js - Inject a function
function injectedFunction() {
document.body.style.backgroundColor = "orange";
}

chrome.action.onClicked.addListener((tab) => {
chrome.scripting.executeScript({
target : {tabId : tab.id},
func : injectedFunction,
});
});

स्क्रिप्टिंग अनुमतियों के साथ उदाहरण

// service-workser.js
chrome.scripting.registerContentScripts([{
id : "test",
matches : [ "https://*.example.com/*" ],
excludeMatches : [ "*://*/*business*" ],
js : [ "contentScript.js" ],
}]);

// Another example
chrome.tabs.executeScript(tabId, { file: "content_script.js" });

URLs को शामिल या बाहर करने के लिए include_globs और exclude_globs का उपयोग करना भी संभव है।

सामग्री स्क्रिप्ट run_at

run_at फ़ील्ड यह नियंत्रित करती है कि JavaScript फ़ाइलें वेब पृष्ठ में कब इंजेक्ट की जाती हैं। पसंदीदा और डिफ़ॉल्ट मान "document_idle" है।

संभावित मान हैं:

• document_idle: जब भी संभव हो
• document_start: css से किसी भी फ़ाइल के बाद, लेकिन किसी अन्य DOM के निर्माण या किसी अन्य स्क्रिप्ट के चलने से पहले।
• document_end: DOM के पूर्ण होने के तुरंत बाद, लेकिन छवियों और फ़्रेम जैसी उप-संसाधनों के लोड होने से पहले।

manifest.json के माध्यम से

{
"name": "My extension",
...
"content_scripts": [
{
"matches": ["https://*.example.com/*"],
"run_at": "document_idle",
"js": ["contentScript.js"]
}
],
...
}

service-worker.js के माध्यम से

chrome.scripting.registerContentScripts([{
id : "test",
matches : [ "https://*.example.com/*" ],
runAt : "document_idle",
js : [ "contentScript.js" ],
}]);

background

सामग्री स्क्रिप्ट द्वारा भेजे गए संदेश बैकग्राउंड पेज द्वारा प्राप्त होते हैं, जो एक्सटेंशन के घटकों के समन्वय में एक केंद्रीय भूमिका निभाता है। विशेष रूप से, बैकग्राउंड पेज एक्सटेंशन के जीवनकाल के दौरान बना रहता है, सीधे उपयोगकर्ता इंटरैक्शन के बिना काम करता है। इसमें अपना खुद का डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM) होता है, जो जटिल इंटरैक्शन और स्थिति प्रबंधन को सक्षम बनाता है।

मुख्य बिंदु:

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

{% hint style="success" %} ब्राउज़र द्वारा स्वचालित रूप से बैकग्राउंड पेज उत्पन्न करने की सुविधा (जब स्पष्ट रूप से घोषित नहीं किया गया हो) यह सुनिश्चित करती है कि सभी आवश्यक बैकग्राउंड स्क्रिप्ट एकीकृत और कार्यशील हैं, जिससे एक्सटेंशन की सेटअप प्रक्रिया को सरल बनाया जा सके। {% endhint %}

Example background script:

chrome.runtime.onMessage.addListener((request, sender, sendResponse) =>
{
if (request == "explain")
{
chrome.tabs.create({ url: "https://example.net/explanation" });
}
})

यह runtime.onMessage API का उपयोग संदेशों को सुनने के लिए करता है। जब एक "explain" संदेश प्राप्त होता है, तो यह tabs API का उपयोग करके एक नए टैब में एक पृष्ठ खोलता है।

बैकग्राउंड स्क्रिप्ट को डिबग करने के लिए आप एक्सटेंशन विवरण पर जा सकते हैं और सेवा कार्यकर्ता का निरीक्षण कर सकते हैं, इससे बैकग्राउंड स्क्रिप्ट के साथ डेवलपर टूल्स खुलेंगे:

विकल्प पृष्ठ और अन्य

ब्राउज़र एक्सटेंशन में विभिन्न प्रकार के पृष्ठ हो सकते हैं:

• एक्शन पृष्ठ तब प्रदर्शित होते हैं जब एक्सटेंशन आइकन पर क्लिक किया जाता है।
• पृष्ठ जो एक्सटेंशन एक नए टैब में लोड करेगा।
• विकल्प पृष्ठ: यह पृष्ठ क्लिक करने पर एक्सटेंशन के शीर्ष पर प्रदर्शित होता है। पिछले मैनिफेस्ट में, मैं इस पृष्ठ तक chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca में पहुँचने में सक्षम था या क्लिक करके:

ध्यान दें कि ये पृष्ठ बैकग्राउंड पृष्ठों की तरह स्थायी नहीं होते हैं क्योंकि वे आवश्यकता के अनुसार गतिशील सामग्री लोड करते हैं। इसके बावजूद, वे बैकग्राउंड पृष्ठ के साथ कुछ क्षमताएँ साझा करते हैं:

• सामग्री स्क्रिप्ट के साथ संचार: बैकग्राउंड पृष्ठ के समान, ये पृष्ठ सामग्री स्क्रिप्ट से संदेश प्राप्त कर सकते हैं, जो एक्सटेंशन के भीतर इंटरैक्शन को सुविधाजनक बनाता है।
• एक्सटेंशन-विशिष्ट APIs तक पहुँच: इन पृष्ठों को एक्सटेंशन-विशिष्ट APIs तक व्यापक पहुँच प्राप्त होती है, जो एक्सटेंशन के लिए परिभाषित अनुमतियों के अधीन होती है।

permissions & host_permissions

permissions और host_permissions manifest.json से प्रविष्टियाँ हैं जो यह संकेत करेंगी कि ब्राउज़र एक्सटेंशन के पास कौन सी अनुमतियाँ हैं (स्टोरेज, स्थान...) और कौन से वेब पृष्ठों में।

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

जांचें कि ये सेटिंग्स कैसे काम करती हैं और कैसे इनका दुरुपयोग किया जा सकता है:

{% content-ref url="browext-permissions-and-host_permissions.md" %} browext-permissions-and-host_permissions.md {% endcontent-ref %}

content_security_policy

एक सामग्री सुरक्षा नीति को manifest.json के अंदर भी घोषित किया जा सकता है। यदि कोई परिभाषित है, तो यह कमजोर हो सकता है।

ब्राउज़र एक्सटेंशन पृष्ठों के लिए डिफ़ॉल्ट सेटिंग काफी प्रतिबंधात्मक है:

script-src 'self'; object-src 'self';

CSP और संभावित बायपास के बारे में अधिक जानकारी के लिए देखें:

{% content-ref url="../content-security-policy-csp-bypass/" %} content-security-policy-csp-bypass {% endcontent-ref %}

web_accessible_resources

किसी वेबपेज को ब्राउज़र एक्सटेंशन के एक पृष्ठ, जैसे कि .html पृष्ठ, तक पहुँचने के लिए, इस पृष्ठ को manifest.json के web_accessible_resources क्षेत्र में उल्लेखित होना चाहिए।
उदाहरण के लिए:

{
...
"web_accessible_resources": [
{
"resources": [ "images/*.png" ],
"matches": [ "https://example.com/*" ]
},
{
"resources": [ "fonts/*.woff" ],
"matches": [ "https://example.com/*" ]
}
],
...
}

ये पृष्ठ URL में इस तरह से पहुँच योग्य हैं:

chrome-extension://<extension-id>/message.html

In सार्वजनिक एक्सटेंशनों में extension-id उपलब्ध है:

हालांकि, यदि manifest.json पैरामीटर use_dynamic_url का उपयोग किया जाता है, तो यह id गतिशील हो सकता है।

{% hint style="success" %} ध्यान दें कि यहां एक पृष्ठ का उल्लेख होने पर भी, यह ClickJacking के खिलाफ सुरक्षित हो सकता है धन्यवाद Content Security Policy के। इसलिए ClickJacking हमले की पुष्टि करने से पहले आपको इसे भी जांचना होगा (frame-ancestors अनुभाग)। {% endhint %}

इन पृष्ठों तक पहुँचने की अनुमति होने से ये पृष्ठ संभावित रूप से कमजोर ClickJacking बन जाते हैं:

{% content-ref url="browext-clickjacking.md" %} browext-clickjacking.md {% endcontent-ref %}

{% hint style="success" %} इन पृष्ठों को केवल एक्सटेंशन द्वारा लोड करने की अनुमति देना और यादृच्छिक URLs द्वारा नहीं, ClickJacking हमलों को रोक सकता है। {% endhint %}

{% hint style="danger" %} ध्यान दें कि web_accessible_resources से पृष्ठ और एक्सटेंशन के अन्य पृष्ठ भी पृष्ठभूमि स्क्रिप्ट से संपर्क करने में सक्षम हैं। इसलिए यदि इनमें से कोई पृष्ठ XSS के लिए कमजोर है, तो यह एक बड़ी कमजोरी खोल सकता है।

इसके अलावा, ध्यान दें कि आप केवल web_accessible_resources में निर्दिष्ट पृष्ठों को iframes के अंदर खोल सकते हैं, लेकिन एक नए टैब से आप एक्सटेंशन ID जानकर एक्सटेंशन में किसी भी पृष्ठ तक पहुँच सकते हैं। इसलिए, यदि एक XSS पाया जाता है जो समान पैरामीटर का दुरुपयोग करता है, तो इसका दुरुपयोग किया जा सकता है भले ही पृष्ठ web_accessible_resources में कॉन्फ़िगर न किया गया हो। {% endhint %}

externally_connectable

docs के अनुसार, "externally_connectable" मैनिफेस्ट प्रॉपर्टी यह घोषित करती है कि कौन सी एक्सटेंशन और वेब पृष्ठ आपके एक्सटेंशन से runtime.connect और runtime.sendMessage के माध्यम से कनेक्ट कर सकते हैं।

• यदि externally_connectable कुंजी आपके एक्सटेंशन के मैनिफेस्ट में नहीं घोषित की गई है या इसे "ids": ["*"] के रूप में घोषित किया गया है, तो सभी एक्सटेंशन कनेक्ट कर सकते हैं, लेकिन कोई वेब पृष्ठ कनेक्ट नहीं कर सकता।
• यदि विशिष्ट IDs निर्दिष्ट की गई हैं, जैसे "ids": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"], तो केवल वही एप्लिकेशन कनेक्ट कर सकते हैं।
• यदि matches निर्दिष्ट किए गए हैं, तो वे वेब ऐप्स कनेक्ट कर सकेंगे:

"matches": [
"https://*.google.com/*",
"*://*.chromium.org/*",

• यदि इसे खाली के रूप में निर्दिष्ट किया गया है: "externally_connectable": {}, तो कोई ऐप या वेब कनेक्ट नहीं कर सकेगा।

यहां निर्दिष्ट कम एक्सटेंशन और URL के साथ, हमला सतह छोटी होगी।

{% hint style="danger" %} यदि एक वेब पृष्ठ XSS या टेकओवर के लिए संवेदनशील है और इसे externally_connectable में निर्दिष्ट किया गया है, तो एक हमलावर पृष्ठभूमि स्क्रिप्ट को सीधे संदेश भेजने में सक्षम होगा, पूरी तरह से कंटेंट स्क्रिप्ट और इसके CSP को बायपास करते हुए।

इसलिए, यह एक बहुत शक्तिशाली बायपास है।

इसके अलावा, यदि क्लाइंट एक रॉग एक्सटेंशन स्थापित करता है, भले ही इसे संवेदनशील एक्सटेंशन के साथ संवाद करने की अनुमति न हो, यह XSS डेटा को एक अनुमत वेब पृष्ठ में इंजेक्ट कर सकता है या WebRequest या DeclarativeNetRequest APIs का दुरुपयोग कर सकता है ताकि लक्षित डोमेन पर अनुरोधों में हेरफेर किया जा सके, एक पृष्ठ के अनुरोध को JavaScript फ़ाइल के लिए बदल सके। (ध्यान दें कि लक्षित पृष्ठ पर CSP इन हमलों को रोक सकता है)। यह विचार इस लेख से आया है। {% endhint %}

संचार सारांश

एक्सटेंशन <--> वेब ऐप

कंटेंट स्क्रिप्ट और वेब पृष्ठ के बीच संवाद करने के लिए आमतौर पर पोस्ट संदेशों का उपयोग किया जाता है। इसलिए, वेब एप्लिकेशन में आपको आमतौर पर window.postMessage फ़ंक्शन के लिए कॉल मिलेंगे और कंटेंट स्क्रिप्ट में window.addEventListener जैसे श्रोता मिलेंगे। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि एक्सटेंशन भी एक पोस्ट संदेश भेजकर वेब एप्लिकेशन के साथ संवाद कर सकता है (और इसलिए वेब को इसकी अपेक्षा करनी चाहिए) या बस वेब को एक नया स्क्रिप्ट लोड करने के लिए मजबूर कर सकता है।

एक्सटेंशन के अंदर

आम तौर पर chrome.runtime.sendMessage फ़ंक्शन का उपयोग एक्सटेंशन के अंदर एक संदेश भेजने के लिए किया जाता है (आमतौर पर background स्क्रिप्ट द्वारा संभाला जाता है) और इसे प्राप्त करने और संभालने के लिए एक श्रोता घोषित किया जाता है जो chrome.runtime.onMessage.addListener को कॉल करता है।

यह chrome.runtime.connect() का उपयोग करके एक स्थायी कनेक्शन बनाने के लिए भी संभव है, इसके बजाय एकल संदेश भेजने के, इसे संदेश भेजने और प्राप्त करने के लिए उपयोग किया जा सकता है जैसे कि निम्नलिखित उदाहरण में:

chrome.runtime.connect() उदाहरण

```javascript var port = chrome.runtime.connect();

// Listen for messages from the web page window.addEventListener("message", (event) => { // Only accept messages from the same window if (event.source !== window) { return; }

// Check if the message type is "FROM_PAGE" if (event.data.type && (event.data.type === "FROM_PAGE")) { console.log("Content script received: " + event.data.text); // Forward the message to the background script port.postMessage({ type: 'FROM_PAGE', text: event.data.text }); } }, false);

// Listen for messages from the background script port.onMessage.addListener(function(msg) { console.log("Content script received message from background script:", msg); // Handle the response message from the background script });

</details>

यह भी संभव है कि एक बैकग्राउंड स्क्रिप्ट से एक कंटेंट स्क्रिप्ट को संदेश भेजा जाए जो एक विशेष टैब में स्थित है, **`chrome.tabs.sendMessage`** को कॉल करके, जहाँ आपको संदेश भेजने के लिए **टैब का ID** निर्दिष्ट करने की आवश्यकता होगी।

### अनुमति प्राप्त `externally_connectable` से एक्सटेंशन तक

**वेब ऐप्स और बाहरी ब्राउज़र एक्सटेंशन जो `externally_connectable` कॉन्फ़िगरेशन में अनुमति प्राप्त हैं** अनुरोध भेज सकते हैं:
```javascript
chrome.runtime.sendMessage(extensionId, ...

जहाँ extension ID का उल्लेख करना आवश्यक है।

Native Messaging

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

chrome.runtime.sendNativeMessage(
'com.my_company.my_application',
{text: 'Hello'},
function (response) {
console.log('Received ' + response);
}
);

Web ↔︎ Content Script Communication

जहाँ content scripts कार्य करते हैं और जहाँ होस्ट पृष्ठ मौजूद हैं, वे एक-दूसरे से अलग हैं, जो अलगाव सुनिश्चित करता है। इस अलगाव के बावजूद, दोनों के पास पृष्ठ के Document Object Model (DOM) के साथ बातचीत करने की क्षमता है, जो एक साझा संसाधन है। होस्ट पृष्ठ को content script के साथ संवाद करने के लिए, या अप्रत्यक्ष रूप से content script के माध्यम से एक्सटेंशन के साथ, आवश्यक है कि वे दोनों पक्षों द्वारा सुलभ DOM का उपयोग करें जो संवाद चैनल के रूप में कार्य करता है।

Post Messages

{% code title="content-script.js" %}

// This is like "chrome.runtime.sendMessage" but to maintain the connection
var port = chrome.runtime.connect();

window.addEventListener("message", (event) => {
// We only accept messages from ourselves
if (event.source !== window) {
return;
}

if (event.data.type && (event.data.type === "FROM_PAGE")) {
console.log("Content script received: " + event.data.text);
// Forward the message to the background script
port.postMessage(event.data.text);
}
}, false);

{% endcode %}

{% code title="example.js" %}

document.getElementById("theButton").addEventListener("click", () => {
window.postMessage(
{type : "FROM_PAGE", text : "Hello from the webpage!"}, "*");
}, false);

{% endcode %}

एक सुरक्षित Post Message संचार को प्राप्त संदेश की प्रामाणिकता की जांच करनी चाहिए, यह निम्नलिखित की जांच करके किया जा सकता है:

• event.isTrusted: यह केवल तब True है जब घटना उपयोगकर्ता की क्रिया द्वारा उत्पन्न की गई हो
• सामग्री स्क्रिप्ट केवल तभी संदेश की अपेक्षा कर सकती है जब उपयोगकर्ता कुछ क्रिया करे
• origin domain: केवल डोमेन की अनुमति सूची से संदेश की अपेक्षा कर सकती है।
• यदि regex का उपयोग किया जाता है, तो बहुत सावधान रहें
• Source: received_message.source !== window का उपयोग यह जांचने के लिए किया जा सकता है कि संदेश उसी विंडो से था जहां सामग्री स्क्रिप्ट सुन रही है।

पिछली जांचें, भले ही की गई हों, कमजोर हो सकती हैं, इसलिए निम्नलिखित पृष्ठ में संभावित Post Message बायपास की जांच करें:

{% content-ref url="../postmessage-vulnerabilities/" %} postmessage-vulnerabilities {% endcontent-ref %}

Iframe

संचार का एक और संभावित तरीका Iframe URLs के माध्यम से हो सकता है, आप इसका एक उदाहरण यहाँ पा सकते हैं:

{% content-ref url="browext-xss-example.md" %} browext-xss-example.md {% endcontent-ref %}

DOM

यह "सटीक" संचार का एक तरीका नहीं है, लेकिन वेब और सामग्री स्क्रिप्ट को वेब DOM तक पहुंच होगी। इसलिए, यदि सामग्री स्क्रिप्ट इससे कुछ जानकारी पढ़ रही है, वेब DOM पर भरोसा करते हुए, तो वेब इस डेटा को संशोधित कर सकता है (क्योंकि वेब पर भरोसा नहीं किया जाना चाहिए, या क्योंकि वेब XSS के प्रति संवेदनशील है) और सामग्री स्क्रिप्ट को समझौता कर सकता है।

आप एक DOM आधारित XSS से एक ब्राउज़र एक्सटेंशन को समझौता करने का उदाहरण भी यहाँ पा सकते हैं:

{% content-ref url="browext-xss-example.md" %} browext-xss-example.md {% endcontent-ref %}

सामग्री स्क्रिप्ट ↔︎ बैकग्राउंड स्क्रिप्ट संचार

एक सामग्री स्क्रिप्ट runtime.sendMessage() या tabs.sendMessage() का उपयोग करके एक एक बार JSON-सीरियलाइज़ेबल संदेश भेज सकती है।

प्रतिक्रिया को संभालने के लिए, लौटाए गए Promise का उपयोग करें। हालांकि, पीछे की संगतता के लिए, आप अभी भी अंतिम तर्क के रूप में एक callback पास कर सकते हैं।

एक सामग्री स्क्रिप्ट से अनुरोध भेजना इस तरह दिखता है:

(async () => {
const response = await chrome.runtime.sendMessage({greeting: "hello"});
// do something with response here, not outside the function
console.log(response);
})();

एक्सटेंशन से एक अनुरोध भेजना (आमतौर पर एक बैकग्राउंड स्क्रिप्ट)। चयनित टैब में सामग्री स्क्रिप्ट को संदेश भेजने का उदाहरण:

// From https://stackoverflow.com/questions/36153999/how-to-send-a-message-between-chrome-extension-popup-and-content-script
(async () => {
const [tab] = await chrome.tabs.query({active: true, lastFocusedWindow: true});
const response = await chrome.tabs.sendMessage(tab.id, {greeting: "hello"});
// do something with response here, not outside the function
console.log(response);
})();

On the receiving end, you need to set up an runtime.onMessage इवेंट लिसनर to handle the message. This looks the same from a content script or extension page.

// From https://stackoverflow.com/questions/70406787/javascript-send-message-from-content-js-to-background-js
chrome.runtime.onMessage.addListener(
function(request, sender, sendResponse) {
console.log(sender.tab ?
"from a content script:" + sender.tab.url :
"from the extension");
if (request.greeting === "hello")
sendResponse({farewell: "goodbye"});
}
);

उदाहरण में उजागर किया गया, sendResponse() को समकालिक तरीके से निष्पादित किया गया था। sendResponse() के असमकालिक निष्पादन के लिए onMessage इवेंट हैंडलर को संशोधित करने के लिए, return true; को शामिल करना अनिवार्य है।

एक महत्वपूर्ण विचार यह है कि उन परिदृश्यों में जहां कई पृष्ठ onMessage इवेंट प्राप्त करने के लिए सेट किए गए हैं, विशिष्ट इवेंट के लिए sendResponse() निष्पादित करने वाला पहला पृष्ठ ही प्रभावी रूप से प्रतिक्रिया देने में सक्षम होगा। उसी इवेंट के लिए किसी भी बाद की प्रतिक्रियाओं पर विचार नहीं किया जाएगा।

नई एक्सटेंशन बनाते समय, वादों की ओर प्राथमिकता होनी चाहिए न कि कॉलबैक की। कॉलबैक के उपयोग के संबंध में, sendResponse() फ़ंक्शन केवल तभी मान्य माना जाता है जब इसे सीधे समकालिक संदर्भ में निष्पादित किया जाए, या यदि इवेंट हैंडलर true लौटाकर असमकालिक संचालन को इंगित करता है। यदि कोई भी हैंडलर true नहीं लौटाता है या यदि sendResponse() फ़ंक्शन मेमोरी से हटा दिया जाता है (गारबेज-कलेक्टेड), तो डिफ़ॉल्ट रूप से sendMessage() फ़ंक्शन से संबंधित कॉलबैक को सक्रिय किया जाएगा।

नेटीव मैसेजिंग

ब्राउज़र एक्सटेंशन stdin के माध्यम से सिस्टम में बाइनरी के साथ संवाद करने की अनुमति भी देते हैं। एप्लिकेशन को इस बात का संकेत देने वाला एक json स्थापित करना चाहिए जैसे:

{
"name": "com.my_company.my_application",
"description": "My Application",
"path": "C:\\Program Files\\My Application\\chrome_native_messaging_host.exe",
"type": "stdio",
"allowed_origins": ["chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"]
}

जहाँ name वह स्ट्रिंग है जो runtime.connectNative() या runtime.sendNativeMessage() को एप्लिकेशन के साथ संवाद करने के लिए ब्राउज़र एक्सटेंशन के बैकग्राउंड स्क्रिप्ट से पास किया जाता है। path बाइनरी का पथ है, केवल 1 मान्य type है जो stdio है (stdin और stdout का उपयोग करें) और allowed_origins उन एक्सटेंशनों को इंगित करता है जो इसे एक्सेस कर सकते हैं (और इसमें वाइल्डकार्ड नहीं हो सकता)।

Chrome/Chromium इस json को कुछ विंडोज रजिस्ट्री और macOS और Linux में कुछ पथों में खोजेगा (अधिक जानकारी के लिए docs में देखें)।

{% hint style="success" %} ब्राउज़र एक्सटेंशन को इस संचार का उपयोग करने के लिए nativeMessaing अनुमति घोषित करने की भी आवश्यकता है। {% endhint %}

यहाँ एक बैकग्राउंड स्क्रिप्ट कोड है जो एक नेटिव एप्लिकेशन को संदेश भेजता है:

chrome.runtime.sendNativeMessage(
'com.my_company.my_application',
{text: 'Hello'},
function (response) {
console.log('Received ' + response);
}
);

In इस ब्लॉग पोस्ट में एक कमजोर पैटर्न जो कि नेटिव मैसेजेस का दुरुपयोग करता है, प्रस्तावित किया गया है:

1. ब्राउज़र एक्सटेंशन के लिए कंटेंट स्क्रिप्ट का एक वाइल्डकार्ड पैटर्न है।
2. कंटेंट स्क्रिप्ट sendMessage का उपयोग करके बैकग्राउंड स्क्रिप्ट को postMessage संदेश भेजता है।
3. बैकग्राउंड स्क्रिप्ट sendNativeMessage का उपयोग करके नेटिव एप्लिकेशन को संदेश भेजता है।
4. नेटिव एप्लिकेशन संदेश को खतरनाक तरीके से संभालता है, जिससे कोड निष्पादन होता है।

और इसके अंदर एक उदाहरण किसी भी पृष्ठ से RCE तक जाने का एक ब्राउज़र एक्सटेंशन का दुरुपयोग समझाया गया है।

मेमोरी/कोड/क्लिपबोर्ड में संवेदनशील जानकारी

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

इसलिए, ब्राउज़र एक्सटेंशन की मेमोरी सुरक्षित नहीं मानी जानी चाहिए और संवेदनशील जानकारी जैसे क्रेडेंशियल्स या म्नेमोनिक वाक्यांश संग्रहीत नहीं किए जाने चाहिए।

बेशक, कोड में संवेदनशील जानकारी न डालें, क्योंकि यह सार्वजनिक होगी।

ब्राउज़र से मेमोरी डंप करने के लिए आप प्रोसेस मेमोरी डंप कर सकते हैं या ब्राउज़र एक्सटेंशन की सेटिंग्स में जाने के लिए Inspect pop-up पर क्लिक करें -> Memory सेक्शन में -> Take a snapshot और संवेदनशील जानकारी के लिए स्नैपशॉट के अंदर खोजने के लिए CTRL+F दबाएं।

इसके अलावा, अत्यधिक संवेदनशील जानकारी जैसे म्नेमोनिक की या पासवर्ड क्लिपबोर्ड में कॉपी करने की अनुमति नहीं दी जानी चाहिए (या कम से कम इसे कुछ सेकंड में क्लिपबोर्ड से हटा दें) क्योंकि तब क्लिपबोर्ड की निगरानी करने वाली प्रक्रियाएँ उन्हें प्राप्त कर सकेंगी।

ब्राउज़र में एक एक्सटेंशन लोड करना

1. ब्राउज़र एक्सटेंशन डाउनलोड करें और अनज़िप करें
2. chrome://extensions/ पर जाएं और Developer Mode सक्रिय करें
3. Load unpacked बटन पर क्लिक करें

फायरफॉक्स में आप about:debugging#/runtime/this-firefox पर जाते हैं और Load Temporary Add-on बटन पर क्लिक करते हैं।

स्टोर से स्रोत कोड प्राप्त करना

एक क्रोम एक्सटेंशन का स्रोत कोड विभिन्न तरीकों से प्राप्त किया जा सकता है। नीचे प्रत्येक विकल्प के लिए विस्तृत स्पष्टीकरण और निर्देश दिए गए हैं।

कमांड लाइन के माध्यम से ZIP के रूप में एक्सटेंशन डाउनलोड करें

एक क्रोम एक्सटेंशन का स्रोत कोड कमांड लाइन का उपयोग करके ZIP फ़ाइल के रूप में डाउनलोड किया जा सकता है। इसमें एक विशिष्ट URL से ZIP फ़ाइल लाने के लिए curl का उपयोग करना और फिर ZIP फ़ाइल की सामग्री को एक निर्देशिका में निकालना शामिल है। यहाँ कदम हैं:

1. "extension_id" को एक्सटेंशन के वास्तविक ID से बदलें।
2. निम्नलिखित कमांड निष्पादित करें:

extension_id=your_extension_id   # Replace with the actual extension ID
curl -L -o "$extension_id.zip" "https://clients2.google.com/service/update2/crx?response=redirect&os=mac&arch=x86-64&nacl_arch=x86-64&prod=chromecrx&prodchannel=stable&prodversion=44.0.2403.130&x=id%3D$extension_id%26uc"
unzip -d "$extension_id-source" "$extension_id.zip"

CRX Viewer वेबसाइट का उपयोग करें

https://robwu.nl/crxviewer/

CRX Viewer एक्सटेंशन का उपयोग करें

एक और सुविधाजनक विधि Chrome Extension Source Viewer का उपयोग करना है, जो एक ओपन-सोर्स प्रोजेक्ट है। इसे Chrome Web Store से स्थापित किया जा सकता है। व्यूअर का स्रोत कोड इसके GitHub repository में उपलब्ध है।

स्थानीय रूप से स्थापित एक्सटेंशन का स्रोत देखें

स्थानीय रूप से स्थापित Chrome एक्सटेंशन को भी निरीक्षण किया जा सकता है। यहाँ यह कैसे करें:

1. chrome://version/ पर जाकर अपने Chrome स्थानीय प्रोफ़ाइल निर्देशिका तक पहुँचें और "Profile Path" फ़ील्ड को खोजें।
2. प्रोफ़ाइल निर्देशिका के भीतर Extensions/ उपफ़ोल्डर पर जाएँ।
3. इस फ़ोल्डर में सभी स्थापित एक्सटेंशन होते हैं, आमतौर पर उनके स्रोत कोड के साथ एक पठनीय प्रारूप में।

एक्सटेंशन की पहचान करने के लिए, आप उनके IDs को नामों से मैप कर सकते हैं:

• प्रत्येक एक्सटेंशन के ID देखने के लिए about:extensions पृष्ठ पर डेवलपर मोड सक्षम करें।
• प्रत्येक एक्सटेंशन के फ़ोल्डर के भीतर, manifest.json फ़ाइल में एक पठनीय name फ़ील्ड होती है, जो आपको एक्सटेंशन की पहचान करने में मदद करती है।

फ़ाइल आर्काइवर या अनपैकर का उपयोग करें

Chrome Web Store पर जाएँ और एक्सटेंशन डाउनलोड करें। फ़ाइल का .crx एक्सटेंशन होगा। फ़ाइल के एक्सटेंशन को .crx से .zip में बदलें। ZIP फ़ाइल की सामग्री निकालने के लिए किसी भी फ़ाइल आर्काइवर (जैसे WinRAR, 7-Zip, आदि) का उपयोग करें।

Chrome में डेवलपर मोड का उपयोग करें

Chrome खोलें और chrome://extensions/ पर जाएँ। शीर्ष दाएँ कोने में "डेवलपर मोड" सक्षम करें। "लोड अनपैक्ड एक्सटेंशन..." पर क्लिक करें। अपने एक्सटेंशन के निर्देशिका पर जाएँ। यह स्रोत कोड डाउनलोड नहीं करता है, लेकिन यह पहले से डाउनलोड या विकसित किए गए एक्सटेंशन के कोड को देखने और संशोधित करने के लिए उपयोगी है।

Chrome एक्सटेंशन मैनिफेस्ट डेटासेट

कमजोर ब्राउज़र एक्सटेंशन को पहचानने के लिए आप https://github.com/palant/chrome-extension-manifests-dataset का उपयोग कर सकते हैं और संभावित कमजोर संकेतों के लिए उनके मैनिफेस्ट फ़ाइलों की जांच कर सकते हैं। उदाहरण के लिए, 25000 से अधिक उपयोगकर्ताओं वाले एक्सटेंशन, content_scripts और अनुमति nativeMessaing की जांच करने के लिए:

{% code overflow="wrap" %}

# Query example from https://spaceraccoon.dev/universal-code-execution-browser-extensions/
node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.length > 0 && manifest.permissions?.includes('nativeMessaging')"

{% endcode %}

सुरक्षा ऑडिट चेकलिस्ट

हालांकि ब्राउज़र एक्सटेंशन का सीमित हमले का क्षेत्र होता है, उनमें से कुछ में कमजोरियाँ या संभावित सख्ती में सुधार हो सकते हैं। निम्नलिखित सबसे सामान्य हैं:

• अनुरोध की गई permissions को यथासंभव सीमित करें
• host_permissions को यथासंभव सीमित करें
• एक मजबूत content_security_policy का उपयोग करें
• externally_connectable को यथासंभव सीमित करें, यदि कोई आवश्यकता नहीं है और संभव है, तो इसे डिफ़ॉल्ट रूप से न छोड़ें, {} निर्दिष्ट करें
• यदि यहां XSS या टेकओवर के लिए कमजोर URL का उल्लेख किया गया है, तो एक हमलावर पृष्ठभूमि स्क्रिप्ट को सीधे संदेश भेजने में सक्षम होगा। बहुत शक्तिशाली बायपास।
• web_accessible_resources को यथासंभव सीमित करें, यदि संभव हो तो खाली भी।
• यदि web_accessible_resources कोई नहीं है, तो ClickJacking के लिए जांचें
• यदि एक्सटेंशन से वेब पृष्ठ में कोई संवाद होता है, तो XSS कमजोरियों के लिए जांचें जो संवाद में उत्पन्न होती हैं।
• यदि पोस्ट संदेशों का उपयोग किया जाता है, तो पोस्ट संदेश कमजोरियों** के लिए जांचें।**
• यदि कंटेंट स्क्रिप्ट DOM विवरण तक पहुंचती है, तो जांचें कि वे XSS को परिवर्तित करने में नहीं लाती हैं यदि वे वेब द्वारा संशोधित की जाती हैं
• यदि यह संवाद कंटेंट स्क्रिप्ट -> पृष्ठभूमि स्क्रिप्ट संवाद में भी शामिल है, तो विशेष जोर दें
• यदि पृष्ठभूमि स्क्रिप्ट नेटिव मैसेजिंग के माध्यम से संवाद कर रही है, तो जांचें कि संवाद सुरक्षित और स्वच्छ है
• संवेदनशील जानकारी को ब्राउज़र एक्सटेंशन कोड के अंदर नहीं रखा जाना चाहिए
• संवेदनशील जानकारी को ब्राउज़र एक्सटेंशन मेमोरी के अंदर नहीं रखा जाना चाहिए
• संवेदनशील जानकारी को फाइल सिस्टम में असुरक्षित रूप से नहीं रखा जाना चाहिए

उपकरण

Tarnish

• किसी दिए गए क्रोम वेबस्टोर लिंक से कोई भी क्रोम एक्सटेंशन खींचता है।
• manifest.json दर्शक: बस एक्सटेंशन के मैनिफेस्ट का JSON-प्रेटिफाइड संस्करण प्रदर्शित करता है।
• फिंगरप्रिंट विश्लेषण: web_accessible_resources का पता लगाना और क्रोम एक्सटेंशन फिंगरप्रिंटिंग जावास्क्रिप्ट का स्वचालित निर्माण।
• संभावित क्लिकजैकिंग विश्लेषण: एक्सटेंशन HTML पृष्ठों का पता लगाना जिनमें web_accessible_resources निर्देश सेट है। ये पृष्ठों के उद्देश्य के आधार पर क्लिकजैकिंग के लिए संभावित रूप से कमजोर हैं।
• अनुमति चेतावनी दर्शक: जो सभी क्रोम अनुमति प्रॉम्प्ट चेतावनियों की सूची दिखाता है जो उपयोगकर्ता द्वारा एक्सटेंशन स्थापित करने का प्रयास करते समय प्रदर्शित की जाएगी।
• खतरनाक फ़ंक्शन: खतरनाक फ़ंक्शनों का स्थान दिखाता है जिन्हें संभावित रूप से एक हमलावर द्वारा शोषित किया जा सकता है (जैसे, innerHTML, chrome.tabs.executeScript जैसे फ़ंक्शन)।
• प्रवेश बिंदु: दिखाता है कि एक्सटेंशन उपयोगकर्ता/बाहरी इनपुट को कहां लेता है। यह एक्सटेंशन के सतह क्षेत्र को समझने और एक्सटेंशन को दुर्भावनापूर्ण रूप से तैयार किए गए डेटा भेजने के संभावित बिंदुओं की तलाश करने के लिए उपयोगी है।
• खतरनाक फ़ंक्शन और प्रवेश बिंदु स्कैनर के लिए उनके उत्पन्न अलर्ट में निम्नलिखित शामिल हैं:
• संबंधित कोड स्निपेट और वह पंक्ति जिसने अलर्ट का कारण बना।
• समस्या का विवरण।
• कोड वाले पूर्ण स्रोत फ़ाइल को देखने के लिए "View File" बटन।
• अलर्ट की गई फ़ाइल का पथ।
• अलर्ट की गई फ़ाइल का पूर्ण क्रोम एक्सटेंशन URI।
• यह किस प्रकार की फ़ाइल है, जैसे कि पृष्ठभूमि पृष्ठ स्क्रिप्ट, सामग्री स्क्रिप्ट, ब्राउज़र क्रिया, आदि।
• यदि कमजोर पंक्ति एक जावास्क्रिप्ट फ़ाइल में है, तो यह उन सभी पृष्ठों के पथ दिखाता है जहां इसे शामिल किया गया है, साथ ही इन पृष्ठों का प्रकार और web_accessible_resource स्थिति।
• कंटेंट सुरक्षा नीति (CSP) विश्लेषक और बायपास चेक: यह आपके एक्सटेंशन के CSP में कमजोरियों को उजागर करेगा और आपके CSP को व्हाइटलिस्टेड CDNs आदि के कारण बायपास करने के संभावित तरीकों को भी उजागर करेगा।
• ज्ञात कमजोर पुस्तकालय: यह ज्ञात-कमजोर जावास्क्रिप्ट पुस्तकालयों के किसी भी उपयोग की जांच के लिए Retire.js का उपयोग करता है।
• एक्सटेंशन और स्वरूपित संस्करण डाउनलोड करें।
• मूल एक्सटेंशन डाउनलोड करें।
• एक्सटेंशन का एक सुंदर संस्करण डाउनलोड करें (स्वचालित रूप से प्रेटिफाइड HTML और जावास्क्रिप्ट)।
• स्कैन परिणामों का स्वचालित कैशिंग, एक एक्सटेंशन स्कैन चलाने में पहले बार में अच्छा समय लगेगा। हालाँकि दूसरी बार, यदि एक्सटेंशन को अपडेट नहीं किया गया है, तो परिणाम कैश किए जाने के कारण लगभग तात्कालिक होगा।
• लिंक करने योग्य रिपोर्ट URLs, किसी और को tarnish द्वारा उत्पन्न एक्सटेंशन रिपोर्ट से आसानी से लिंक करें।

Neto

प्रोजेक्ट Neto एक Python 3 पैकेज है जिसे फ़ायरफ़ॉक्स और क्रोम जैसे प्रसिद्ध ब्राउज़रों के लिए ब्राउज़र प्लगइन्स और एक्सटेंशनों की छिपी हुई विशेषताओं का विश्लेषण और अनावरण करने के लिए तैयार किया गया है। यह पैकेज किए गए फ़ाइलों को अनज़िप करने की प्रक्रिया को स्वचालित करता है ताकि manifest.json, स्थानीयकरण फ़ोल्डरों या जावास्क्रिप्ट और HTML स्रोत फ़ाइलों में प्रासंगिक संसाधनों से इन विशेषताओं को निकाला जा सके।

संदर्भ

• इस पद्धति में मदद के लिए धन्यवाद @naivenom
• https://www.cobalt.io/blog/introduction-to-chrome-browser-extension-security-testing
• https://palant.info/2022/08/10/anatomy-of-a-basic-extension/
• https://palant.info/2022/08/24/attack-surface-of-extension-pages/
• https://palant.info/2022/08/31/when-extension-pages-are-web-accessible/
• https://help.passbolt.com/assets/files/PBL-02-report.pdf
• https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts
• https://developer.chrome.com/docs/extensions/mv2/background-pages
• https://thehackerblog.com/kicking-the-rims-a-guide-for-securely-writing-and-auditing-chrome-extensions/
• https://gist.github.com/LongJohnCoder/9ddf5735df3a4f2e9559665fb864eac0

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}