// 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>

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

### अनुमति प्राप्त `externally_connectable` से extension तक

**Web apps and external browser extensions allowed** को `externally_connectable` configuration में अनुमति होने पर requests भेजने के लिए निम्न का उपयोग कर सकते हैं :
```javascript
chrome.runtime.sendMessage(extensionId, ...

जहाँ आवश्यक हो, वहाँ extension ID का उल्लेख करें।

Native Messaging

यह संभव है कि background scripts सिस्टम के अंदर के binaries के साथ संवाद करें, जो यदि यह संचार ठीक तरह से सुरक्षित न किया गया हो तो RCEs जैसे critical vulnerabilities के लिए प्रवण हो सकते हैं। More on this later.

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

Web ↔︎ Content Script Communication

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

Post Messages

// 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
)

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

A secure Post Message communication को प्राप्त संदेश की प्रामाणिकता की जाँच करनी चाहिए — यह निम्नलिखित की जाँच करके किया जा सकता है:

• event.isTrusted: यह केवल तभी True होता है जब इवेंट किसी उपयोगकर्ता की क्रिया से ट्रिगर हुआ हो
• Content Script संभवतः केवल तब संदेश की अपेक्षा करेगा जब उपयोगकर्ता कोई क्रिया करे
• origin domain: संदेश केवल allowlist किए गए domains से ही स्वीकार करने की उम्मीद हो सकती है
• यदि regex का उपयोग किया जा रहा है, तो बहुत सतर्क रहें
• Source: received_message.source !== window का उपयोग यह जांचने के लिए किया जा सकता है कि संदेश उसी window से था जहाँ Content Script सुन रहा है।

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

PostMessage Vulnerabilities

Iframe

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

BrowExt - XSS Example

DOM

यह बिल्कुल “संचार” का तरीका नहीं है, लेकिन web और Content Script दोनों को web DOM तक पहुँच होती है। इसलिए, यदि Content Script उससे कुछ जानकारी पढ़ रहा है और web DOM पर भरोसा कर रहा है, तो web उस डेटा को बदल सकता है (क्योंकि web पर भरोसा नहीं किया जाना चाहिए, या web XSS के लिए vulnerable है) और Content Script को compromise कर सकता है।

आप एक उदाहरण भी पा सकते हैं — एक DOM based XSS to compromise a browser extension — यहाँ:

BrowExt - XSS Example

Content Script ↔︎ Background Script Communication

A Content Script runtime.sendMessage() or tabs.sendMessage() फ़ंक्शन का उपयोग करके एक one-time JSON-serializable संदेश भेज सकता है।

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

Content Script से request भेजना इस तरह दिखता है:

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

एक अनुरोध extension से भेजना (आमतौर पर एक background script). चुने हुए टैब में content script को संदेश भेजने का उदाहरण:

// 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)
})()

प्राप्त करने वाले पक्ष पर, आपको संदेश को हैंडल करने के लिए runtime.onMessage event listener सेट अप करना होगा। यह content script या 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() समकालिक (synchronous) तरीके से निष्पादित हुआ था। onMessage इवेंट हैंडलर को sendResponse() के असमकालिक (asynchronous) निष्पादन के लिए संशोधित करने हेतु return true; जोड़ना अनिवार्य है।

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

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

Native Messaging

Browser extensions भी यह अनुमति देती हैं कि वे binaries in the system via stdin के साथ संवाद कर सकें। एप्लिकेशन को इसके लिए एक json इंस्टॉल करना होगा, जैसे निम्नलिखित 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 वह string है जो browser extension के background scripts से application से संवाद करने के लिए runtime.connectNative() या runtime.sendNativeMessage() को पास किया जाता है। path binary का path है, केवल 1 मान्य type है जो कि stdio है (stdin और stdout का उपयोग करता है) और allowed_origins उन extensions को दर्शाते हैं जो इसे access कर सकते हैं (और इनमें wildcard नहीं हो सकता)।

Chrome/Chromium इस json को Windows registry और macOS तथा Linux के कुछ paths में खोजेगा (अधिक जानकारी docs में)।

Tip

Browser extension को यह communication उपयोग करने में सक्षम होने के लिए nativeMessaing permission घोषित करने की भी आवश्यकता होती है।

नीचे दिखाया गया है कि background script code native application को messages भेजते समय कैसा दिखता है:

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

In this blog post, एक vulnerable पैटर्न जो native messages का दुरुपयोग करता है प्रस्तावित किया गया है:

1. Browser extension का content script के लिए एक wildcard pattern होता है।
2. Content script postMessage messages को background script को sendMessage के माध्यम से पास करता है।
3. Background script message को native application को sendNativeMessage के माध्यम से पास करता है।
4. Native application message को खतरनाक तरीके से हैंडल करता है, जिससे code execution हो सकता है।

और इसका अंदर एक उदाहरण है कि किसी भी पेज से RCE तक कैसे पहुँचा जा सकता है abusing a browser extension।

Sensitive Information in Memory/Code/Clipboard

यदि एक Browser Extension अपनी memory के अंदर sensitive information स्टोर करता है, तो इसे dump किया जा सकता है (खासकर Windows मशीनों में) और उस जानकारी के लिए search किया जा सकता है।

इसलिए, Browser Extension की memory को secure नहीं माना जाना चाहिए और sensitive information जैसे credentials या mnemonic phrases store नहीं करने चाहिए।

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

Browser से memory dump करने के लिए आप process memory को dump कर सकते हैं या browser extension की settings में जाकर Inspect pop-up -> Memory सेक्शन -> Take a snaphost और CTRL+F करके snapshot के अंदर संवेदनशील जानकारी खोज सकते हैं।

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

Loading an Extension in the Browser

1. Browser Extension को Download करके अनज़िप करें
2. chrome://extensions/ पर जाएँ और Developer Mode enable करें
3. Load unpacked बटन पर क्लिक करें

Firefox में आप about:debugging#/runtime/this-firefox पर जाएँ और Load Temporary Add-on बटन पर क्लिक करें।

Getting the source code from the store

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

Download Extension as ZIP via Command Line

Chrome extension का source code command line का उपयोग करके ZIP फ़ाइल के रूप में डाउनलोड किया जा सकता है। इसमें curl का उपयोग करके किसी निश्चित URL से ZIP फ़ाइल को फ़ेच करना और फिर ZIP फ़ाइल की सामग्री को किसी डायरेक्टरी में extract करना शामिल है। यहाँ कदम दिए गए हैं:

1. "extension_id" को वास्तविक extension ID से बदलें।
2. निम्नलिखित commands को execute करें:

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"

Use the CRX Viewer website

https://robwu.nl/crxviewer/

Use the CRX Viewer extension

एक और सुविधाजनक तरीका Chrome Extension Source Viewer का उपयोग करना है, जो एक open-source प्रोजेक्ट है। इसे Chrome Web Store से इंस्टॉल किया जा सकता है: https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin?hl=en। viewer का source code इसके GitHub repository पर उपलब्ध है: https://github.com/Rob–W/crxviewer।

View source of locally installed extension

Chrome में स्थानीय रूप से इंस्टॉल किए गए एक्सटेंशन को भी निरीक्षित किया जा सकता है। तरीका इस प्रकार है:

1. अपने Chrome local profile directory तक पहुँचने के लिए chrome://version/ खोलें और “Profile Path” फ़ील्ड देखें।
2. प्रोफ़ाइल डायरेक्टरी के भीतर Extensions/ उपफ़ोल्डर पर नेविगेट करें।
3. यह फ़ोल्डर सभी इंस्टॉल किए गए एक्सटेंशनों को रखता है, आमतौर पर इनका source code पढ़ने योग्य फॉर्मेट में होता है।

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

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

Use a File Archiver or Unpacker

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

Use Developer Mode in Chrome

Chrome खोलें और chrome://extensions/ पर जाएँ। ऊपर दाईं ओर “Developer mode” सक्षम करें। “Load unpacked extension…” पर क्लिक करें। अपने एक्सटेंशन की डायरेक्टरी पर नेविगेट करें। यह source code डाउनलोड नहीं करता, पर पहले से डाउनलोड या विकसित किए गए एक्सटेंशन के कोड को देखने और संशोधित करने के लिए उपयोगी है।

Chrome extension manifest dataset

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

# 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')"

Post-exploitation: Forced extension load & persistence (Windows)

Stealthy technique to backdoor Chromium by directly editing per-user Preferences and forging valid HMACs, causing the browser to accept and activate an arbitrary unpacked extension without prompts or flags.

Forced Extension Load Preferences Mac Forgery Windows

Detecting Malicious Extension Updates (Static Version Diffing)

Supply-chain compromises अक्सर पहले से benign extensions में किए गए malicious updates के रूप में आते हैं। एक व्यावहारिक, low-noise तरीका यह है कि नए extension package की तुलना last known-good version से की जाए, static analysis का उपयोग करके (उदाहरण के लिए, Assemblyline). उद्देश्य है किसी भी छोटे बदलाव पर अलर्ट करने की बजाय केवल उन high-signal deltas पर अलर्ट देना जो वास्तव में जोखिम सूचित करते हैं।

Workflow

• Submit both versions (old + new) को एक ही static-analysis profile में चलाएँ।
• Flag new or updated background/service worker scripts (persistence + privileged logic)।
• Flag new or updated content scripts (DOM access और data collection)।
• Flag new permissions/host_permissions जो manifest.json में जोड़े गए हों।
• Flag new domains जो code से निकाले गए हों (संभावित C2/exfil endpoints)।
• Flag new static-analysis detections (उदा., base64 decode, cookie harvesting, network-request builders, obfuscation patterns)।
• Flag statistical anomalies जैसे कि बदले हुए scripts में तेज entropy उछाल या outlier z-scores।

Detecting script changes accurately

• New script added → manifest.json diff के माध्यम से पता करें।
• Existing script modified (manifest अपरिवर्तित) → extracted file tree से per-file hashes की तुलना करें (उदा., Assemblyline Extract output). यह existing workers या content scripts में छिपे हुए stealthy updates पकड़ता है।

Pre-disclosure detections

पहले से ज्ञात IOCs पर आधारित “easy mode” detections से बचने के लिए, threat-intel-fed services को disable करें और intrinsic signals (domains, heuristic signatures, script deltas, entropy anomalies) पर निर्भर रहें। इससे सार्वजनिक रिपोर्टिंग से पहले malicious updates पकड़ने के मौके बढ़ते हैं।

Example high-confidence alert logic

• Low-noise combo: new domains + new static-analysis detections + updated background/service worker + updated or added content scripts।
• Broader catch: new domain + new or updated background/service worker (higher recall, higher noise)।

Key Assemblyline services for this workflow:

• Extract: extension को unpack करता है और per-file hashes देता है।
• Characterize: file characteristics (उदा., entropy) को compute करता है।
• JsJAWS / FrankenStrings / URLCreator: JS heuristics, strings, और domains को surface करता है ताकि versions में diff किया जा सके।

Security Audit Checklist

हालाँकि Browser Extensions का attack surface सीमित होता है, कुछ extensions में vulnerabilities या hardening सुधार की संभावनाएँ होती हैं। सबसे सामान्य चेकलिस्ट निम्नलिखित है:

• जितना संभव हो उतना requested permissions को Limit करें
• जितना संभव हो उतना host_permissions को Limit करें
• एक मजबूत content_security_policy का उपयोग करें
• जितना संभव हो उतना externally_connectable को Limit करें; यदि आवश्यक नहीं है तो डिफ़ॉल्ट रूप से न रखें, specify करें {}
• यदि कोई URL जो这里 XSS या takeover के लिए vulnerable है, यहां उल्लेखित है, तो attacker सीधे background scripts को संदेश भेज पाएगा। यह बहुत शक्तिशाली bypass हो सकता है।
• जितना संभव हो उतना web_accessible_resources को Limit करें, यदि संभव हो तो खाली रखें।
• यदि web_accessible_resources none नहीं है, तो ClickJacking के लिए जाँच करें
• यदि extension और web page के बीच कोई communication हो रही है, तो उस communication में पैदा होने वाली संभावित XSS vulnerabilities की जाँच करें।
• यदि Post Messages उपयोग हो रहे हैं, तो Post Message vulnerabilities की जाँच करें।
• यदि Content Script DOM तक पहुँचता है, तो सुनिश्चित करें कि वे web द्वारा बदलने पर XSS introduce न करें
• विशेष ध्यान दें यदि यह communication Content Script -> Background script communication में भी शामिल है
• यदि background script native messaging के माध्यम से communicate कर रहा है तो सुनिश्चित करें कि communication secure और sanitized है
• Sensitive information को Browser Extension के code के अंदर नहीं स्टोर किया जाना चाहिए
• Sensitive information को Browser Extension की memory के अंदर नहीं रखा जाना चाहिए
• Sensitive information को file system unprotected में नहीं रखना चाहिए

Browser Extension Risks

• ऐप https://crxaminer.tech/ कुछ डेटा, जैसे कि extension द्वारा माँगी गई permissions, analyze करता है ताकि extension के उपयोग का risk level दिया जा सके।

Tools

Tarnish

• दिए गए Chrome webstore link से किसी भी Chrome extension को pull करता है।
• manifest.json viewer: extension के manifest का JSON-prettified संस्करण दिखाता है।
• Fingerprint Analysis: web_accessible_resources का पता लगाता है और Chrome extension fingerprinting JavaScript स्वतः जनरेट करता है।
• Potential Clickjacking Analysis: उन extension HTML पृष्ठों का पता लगाता है जिनमें web_accessible_resources directive सेट है। पृष्ठों के उद्देश्य के आधार पर ये Clickjacking के प्रति संवेदनशील हो सकते हैं।
• Permission Warning(s) viewer: यह उन सभी Chrome permission prompt warnings की सूची दिखाता है जो उपयोगकर्ता द्वारा extension install करने पर प्रदर्शित होंगे।
• Dangerous Function(s): संभावित खतरनाक functions (उदा., innerHTML, chrome.tabs.executeScript) के स्थान को दिखाता है जो attacker द्वारा exploit हो सकते हैं।
• Entry Point(s): दिखाता है कि extension कहाँ user/external input लेता है। यह extension के surface area को समझने और संभावित स्थानों की पहचान करने में उपयोगी है जहाँ maliciously-crafted data भेजा जा सकता है।
• Dangerous Function(s) और Entry Point(s) scanners द्वारा जनरेट किए गए alerts के लिए जानकारी:
  • संबंधित code snippet और alert का कारण बनने वाली लाइन।
  • समस्या का विवरण।
  • “View File” बटन जिससे पूरा source file देखा जा सके।
  • alerted file का path।
  • alerted file का पूरा Chrome extension URI।
  • फाइल का प्रकार, जैसे Background Page script, Content Script, Browser Action, आदि।
  • यदि vulnerable line किसी JavaScript फाइल में है, तो उन सभी पृष्ठों के paths जहाँ यह शामिल है, साथ ही उन पृष्ठों का type और web_accessible_resource status।
• Content Security Policy (CSP) analyzer and bypass checker: यह आपके extension की CSP में कमजोरियों की ओर संकेत करेगा और उन संभावित bypass मार्गों को भी दिखाएगा जो whitelisted CDNs आदि के कारण हो सकते हैं।
• Known Vulnerable Libraries: यह Retire.js का उपयोग करके ज्ञात-vulnerable JavaScript libraries के उपयोग की जाँच करता है।
• Extension को डाउनलोड करने और formatted versions डाउनलोड करने की सुविधा।
• Original extension डाउनलोड करने का विकल्प।
• Beautified version (auto prettified HTML और JavaScript) डाउनलोड करने का विकल्प।
• स्कैन परिणामों का automatic caching; पहली बार स्कैन में समय लग सकता है, लेकिन बाद के स्कैन तेज़ होंगे यदि extension अपडेट नहीं हुआ है।
• Linkable Report URLs, जिससे generated extension report को आसानी से किसी और के साथ share किया जा सकता है।

Neto

Project Neto एक Python 3 package है जिसे Firefox और Chrome जैसे प्रसिद्ध ब्राउज़रों के browser plugins और extensions की hidden features को analyze और उजागर करने के लिए डिज़ाइन किया गया है। यह packaged files को unzip करके relevant resources (जैसे manifest.json, localization folders या Javascript और HTML source files) से इन features को extract करने की प्रक्रिया को automate करता है।

References

• Thanks to @naivenom for the help with this methodology
• 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
• https://redcanary.com/blog/threat-detection/assemblyline-browser-extensions/

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

• सदस्यता योजनाओं की जांच करें!
• हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।