XSS Unleashed

XSS Unleashed: The Dangers of Cross-Site Scripting
Cross-site scripting is an ever-present danger on the web, to both consumers and businesses alike. Attacks can be carried out secretly without users even realizing it, and by the time holes are found and patched, it may already be too late. The majority of attacks happen because webmasters are either unaware of the problem, don’t know how to fix it, or do not see cross-site scripting as a problem; this grave mistake can prove detrimental to your business’s bottom line. Thankfully, there are ways to prevent these attacks and protect consumers and businesses from most, if not all, cross-site scripting attempts.

The motivation behind the actions of those committing the attacks varies. Some do it for fun, just to see if it can be done; some try to impress their peers; others have more vengeful or criminal reasons. Whatever the case may be, it is vitally important to understand what these threats mean to your business, where the vulnerabilities lie, and how attacks can be prevented.

In general, cross-site scripting attacks happen over the web, when malicious code is inserted into web forms and HTML pages where it would otherwise not appear. They can be used to steal confidential user information, misdirect users to illegitimate sites, corrupt database tables, or gain control of systems. The danger is magnified for users of systems where a single login provides numerous services, such as e-mail and web access to online software, because a single successful attack can compromise each service. There are several different types of attacks, and each has specific consequences that come with it, as well as associated solutions.

One fairly common method of cross-site scripting involves tricking a user into opening a maliciously coded page, which uses JavaScript code to open a vulnerable HTML page on the user’s local computer – often located in the directory where cached pages are stored, or perhaps a pop-up window – enabling the script to run commands with the same level of permission as the user. With this type of access, a hacker can easily corrupt a user's data, steal personal information, or take control of the user’s computer.

One effective way for users to protect themselves from this attack is to user a browser that supports Same Origin Policy. This ensures that code cannot span multiple domains, eliminating the hacker's ability to inject code into a page supplied by a domain other than the one the hacker is using. Mozilla FireFox carries this capability; however, versions 6 and 7 of Internet Explorer do not. The Mozilla FireFox browser also offers an add-on called NoScript, which will stop JavaScript code from executing on domains that the user has not specified as trustworthy. For a webmaster, data validation is the best way to mitigate this threat. Code-specific characters such as semicolons and ampersands should, through proper parsing and data validation in the form, be re-coded into their respective HTML entities to ensure they do not behave as code characters. Additionally, input data can be validated in order to be read only as text, rather than HTML code that can be rendered in the page. This will prevent additional code from being injected into dynamic web pages.

Another method of cross-site scripting involves e-mail spoofing, and is somewhat of a cross between the classic "Man-in-the-Middle" attack and regular phishing attacks. A hacker will send an e-mail to a user that appears to be from a particular website, and will even link to the real website. However, extra code is embedded in the link itself so that when a user clicks the link, the code executes silently inside the user's browser, appended to the URL of the site visited. If the link goes to a log in page, the user's login credentials can be sent back to the hacker, or the page's output display can be changed to whatever the hacker wishes, depending on the malicious code used. Such code can alter the displayed page so that all form input, such as login credentials and billing information, is sent to the hacker's server instead of the real server.

This type of attack can be thwarted by both users and webmasters. First and foremost, users can disable HTML e-mail and opt for all messages to appear as text only. When viewing HTML e-mails, you must be careful when clicking links that appear inside e-mails – even if an e-mail looks legitimate, it is always safer to close all browser windows, open a new one, and go to the appropriate website directly to find the information you need. Going straight to the source will severely hinder, if not completely eliminate, a hacker's ability to inject malicious code into your browser. On the server side, the server should be configured to not allow extraneous code within the passed URL, such as that which would be placed in the address bar of the user's web browser via a malicious e-mail link. Webmasters can protect their websites from this type of attack by validating all rendered code to ensure that no additional code has been added to the page.

Another common attack involves websites where users can post their own content; typically message boards and weblogs that enable HTML code in comments from readers. Such message posts can contain harmful JavaScript code, and if the message service is not configured to disallow such code, users' systems can be compromised, or site login credentials can be stolen. A hacker will typically accomplish this task by using JavaScript to place a cookie on the user's computer, at which point the cookie can be accessed in order to send information back to the hacker's web server.

Attacks like this can also be mitigated by either the user or the webmaster, though it can be difficult. For users, browsers must be adjusted to not allow certain JavaScript functions to run, and cookies should be cleared often. (Optionally, a user can elect to only store cookies from trusted domains; however, if the site where the malicious code is posted has been added to the trusted sites list, the setting will have no effect.) For webmasters, the web applications in use should be set to parse HTML and strip out tags that are deemed undesirable. Certain script functions can be disallowed, or scripting can be disabled entirely. A web server can also bind the server’s IP address to session cookies, allowing only that IP address to use the cookie; this will prevent the hacker from using a different server to access the cookie.

Cross-site scripting can come from a variety of angles, for many different reasons, and have a virtually unlimited number of effects on both user and server systems. For these reasons, all webmasters and business owners should be aware of the dangers and what measures should be taken to prevent attacks.

Posted in: XSS