The present invention generally relates to detecting XSS (Cross-site Scripting) attacks on computer systems. More specifically, the present invention relates to using scripts executed by web browsers to detect XSS vulnerabilities in dynamic URLs (Uniform Resource Locator) and collect XSS vulnerable URLs.
Cross-site Scripting (XSS) is a type of computer security vulnerability typically found in web applications that allow malicious attackers to inject code, such as HTML (Hypertext Markup Language) code or client-side script code (e.g., JavaScript code), into the source code of web pages viewed by users. For example, by incorporating JavaScript code into a web page's source code, a web server is able to send executable code to a browser. Such script code may be manipulated, e.g. altered or replaced, by malicious attackers to cause various types of damages or harms to a user when the script code is executed in the user's browser, such as stealing the user's private information, manipulating or stealing cookies, creating requests that can be mistaken for those of a valid user, executing malicious code on the end-user systems, etc.
Currently, there are three distinct types of XSS vulnerabilities. The first type, generally referred to as “non-persistent” or “reflected” XSS vulnerabilities, occurs when data provided by a web client associated with a user is used by server-side scripts to generate a dynamic web page for that user. If invalidated user-supplied data is included in the resulting web page without HTML encoding, the client-side code may be injected into the generated dynamic web page. One type of harm caused by reflected XSS is that an attacker may convince the user to follow a malicious URL that injects code into the resulting web page, giving the attacker full access to that page's content.
The second type, generally referred to as “stored”, “persistent”, or “second-order” XSS vulnerabilities, occurs when data provided by a user to a web application is stored persistently on the web server, such as in a database, a file system, or other types of locations linked to the server. Subsequently, the stored data is displayed in web pages without being encoded using HTML entities. This is the most powerful kind of attack, because an attacker can inject the malicious script just once, and since the malicious script is stored in the web server, it may harm a large number of other users as the web server may send the malicious script to many different users.
The third type is generally referred to as “DOM-based” or “local” XSS vulnerabilities. With this type, the problem exists within a web page's client-side script itself. For example, if a piece of potentially malicious JavaScript code accesses a URL request parameter and uses this information to write some HTML to its own page, an XSS hole may be present if the information is not encoded using HTML entities. Although the server responses do not contain the malicious script code in any form, the URL is still vulnerable. This type of XSS hole in a local web page may result in remote execution vulnerabilities.
Several methods have been developed to detect and prevent XSS attacks. Filtering is the most recommended solution when dealing with XSS prevention. Applications may filter out invalid input or encode some special characters, such as encoding all user-supplied HTML special characters for both ASCII and HEX (hexadecimal) values, thereby preventing these special characters from being interpreted as HTML.
To detect whether there is any XSS vulnerability in a dynamic URL, a tool, often automated, may be used to submit random data to the URL and then checks whether the same random data appears in the dynamically-generated response web pages. If so, the URL is likely to be vulnerable. However, such tool is unable to detect DOM-based XSS vulnerabilities because the response web pages do not contain any submitted data, i.e., the random data. Furthermore, it may have false alarms because the tool does not use browsers to validate the XSS vulnerabilities. Therefore, continuous efforts are needed to improve XSS prevention and detection.
USPTO Backgrounds
USPTO Backgrounds