Website designers and operators such as online merchants are engaged in an ongoing battle to maintain information security. The complexity of the Internet's infrastructure is accompanied by numerous security vulnerabilities, such as Cross-Site Scripting (CSS) and other vulnerabilities. A cross-site scripting exploit may be used by an attacker to breach the security of a web browser or other web-based application. By breaching a browser's security, the attacker may gain access to a user's session at a particular website. For a user engaged in a session at the website of an online merchant, for example, a cross-site scripting exploit may permit an attacker to gain access to private information associated with the user's session, such as financial information, authentication credentials, and/or elements of the user's personal identity (e.g., a real name, an e-mail address, etc).
In particular, a cross-site scripting flaw may be exploited to enable an attacker to inject a client-side script into a web page. The client-side script may be injected into a web page sent by a server to the client without the knowledge or consent of the server's operators. When processed in the client's browser, the script may access private information stored in one or more cookies (or other storage elements) in the memory of the browser. The script may forward the stolen information to a third-party recipient for potential use in fraudulent or otherwise malicious schemes.
Cross-site scripting exploits are often placed into two categories: non-persistent and persistent. In a non-persistent or reflected exploit, data provided to a server by a client (e.g., the client's browser) may be included in a web page sent back to the client without properly sanitizing the data. The data introducing the exploit is typically provided to the client through a link to the server provided by a third party. The link may contain an injected script or any other content that is interpretable as code by the browser. When the improperly sanitized data is sent (i.e., reflected) from the server back to the client, the injected script may be executed on the client's browser. In a persistent or stored exploit, data introducing the exploit is stored by the web server and provided by the server to the client that requests a particular web page. The data may include a script that is executed on the client side when provided by the server to the client. The script may be introduced into the server's web page through user-supplied content from a malicious third party. Whether the script is sent to the client using the non-persistent or persistent type of exploit, execution of the script on the client side may result in sensitive information being stolen and/or misused.
Web application vulnerability scanners typically scan for CSS and other vulnerabilities by attempting a large list of previously successful exploits in connection with the user supplied parameter (also referred to as an input element) associated with the URL identifying the webpage or parameter list. Accordingly, conventional Web application vulnerability scanners are not particularly smart and frequently will attempt multiple (e.g. hundreds) exploits, even though such exploits are predicted to fail based on previous checks of the current webpage and/or other webpages.
Hence, conventional Web application vulnerability scanners place a large strain on a Web server, by attempting numerous exploits. Also, due to the volume of potential exploits, a vulnerability scan may require a relatively long period of time to be completed. Consequently, web vulnerability scanners are run infrequently and typically only run on test systems. Web vulnerability scanners are generally not run on production environment Web sites and/or Web applications.
In addition, conventional Web application vulnerability scanners may return numerous “false positives” indicating apparent exploits. However, when these apparent exploits are further analyzed, it may turn out that some of the apparent exploits are not in fact actual vulnerabilities. Instead, other methods operating on the Web server (or elsewhere) may ultimately prove to appropriately quarantine some of the apparent exploits.
Accordingly, it is desirable for website operators and designers to have techniques for detecting and/or remediating vulnerabilities in an adaptive manner that performs vulnerability scans more efficiently and with less demand on web server resources.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning “having the potential to”), rather than the mandatory sense (i.e., meaning “must”). Similarly, the words “include,” “including,” and “includes” mean “including, but not limited to.”