Browser DOM Instrumentation for Third-Party JavaScript Sanitization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Modern web applications are vulnerable to Cross-Site Scripting (XSS) attacks due to the execution of third-party JavaScript code, which can lead to security breaches as attackers can impersonate users and retrieve sensitive information, despite existing solutions like DOMPurify and resource management components not fully addressing the issue.
Innovation Solution
A browser-based system that references a whitelist or blacklist to identify third-party JavaScript, instruments the Document Object Model (DOM) features by overwriting global references or altering prototypes, sanitizing the JavaScript before execution, and uses stacktraces to differentiate between trusted and untrusted code.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If third-party JavaScript code is executed to add services and features, then functionality and versatility are improved, but security vulnerability to XSS attacks increases
Solution Approach 1:
The patent introduces a whitelist mechanism as an intermediary layer between third-party JavaScript code and the web application execution environment. The whitelist contains pre-approved script identifiers, and the system checks whether incoming third-party scripts match entries in the whitelist before allowing execution. This mediator filters out untrusted scripts while permitting legitimate third-party functionality, thus resolving the contradiction between functionality and security.
2Reliability
If DOM features are instrumented to sanitize JavaScript, then security is improved, but device complexity increases
Solution Approach 1:
The patent implements preliminary action by pre-compiling and storing a whitelist of trusted third-party JavaScript script identifiers in a database before runtime. During execution, the system performs a simple lookup check against this pre-prepared whitelist rather than performing complex analysis on each script. This preliminary preparation reduces runtime complexity while maintaining security, as the heavy lifting of identifying trusted scripts is done in advance.
3Measurement precision
If a whitelist mechanism is implemented to identify third-party scripts, then security precision is improved, but measurement and detection difficulty increases
Solution Approach 1:
The patent extracts the identification criterion for trusted third-party scripts into a separate, standalone whitelist database structure. Instead of embedding complex identification logic within the script execution flow, the system separates the trusted script identifiers into an external whitelist that can be independently managed, updated, and queried. This extraction simplifies the detection process to a straightforward database lookup operation.
Data Source
Figure 1
Figure 2
Figure 3~5
AI summary
Embodiments protect against security vulnerabilities arising from 3rd party JavaScript code. A browser receives from a server, a document including a first JavaScript. The browser in turn references a list stored in a database to recognize the first JavaScript as originating from other than the server. This recognition process may involve obtaining a stacktrace. The browser then references a second JavaScript in order to instrument a document object model (DOM) feature (e.g., global API, DOM element-attached API, DOM node property) to sanitize the first JavaScript. For instrumenting a global API, this may comprise overwriting a global reference in the first JavaScript with a replacement reference to a sanitization function. For instrumenting the DOM element-attached API or the DOM node property, the instrumenting may comprise altering a prototype of the DOM node element. The browser causes the DOM feature to sanitize the first JavaScript, and passes a sanitized JavaScript for execution.