Introduction to XSS (CSS)

Cross Site Scripting

submitted by Generics

Abstract
Keywords: Cross-Site Scripting Keywords: Vulnerabilities Keywords: Impacts

This document offers an overview of the process, solutions, and dangers, of Cross-site Scripting. It demonstrates the ease at which an attacker can access a victims personal information while keeping their identity covered. Furthermore, means to circumvent these attacks are presented in hopes to raise user awareness.

Seminarpaper

Generics

2006

1 2

INTRODUCTION ................................................................................................. 3 CROSS SITE SCRIPTING [1] ............................................................................. 3

2.1 Types of XSS Vulnerability [2] ................................................................................................................... 4 2.2 Session Hacking [3]...................................................................................................................................... 5

3 4 5 6 7 8 9

XSS-PROXY [5] .................................................................................................. 6 THE IMPACT [6] ................................................................................................. 6 VULNERABILITY CHECKING [7] ...................................................................... 7 SOLUTIONS AND WORKAROUNDS [8] ........................................................... 7 CONCLUSION .................................................................................................... 8 APPENDIX .......................................................................................................... 9 BIBLIOGRAPHY ............................................................................................... 12

Seminarpaper

Generics

2006

1 Introduction
Following a seemingly harmless link can lead to catastrophic consequences, especially if it is allegedly a link to your net banking account. The world of internet has advanced tremendously, as have ways of exploiting its security. Internet users have had negative surfing experiences by following malicious links since the beginning, without ever discovering how to bypass such threats. Cross-Site and Cross-Framework-Scripting are the standard attack techniques for stealing cookies, passwords or even worse, your personal TAN numbers. In this paper we will discuss these and other advanced techniques, outline the impacts, give some examples, and explain how to protect yourself from these attacks.

2 Cross site Scripting [1]

Cross-Site-Scripting, which in security circles is more popularly known as XSS, is a technique used to gather user information. XSS (CSS) is used by attackers to compromise clients through security vulnerabilities. Usually such vulnerabilities can be found in web applications. Because there can be confusion with the acronym of Cross-Site-Scripting (CSS), which also stands for Cascading Style Sheet or Content Scrambling System, Steve Champeon popularized XSS in his Webmonkey article XSS, Trust, and Barney [8]. Since then the security community has used XSS as the standard abbreviation. The main intention of a XSS attacker is to fool the user into clicking on a malicious link which looks like a trusted site. The link could look like this:
http://www.mytrustedsite.com/cgi-bin/xy.cgi?<script>givemeallyourmoney</script>

Since most of the users do not know what all the code after http://www.mytrustedsite.com stands for, they are tempted to click on the link because it looks like a site they are familiar with. To make the attack possible, the attacker has to know that the trusted server has XSS vulnerability. After a user clicks on a prepared link they will be forwarded to the site, and without asking, the malicious code will be executed in their browser. For a better understanding see the graph below.

Seminarpaper

Generics

2006

Fig 1

Usually JavaScript is not allowed to access cookies that arent from the same script or from the same server. Cookies can store session IDs or even worse, authentication data. With the Cross-Site-Scripting technique the attacker can now modify or delete cookies on the victims computer.

So far it may not sound as if this is a big issue. However, in the next chapter we will see that once the attacker gets the cookie, it is easy to hijack a session.

2.1 Types of XSS Vulnerability [2]

XSS commonly attacked vulnerabilities are separated into three basic groups: types 1, 2, and 3. However, there is no standard nomenclature for these points. Type 1 is commonly referred to as DOM-based or Local XSS. It is distinguished by a security hole in the client-side script; meaning that the JavaScript connects to a particular URL request parameter, creates its own HTML with the gathered information, but fails to be HTML quoted. The information will be re-processed by browsers as HTML that might include more client-side script. Script can be injected into a link, which can skip the client-side sandbox and grant the attacker full access to the victims system. A Bugzilla error page was once found to have a vulnerability of this kind. In that particular case, JavaScript wrote URL to pages without prior filtering, encrypting, or quoting.

Seminarpaper

Generics

2006

Type 2-vulnerability is the most common form, and is usually called non-persistent or reflected vulnerability. The hole is most commonly found in search-engines where a user types in a string that has HTML special characters. The search-string shows up again on the page of results without HTML characters, which allows the code from the clients side to be added to the dynamic page, and you have a XSS hole. Attackers use social engineering to lure victims into following hurtful URLs that can inject code into the page of results. By doing this, the attacker gains full admittance to the pages composition. This type of vulnerability has evoked mixed feelings by programmers and other computer specialists due to the fact that social engineering is involved. However, for a beginner using the internet, this threat is unquestionable. This vulnerability was found in older versions of ATutor (a web-based learning center) on the search page. It was possible to inject script into the URLs that would result in unquoted malicious script. Type 3-vulnerability is the most powerful XSS attack, and is referred to as persistent, stored, or second-order vulnerability. When user data is persistently stored in file or database and then later shown to other users without first being HTML quoted, vulnerability exists. Online message boards where users can post messages for others is an example of this. Attackers can inject a script a single time and have it negatively effect many other users with minimal social engineering. Users can bypass this problem by encoding data before it is re-displayed on another page. An extreme example of this was found in Indiatimes Email portal where users inboxes could be hijacked even if the victims hadnt opened the destructive email. A limited percentage of possible XSS vulnerabilities are listed here; there are hundreds of other examples attainable by the public.

2.2 Session Hacking [3]

In order to understand why an attacker is capable of hijacking a session, we need to comprehend what a cookies function is. Cookies store session IDs and authentication data for the time a user is at a site. This means that the attacker can only hijack the session as long as the user is on that site. The attacker can extract the session ID from the stolen cookie and use it for himself to make a connection to the site. Since the attacker has a valid session ID, he doesnt need to enter a username or password. The stolen cookie provides that information for the enemy.

Seminarpaper

Generics

2006

3 XSS-Proxy [5]
XSS-Proxy is fundamentally a cutting-edge Cross-Site-Scripting tool used in assaults. Cross Site Scripting has erroneously not stimulated great concern among certain security experts; however, XSS-Proxys ability to allow attackers to control attacks entirely remotely may change that misconception. This new generation of CrossSite-Scripting, especially with the additional aid of JavaScript Remoting, has the ability to make remote advances bi-directional, interactive, and above all, much more menacing to users. Once a diversion has been created and the victim has left the XSS window open, the attacker has imminent browser control. The attacker then has the ability to access other XSS susceptible sites or redirect distinct blind requests to other servers. One way this can occur is through XSS vectors sent by blogs, email, etc. A victim clicks on a URL and is redirected to another site (typically a banking, or other site that may hold person-particular account information) where the JavaScript sends a request for additional script commands. This is followed by a fairly complex process on the attackers side including submission processing, response forwarding, error management, etc. During the users idle time, the attacker has the capacity to view, alter, and submit the victims personal documents. In addition, the attacker can access the victims identity (especially in cases when the victim has logged into a particular site) and ride on the preexisting session (session-riding).

4 The Impact [6]

The negative impacts of XSS are far-reaching, diverse, and potentially devastating. If an attacker gains access to authentication cookies and session management tokens, the process of hijacking a victims session without going through the authentication process can be expedited. Making the situation more serious is the fact that the process is unfortunately easy to master. Due to the fact that damaging scripts are actualized in a seemingly trusted setting, the attacker has the opportunity to view the document fields filled out by the victim. Another possible incursion is for the attacker to create a hidden window on the victims machine, which would log each of the victims keystrokes (including passwords and other private information to be used by the attacker later). The attacker can also use malicious codes against HTTPS and override possible warning reports to the user. These situations can lead to identity theft, account hijacking, alteration of user settings, cookie theft, false advertising, and the spread of webmail-based worms. Attackers are most interested in sites that process credit card facts, produce results based on what a user enters into a search engine, and that store user content. For internet users or sellers, this topic is alarming and may pose many security issues. Holes in XSS can be devastating and costly to businesses, especially if the attacker publicizes the flaws. Such security leaks can deteriorate customerconsumer confidence. 6

Seminarpaper

Generics

2006

5 Vulnerability checking [7]

Analyzing your susceptibility of becoming a victim of a code insertion attack is a vital element of user internet safety. Ignorance of internet fraud puts users at the front line for attacks. Despite the fact that many users are aware of holes in security, they lack the knowledge to close them. The road to protection can be very basic and involves the interpretation of client-side HTML composition. One of the simplest ways of analyzing your weakness is by entering a scripting format. By entering a scripting format into all input fields, application vulnerability can be assessed. If a warning appears in the form of XSS Vulnerable, you are dealing with a susceptible component. An improperly loaded HTML page after a script check is also an indication of page vulnerability. There are various other ways of assessing vulnerability as well, including assessment of hidden fields and variable string substitution. Also, once XSS holes have been evaluated, investigate if the site distributes cookies. Cookie theft can be accomplished in any site that operates with them. If an application component responds alternatively to GET and POST submissions, susceptibility is low to URL scripting strikes. New XSS attack methods are being developed every day which elevates the risks, and should encourage users to educate themselves.

6 Solutions and workarounds [8]

As alarming as this subject is, there are ways for users to protect themselves. The best advice is to only follow main and direct links to websites. If while surfing, a link catches your eye, search for its main site instead of clicking on the link. By following that rule, users will practically eliminate all associated risks. If you intend to read a message board from unknown users, protect yourself by switching off JavaScript in the browser settings or change your security settings to the maximum level of security. Another simple way to bypass XSS problems is to encode all HTML characters, so as to obstruct attackers from deciphering it as HTML. Furthermore, client-side scripts can, under some circumstances, by entirely bypassed by disabling scripting all together. Encrypted sites and others that operate with SSL (https) are equally exposed to attacks. A lock symbol on a browser does not necessarily indicate security. Attacks in those cases are simply being carried out through an encrypted connection.

Seminarpaper

Generics

2006

7 Conclusion
This paper points out how Cross-site Scripting can lead to identity-theft, account hijacking, alteration of user settings, cookie theft, false advertising, and the spread of webmail-based worms. These situations can occur unexpectedly and even to the most knowledgeable of users. Forms of hacking are developing right along with internet applications. Moreover, company reputations can be deteriorated, causing customer dissatisfaction and mistrust. New applications also come with formerly unknown holes that can be penetrated as soon as a technique arises that can do so. These risks could easily be counteracted if we could raise awareness and educate users. Also, by taking more time to assess and improve products before distributing them, companies can prevent this entire problem from the root.

Seminarpaper

Generics

2006

8 Appendix
Examples of Cross-site Scripting Example 1 [A]:
Phpnuke cross site scripting vulnerability Hi nuke webmasters, Phpnuke cross site scripting vulnerability Affected version : 5.3.1 and prior perhaps other...perhaps all PostNuke affected too. No more explanation, it is enough with cross site scripting...i'm bored with CSS vuln ;) http://www.phpnuke.org/user.php?op=userinfo&uname=&ltscript&gtalert(document.cookie); </script> This is an other way to stole cookies as i explain in my previous post but without using IE 5.5 vulnerability. http://www.isecurelabs.com/article.php?sid=230 regards,

Example 2 [B]:
Here a few holes that i've found in PHPNuke. 5 Cross Site Scripting. http://phpnuke.org/modules.php?name=Downloads&d_op=viewdownloaddetails&lid=02&ttitle= [JAVASCRIPT] http://phpnuke.org/modules.php?name=Downloads&d_op=ratedownload&lid=118&ttitle=[JAV ASCRIPT] http://phpnuke.org/modules.php?op=modload&name=Members_List&file=index&letter=[JAVA SCRIPT] http://phpnuke.org/submit.php?subject=[JAVASCRIPT]&story=[JAVASCRIPT]&storyext=[JAV ASCRIPT]&op=Preview http://phpnuke.org/user.php?op=userinfo&uname=[JAVASCRIPT] ==> This hole was not found by Aurelien Cabezon.

and /admin.php?upload=Go! who's the same that upload=1 .

Seminarpaper

Generics

2006

Example 3 [C]:
Phpnuke module.php vulnerability and php error_reporting issue From: =?iso-8859-1?Q?Cabezon_Aur=E9lien?= &ltaurelien.cabezon@isecurelabs.com> To: &ltbugtraq@securityfocus.com> Subject: [VulnWatch] Phpnuke module.php vulnerability and php error_reporting issue [ Phpnuke module.php vulnerability and PHP error_reporting issue ] on 16 december by Cabezon Aurlien | aurelien.cabezon@iSecureLabs.com As you know, there are many Cross site scripting issue on Phpnuke modules and other web application using PHP. There is a cross site scripting issue cause : [1] there is a lack to checks from user input in module.php [2] PHP does not have a good deal with error reporting I found my website vulnerable to an other cross site scripting vulnerability, i thougt the problem was in XForum (forum module for phpnuke) He was also, but it was too on the way that PHP report errors and deals with error messages. ---Vulnerable line in module.php--- include("modules/$name/$file.php"); ---Vulnerable line in module.php--Exploit : http://host.com/modules.php?op=modload&name=XForum&file=[hostile javascript]&fid=2 Hostile javascript could be : {script}alert(document.cookie);{/script} that display your cookie. replace {} by <> This crafted url cause the module.php script to make an PHP error reporting like this: ---php error report--Warning: Failed opening 'modules/XForum/.php' for inclusion (include_path='') in /home/foo/htdocs/modules.php on line 27 ---php error report--When your browser display the error reporting, it parses the hotile javascript too... I found an easy and fast way to fix this problem and other cross site scripting issue regarding module.php and other web application using PHP : Just turn off PHP error reporting and wait for a fix from PHP devel team :) The error_reporting function should check for bad inputs.

Temp fix for phpnuke module.php: ---start of module.php--error_reporting(0); //Add this line, Just turn off error_reporting //original file switch($op) {

10

Seminarpaper

Generics

2006

case "modload":/ if (!isset($mainfile)) { include("mainfile.php"); } if (ereg("\.\.",$name) || ereg("\.\.",$file)) { echo "You are so cool"; break; } else { include("modules/$name/$file.php"); } break; default: die ("Sorry, you can't access this file directly..."); break; } ---end of module.php---

11

Seminarpaper

Generics

2006

9 Bibliography
Online Sources 1. Bachfeld, Daniel. Cross-Site-Scripting: Datenklau ber Bande. 16 June 2006 < http://www.heise.de/security/artikel/print/38658> [1] 2. Endler, David. The Cross Site Scripting FAQ. 16 June 2006 < http://www.cgisecurity.com/articles/xss-faq.shtml> [6] [7] [8] 3. GNU Free Documentation License. Cross-site Scripting. Wikipedia The Free Encyclopedia (2006). 16 June 2006 < http://en.wikipedia.org/wiki/Cross_site_scripting> [2] [8] 4. - - -. Cross-site Scripting. Wikipedia The Free Encyclopedia (2006). 16 June 2006 < http://de.wikipedia.org/wiki/Cross_Site_Scripting> [2] [8] 5. Ollmann, Gunter. HTML Code Injection and Cross-site Scripting. 16 June 2006 < http://www.technicalinfo.net/papers/CSS.html> [4] [6] [7] 6. Rager, Anton. XSS-Proxy. 16 June 2006 < http://xss-proxy.sourceforge.net/> [5] 7. Sumit, Siddharth, and Doshi Pratiksha. Five Common Web Application Vulnerabilities. 16 June 2006 <http://www.securityfocus.com/infocus/1864> 8. Champion, Steve. XSS, Trust, and Barney. 16 June 2006 <http://www.webmonkey.com/webmonkey/00/18/index3a.html> [8]

12

Seminarpaper

Generics

2006

Examples A. Aurlien, Cabezoni. Phpnuke cross site scripting vulnerability. 16 June 2006 <http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting. shtml> B. frog, frog. 5 PHPNuke Cross Site Scripting holes. 16 June 2006 <http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.shtml > C. Aurlien, Cabezoni. Phpnuke module.php vulnerability and php error_reporting issue. 16 June 2006 <http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes .shtm> [11]

Figures Fig 1 Endler, David. The Evolution of Cross Site Scripting Attacks. 20 May 2002 <http://www.cgisecurity.com/lib/XSS.pdf>

13