Paper: HTML Code Injection and Cross-Site Scripting

http://www.xssed.com/article/8/Paper_HTML_Code_Injection_and_Cross-Site_Scripting/
Paper: HTML Code Injection and Cross-Site Scripting
Written by Gunter Ollmann - Technicalinfo.net
Monday, 21 May 2007

Contents:

* Abstract
* Introduction
* Code Insertion
* Malicious Code
* Cross-Site Scripting
* Understanding Code Insertion
o Inline Scripting
o Forced Error Responses
o Non

Hello World!

Unfortunately, attackers are finding ever more ingenious methods of encoding their embedded attacks, and consequently many more sites are vulnerable.
Of particular importance is the abuse of trust. Consider a trusted site with a poorly coded search engine. An attacker may be able to embed their malicious code within a hyperlink to the site. When the client web browser follows the link, the URL sent to trusted.org includes malicious code. The site sends a page back to the browser including the value of criteria, which consequently forces the execution of code from the evil attackers’ server. For example;

Go to trusted.org

In the attack above, one source is inserting code into pages sent by another source.

It should be noted that this attack:
• disguises the link as a link to http://trusted.org,
• can be easily included in an HTML email message,
• does not supply the malicious code inline, but is downloaded from http://evil.org. Thus the attacker retains control of the script and can update or remove the exploit code at anytime.
This class of vulnerability is popularly referred to as cross-site scripting (CSS or sometimes XSS).
Cross Site Scripting

A cross-site scripting vulnerability is caused by the failure of an web based application to validate user supplied input before returning it to the client system. “Cross-Site” refers to the security restrictions that the client browser usually places on data (i.e. cookies, dynamic content attributes, etc.) associated with a web site. By causing the victim’s browser to execute injected code under the same permissions as the web application domain, an attacker can bypass the traditional Document Object Model (DOM) security restrictions which can result not only in cookie theft but account hijacking, changing of web application account settings, spreading of a webmail worm, etc.
Note that the access that an intruder has to the Document Object Model (DOM) is dependent on the security architecture of the language chosen by the attacker. Specifically, Java applets do not provide the attacker with any access beyond the DOM and are restricted to what is commonly referred to as a sandbox.
The most common web components that fall victim to CSS/XSS vulnerabilities include CGI scripts, search engines, interactive bulletin boards, and custom error pages with poorly written input validation routines. Additionally, a victim doesn’t necessarily have to click on a link; CSS code can also be made to load automatically in an HTML e-mail with certain manipulations of the IMG or IFRAME HTML tags.
The most popular CSS/XSS attack (and devastating) is the harvesting of authentication cookies and session management tokens. With this information, it is often a trivial exercise for an attacker to hijack the victims active session, completely bypassing the authentication process. Unfortunately, the mechanism of the attack is very simple and can be easily automated. A detailed paper by iDefence goes into great detail explaining the process, but can be quickly summarised as follows:

1. The attacker investigates an interesting site that normal users must authenticate to gain access to, and that tracks the authenticated user through the use of cookies or session ID’s
2. The attacker finds a CSS vulnerable page on the site, for instance http://trusted.org/ account.asp.
3. Using a little social engineering, the attacker creates a special link to the site and embeds it in an HTML email that he sends to a long list of potential victims.
4. Embedded within the special link are some coding elements specially designed to transmit a copy of the victims cookie back to the attacker. For instance:
5. Unknown to the victim, the attacker has now received a copy of their cookie information.

The attacker now visits the web site and, by substituting his cookie information with that of the victims, is now perceived to be the victim by the server application.

Note that Cross-site scripting is commonly referred to as CSS and/or XSS.
Understanding Code Insertion

To date, security professions have discovered an ever increasing number of methods for potentially embedding code within poorly configured web applications. The following are some of the more common methods for doing so.
Inline Scripting

http://trusted.org/search.cgi?criteria=

http://trusted.org/search.cgi?val=

http://trusted.org/COM2.IMG%20src= "Javascript:alert(document.domain)"
Forced Error Responses

http://trusted.org/
This insertion facet usually occurs due to poor error handling by the web server or application component. The application fails to find the requested page and reports an error which unfortunately includes the unprocessed script data.

http://trusted.org/search.cgi?blahblahblahblahblah
If a Java application such as a servlet fails to handle an error gracefully, and allows stack traces to be sent to the users browser, an attacker can construct a URL that will throw an exception and add his malicious script to the end of the request.

http://trusted.og/servlet/ org.apache.catalina.servlets.WebdavStatus/
In the example above, when the Tomcat servlet is called with the training illegitimate request, an error page is served containing the offending text verbatim.
Non