Scripting Environment Protection via High-Entropy Secret Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cross-site scripting (XSS) attacks pose a significant threat to Web 2.0 sites, particularly social networking platforms, due to their large user base, diverse technical understanding, and susceptibility to social engineering, making it difficult to distinguish between legitimate and malicious script code, leading to potential data breaches and rapid propagation of attacks.
Innovation Solution
Implementing a method to differentiate between 'trusted' and 'untrusted' scripts by requiring high-entropy secrets for execution in 'at risk' or 'restricted' portions of the scripting language and environment, while allowing 'safe' portions to execute freely, using mechanisms like reconfiguring objects and functions to require password parameters and maintaining anonymity through native functionality and property descriptors.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If scripts are allowed to execute freely in the scripting language environment, then the ease of operation and functionality are improved, but the security risk increases due to XSS attacks
Solution Approach 1:
The patent segments the scripting environment into trusted and untrusted zones by introducing password-protected functions. Legitimate scripts receive passwords that enable access to protected functions, while malicious scripts cannot obtain these passwords. This segmentation allows free execution of authorized scripts while blocking unauthorized access to sensitive operations.
Solution Approach 2:
The patent introduces passwords as an intermediary mechanism between scripts and sensitive functions. The password acts as a mediator that legitimate scripts can obtain through authorized channels (like server responses) while malicious scripts cannot acquire. This intermediary layer enables differentiated access control without restricting the overall scripting environment.
2Reliability
If password protection is added to sensitive functions, then security is improved, but the device complexity increases
Solution Approach 1:
The patent applies password protection locally only to sensitive functions that are vulnerable to XSS attacks, rather than protecting the entire scripting environment. Functions like document.write, createElement, and other DOM-manipulating functions are protected, while other functions remain accessible without passwords. This localized approach provides security where needed while maintaining simplicity elsewhere.
Solution Approach 2:
The patent changes the parameter structure of sensitive functions by adding a password parameter. Functions that originally took parameters like (url, text) now require an additional password parameter. This parameter change is transparent to the function's core logic but provides the necessary security control. The password parameter is verified before executing the original function logic.
3Reliability
If all functions require passwords for execution, then security is improved, but the productivity decreases due to additional authentication overhead
Solution Approach 1:
The patent applies password protection to only the subset of functions that are critical for XSS attacks, rather than requiring passwords for all functions. High-risk functions like those that can write to the DOM or make network requests are protected, while lower-risk functions remain accessible without authentication. This partial application of protection maintains security for critical operations while preserving execution efficiency for non-critical operations.
4Reliability
If the scripting environment is reconfigured to require passwords, then the reliability is improved, but the ease of manufacture and deployment becomes more difficult
Solution Approach 1:
The patent implements a self-service mechanism where the server automatically provides passwords to legitimate scripts through normal HTTP responses. The protection mechanism does not require manual configuration or complex deployment - it automatically integrates with the existing server-script-client architecture. The server includes the password in the response to the script, and the script automatically uses it, making the system self-configuring and easy to deploy.
Data Source
AI summary
There is provided a method of preventing unwanted code execution in a computing environment executing a scripting language and associated environment, wherein said computing environment comprises at least one server-side resource and a client side resource, comprising determining “safe” and “at risk” or “restricted” portions of the scripting language and associated environment, determining “trusted” and “untrusted” portions of the scripting language and associated environment, determining at least one “trusted” server-side resource, receiving from the “trusted” server-side resource an initial message containing one or more high-entropy secrets, and providing an unwanted code execution protection mechanism by reconfiguring said “at risk” or “restricted” portions of the scripting language and associated environment to require presentation of the one or more high-entropy secrets in order to execute.