High availability is a system design protocol and associated implementation that ensures a certain absolute degree of operational continuity during a given measurement period.

Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message.

Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website.

Many popular guestbook and forum programs allow users to submit posts with html and javascript embedded in them. If for example I was logged in as "john" and read a message by "joe" that contained malicious javascript in it, then it may be possible for "joe" to hijack my session just by reading his bulletin board post. Further details on how attacks like this are accomplished via "cookie theft" are explained in detail below.

JavaScript is a powerful tool for developing rich Web applications. Without client-side execution of code embedded in HTML and XHTML pages, the dynamic nature of Web applications like Google Maps, Try Ruby! And Zoho Office would not be possible. Unfortunately, any time you add complexity to a system, you increase the potential for security issues — and adding JavaScript to a Web page is no exception.

Among the problems introduced by JavaScript are:

A malicious website might employ JavaScript to make changes to the local system, such as copying or deleting files.

A malicious website might employ JavaScript to monitor activity on the local system, such as with keystroke logging.

A malicious website might employ JavaScript to interact with other Websites the user has open in other browser windows or tabs.

The first and second problems in the above list can be mitigated by turning the browser into a sort of “sandbox” that limits the way JavaScript is allowed to behave so that it only works within the browser’s little world. The third can be limited somewhat as well, but it is all too easy to get around that limitation because whether a particular webpage can interact with another webpage in a given manner may not be something that can be controlled by the software employed by the end user. Sometimes, the ability of one website’s JavaScript to steal data meant for another Website can only be limited by the due diligence of the other website’s developers.

The key to defining cross-site scripting is in the fact that vulnerabilities in a given website’s use of dynamic Web design elements may give someone the opportunity to use JavaScript for security compromises. It’s called “cross-site” because it involves interactions between two separate websites to achieve its goals. In many cases, however, even though the exploit involves the use of JavaScript, the website that’s vulnerable to cross-site scripting exploits does not have to employ JavaScript itself at all. Only in the case of local cross-site scripting exploits does the vulnerability have to exist in JavaScript sent to the browser by a legitimate website.



Types of cross-site scripting

There are currently three major categories of cross-site scripting. Others may be discovered in the future, however, so don’t think this sort of misuse of Web page vulnerability is necessarily limited to these three types.

Reflected: Probably the most common type of cross-site scripting exploit is the reflected exploit. It targets vulnerabilities that occur in some websites when data submitted by the client is immediately processed by the server to generate results that are then sent back to the browser on the client system. An exploit is successful if it can send code to the server that is included in the Web page results sent back to the browser, and when those results are sent the code is not encoded using HTML special character encoding — thus being interpreted by the browser rather than being displayed as inert visible text.

The most common way to make use of this exploit probably involves a link using a malformed URL, such that a variable passed in a URL to be displayed on the page contains malicious code. Something as simple as another URL used by the server-side code to produce links on the page, or even a user’s name to be included in the text page so that the user can be greeted by name, can become a vulnerability employed in a reflected cross-site scripting exploit.

Stored: Also known as HTML injection attacks, stored cross-site scripting exploits are those where some data sent to the server is stored (typically in a database) to be used in the creation of pages that will be served to other users later. This form of cross-site scripting exploit can affect any visitor to your website, if your site is subject to a stored cross-site scripting vulnerability. The classic example of this sort of vulnerability is content management software such as forums and bulletin boards where users are allowed to use raw HTML and XHTML to format their posts.

As with preventing reflected exploits, the key to securing your site against stored exploits is ensuring that all submitted data is translated to display entities before display so that it will not be interpreted by the browser as code.

Local: A local cross-site scripting exploit targets vulnerabilities within the code of a webpage itself. These vulnerabilities are the result of incautious use of the Document Object Model in JavaScript so that opening another Web page with malicious JavaScript code in it at the same time might actually alter the code in the first page on the local system. In older versions of Internet Explorer (before IE 6 on MS Windows XP Service Pack 2), in fact, this could even be used on local Web pages (stored on the local computer rather than retrieved from the World Wide Web), and through those pages break out of the browser “sandbox” to affect the local system with the user privileges used to run the browser. Because most MS Windows users have tended to run everything as the Administrator account, this effectively meant that local cross-site scripting exploits on MS Windows before XP Service Pack 2 could do just about anything.

In a local cross-site scripting exploit, unlike reflected and stored exploits, no malicious code is sent to the server at all. The behavior of the exploit takes place entirely on the local client system, but it alters the pages provided by the otherwise benign Website before they are interpreted by the browser so that they behave as though they carried the malicious payload to the client from the server. This means that server-side protections that filter out or block malicious cross-site scripting will not work with this sort of exploit.