Cross-Site Scripting (XSS)

Transcription

1 Lam 1 Cross-Site Scripting (XSS) Christopher Lam December 15, 2008 CMPT-320 Dr. Stefan Robila Final Project Report

2 Lam 2 Abstract As the Internet becomes more and more complex, newly found vulnerabilities continue to develop and through web-based applications, these vulnerabilities are exploited. One of the most common styles of malicious attacks that come to mind is code injection. A form of code injection that is well-liked by many malicious web users that exploits these vulnerabilities is cross-site scripting (XSS). Not only are seventy percent of websites vulnerable to XSS, but it also allows the most powerful kinds of attacks. XSS is very easy to execute and very long and arduous to repair. For this reason, XSS is defined as the number one and utmost prevalent website vulnerability on the internet. Introduction Most websites today contain dynamic content which gives its viewers a more interactive and enjoyable experience. Instead of having a classic static website, a dynamic website is generated by two different types of interactivities: client-side scripting (used to change interface behaviors within a specific webpage) and server-side scripting (used to change the supplied page source between pages). In addition to creating a dynamic website, you are making yourself susceptible to a popular and very powerful security vulnerability that plain static websites are not. This threat is called cross-site scripting (XSS). XSS has come about as a result of defectively constructed coding within webbased applications. Attackers direct their attention towards these vulnerabilities and insert malicious content into the client-side browser without the user s knowledge which allows an attacker to gain access to the user s personal information. Cross-site scripting vulnerabilities have been around for a long time, and are found within almost any kind of dynamically generated website. As new XSS threats develop, malicious attackers will continue to discover innovative ways to exploit these weaknesses. It is necessary to have a comprehensive understanding of cross-site scripting due to its significant impact in today s internet security worldwide.

3 Lam 3 Overview The remainder of this paper will be organized as follows. There will be a general description of what cross-site scripting is. Then it will move onto a simple list of different types of programming languages used in the malicious code injections. That will be followed by the different types of XSS attacks. We will then describe the reasons why malicious attackers utilize XSS. After that, we will go on to illustrate different kinds of possible attack scenarios. This would then lead to the steps a malicious attacker takes to execute an XSS attack. The next segment explains the consequences of not fixing CSS/XSS holes. Then I will go on to demonstrate a practical example of XSS on a testing site. Afterwards, I will inform you of multiple ways to protect yourself against XSS. Finally, I will end my paper with a summary of cross-site scripting. Cross-Site Scripting Cross-site scripting (previously titled CSS, but later renamed to XSS because it was often confused for Cascading Style Sheets) is a type of computer security vulnerability that is found in web-based applications which allows code injection by malicious web users into any webpage that is viewed by other users. The term Cross-site scripting, originated when a malicious website could potentially load a website onto another window and then use JavaScript to read or write information on the other website, which was later redefined as injection. XSS is made possible due to the fact that faulty coding causes XSS holes (vulnerabilities on websites that allows attackers to avoid security measures) in the client-side script that allows for insertion of malignant code. During an attack, everything looks fine to the end user, but in actuality they are subject to a wide variety of threats. These vulnerabilities are exploited by attackers to bypass access controls such as the same origin policy (security measure preventing a document or script being loaded from one "origin" from getting or setting properties of a document from a different "origin"). XSS is a potentially dangerous vulnerability that is easy to execute and very long and arduous to repair. For this reason, XSS holes are rarely patched up because they exist in 7 out of every 10 websites, and take approximately 52 days to fix. Many site owners do not consider an XSS hole to be a big threat, which is a commonly made mistake because the consequences of an XSS attack against web

4 Lam 4 applications and its users have been proven to be extremely serious. The most frequent kinds of web applications that are victimized by XSS attacks are search engines, discussion boards, web-based s, and posts. Even the most well-known websites in today s world like Google, Yahoo!, MySpace, Facebook, PayPal, and WikiPedia were once victims and still are very susceptible to many kinds of XSS attacks. Programming Languages Utilized in XSS Attacks Sun Microsystems's Java Microsoft s Active X JavaScript Adobe s Flash Action Script HTML or XHTML VB Script RSS and Atom feeds The most commonly used programming languages during XSS attacks are HTML, XHTML, JavaScript, and Adobe s Flash. However the most popular and potentially the most detrimental language used by malicious attackers is JavaScript. Types of XSS Attacks There are three significant types of XSS vulnerabilities that exist and they are non-persistent, persistent, and DOM-based (which can be either persistent or nonpersistent). The first type of XSS vulnerability is known as DOM-based. It is also referred to as a Type 0 or a Local XSS. Document Object Model (DOM) is a platform for representing HTML or XML and other related languages. In this vulnerability, the problem exists within the pages client side script. If an attacker hosts a malicious site, which contains a vulnerable website on a client s local system, a script can be injected. Now the attacker can run the privileges of that user s browser on their system Local Zone. DOM-based vulnerabilities can be either persistent or non-persistent. [1] The second type of XSS vulnerability is known as non-persistent. It is also referred to as a Type 1 or a reflected vulnerability. It is by far the most common type of the three but is not nearly as popular as the others. If a web user provided data to a server-

5 Lam 5 side script to instantly generate a resulting page back to him/herself, a resulting page without html encoding can be intercepted by an invalidated user. The malicious clientside code can then be injected into the dynamic page. The attacker can apply a little social engineering (which is the power to manipulate someone to perform actions) to persuade a user to follow a malicious URL that will inject code into the resulting page. After the attacker has accomplished that, he now has full access to that web pages content. [1] The third and final type of XSS vulnerability is known as persistent. It is also referred to as a Type 2, a stored, or a second order vulnerability. This vulnerability is susceptible to the most powerful kinds of attacks. First, the data is stored on the server (in a database, file system, or other location) provided by a web application. Then it is later reopened and shown to other users on a webpage without any html encoding. An example of this is an online discussion or message board that allows users to sign in to post messages for other users to read. Persistent XSS is one of the more prestigious types of vulnerabilities because the malicious scripts are capable of being provided and used more then once. This means an attacker can exploit this vulnerability and affect a large magnitude of users. In addition to the huge number of users already at risk, this web application can also be infected by a cross-site scripting virus or worm. [1] Reasons Why XSS Vulnerabilities are Exploited Account Hijacking for identity theft Cookie theft/poisoning to acquire sensitive information Conduct phishing attacks Gain free access to otherwise paid for content Spy on a users web browsing habits Change a users settings False advertising Deface a website Insertion of hostile content Denial of service attack Public defamation of an individual of company

6 Lam 6 Attack Scenarios DOM-Based Attack [1] 1. Mallory sends via a URL of a maliciously constructed webpage to Alice. 2. Alice receives the and clicks on the link. 3. The malicious webpage's JavaScript opens up a vulnerable HTML webpage locally on Alice's computer. 4. The vulnerable webpage containing the JavaScript then executes on Alice s computers Local zone. 5. Now Mallory's malicious script can run commands with all the privileges of Alice s computer on her own computer. This is an example of a Cross-Site Scripting attack via . [5] Adapted from Paul Lee (paul@ca.ibm.com), I/T Architect, IBM Global Services [5]

7 Lam 7 Non-Persistent Attack [1] 1. Alice visits Bob s website frequently and logs in with a username and password. Bob s website stores billing information. 2. Mallory notices that Bob s website contains a Type 1 XSS vulnerability. 3. Mallory then cooks up a URL to exploit that vulnerability, and then sends Alice an making it look like it came from Bob. ( spoofing) 4. While logged into Bob s website, Alice clicks and views the malicious URL. 5. The malicious script then poses as Bob s website, and steals Alice s session cookie and sends it back to Mallory. 6. With Alice s session cookie, Mallory can steal everything Alice had stored on Bob s website. (Authentication credentials and billing information) This is an example of a Cookie theft and Account Hijacking. [5] Adapted from Paul Lee (paul@ca.ibm.com), I/T Architect, IBM Global Services [5]

8 Lam 8 Persistent Attack [1] 1. Bob hosts a website that allows users to post messages that can be viewed by other users at a later time. 2. Mallory notices that Bob s website has a Stored XSS vulnerability. 3. Mallory then posts a controversial message that encourages more users to view it. (Malicious URL) 4. After viewing the posted message, all the users session cookies are automatically sent to Mallory s web server without them knowing. 5. Later on, Mallory can log in as whom ever she wants, and then post messages posing as them. This is an example of a sending an unauthorized request. [5] Adapted from Paul Lee (paul@ca.ibm.com), I/T Architect, IBM Global Services [5]

9 Lam 9 Steps to an XSS Attack In order for a malicious attacker to execute a basic cross-site scripting attack, they must follow these four simple steps: 1. Select a target [2] The first step is to select a target. This is done by searching for an XSS hole in a web-based application on a website. Once you have discovered an XSS hole, you must look to see if that website contains any kind of cookies. If it does not, then you have failed and you must continue to look for another website. If it does, then you have succeeded and it is now possible for you to steal that cookie. You have finally selected a target. 2. Testing [2] The next step is to decide what kind of XSS hole this website contains because all XSS holes are different in how they are exploited. You must then run some tests to make sure the output is authentic looking. If the website appears to be broken, then you must modify your coding until it looks legitimate. When this is complete, you then plug in your JavaScript, or another kind of client-side scripting code, directing it towards the XSS vulnerability. 3. XSS Execution [2] You are finally ready to distribute your malicious URL in any way that might potentially help you launch it. However, you should make sure to Hex encode your URL to make it seem less obvious of its malicious intent. Now all you have to do is sit and wait. If you are a more experienced attacker, you could even do a few redirects and some XSS combo s to steal a user s cookie, and return the user to the website without them knowing their cookie was even stolen. 4. Decide what to do with the data [2] Once you get the user to execute your XSS hole, their cookie will be sent to your CGI script. The last thing to do is to use a program like Websleuth to see if account hijacking is possible. Adapted from Article #2 admin@cgisecurity.com "The Cross Site Scripting FAQ"

10 Lam 10 Compromises to Not Fixing XSS Holes Risk of account being taken over Having a hacker publish a warning about your company not fixing its problems Damages to your companies reputation Shows lack of security measures Shows clients you are irresponsible and not doing anything about your problems In turn, creates trust issues Why do business with you if you are not trustworthy Why do business with a faulty company A Practical Example of XSS on a Test Site This is a simple example of an XSS attack that has been tested on this Acunetix acuform test site. Below is a screenshot of a web-based application with an input field for running a search and also containing an XSS hole. This is how the website looks before any real malicious code is injected. Load the following link in your browser: [2]

11 Lam 11 After loading the following link in the browser: the testing site appears and then you continue to insert the following malicious code into the search field: <br><br>please login with the form below before proceeding:<form action="destination.asp"><table><tr><td>login:</td><td><input type=text length=20 name=login></td></tr><tr><td>password:</td><td><input type=text length=20 name=password></td></tr></table><input type=submit value=login></form> Then you click the search button and now a malicious login form was created and is now displayed in the screenshot shown below. This is an example of how easy it is to implement an XSS hole. With this fake login form, the attacker can now sit and wait as users come and fill out the fake form allowing their credentials to be stolen. The code entered to create the fake form contains a section shown above which mentions destination.asp. This code allows the attacker to decide where the fake login form information will be sent to. Afterwards, the user s log-in information is now in the hands of the attacker to do what ever he/she pleases.

12 Lam 12 Another alternative for an attacker to exploit the XSS hole in this testing site is to inject the code below by distributing this malicious URL. [2] %3A%3Cform+action%3D%22test.asp%22%3E%3Ctable%3E%3Ctr%3E%3Ctd%3ELogin%3A%3C%2Ftd%3E%3Ctd%3E%3Cinp ut+type%3dtext+length%3d20+name%3dlogin%3e%3c%2ftd%3e%3c%2ftr%3e%3ctr%3e%3ctd%3epassword%3a%3c%2 Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+length%3D20+name%3Dpassword%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftabl e%3e%3cinput+type%3dsubmit+value%3dlogin%3e%3c%2fform%3e Both sets of malicious code result in the same display page shown above. They also have the same affect in stealing a user s credentials. But the second set of malicious code jumps straight the resulting page causing the user to be easily fooled. Adapted from Jacques Guillaumier [2]

13 Lam 13 How to Protect Against XSS CHAR / < { ( [? # : % + CODE %2f &LT %7b &#40 %5b &#34 %3f &#35 %3a &#37 %7c &#43 CHAR \ > } ) & = ; ~ - CODE %5c &GT %7d &#41 %5d &#39 %40 &#38 %3d &#59 %7e &#45 Never trust Input & Always filter out metacharacters Encode locally or at a server View material only from official websites It will eliminate almost 90% of problems Be cautious when opening s from people you do not know, discussion boards, posts, etc. Turn off JavaScript in browser settings In IE, turn security settings on high Filtering Systems Server-side algorithms must reject broken HTML Input Validation A form accepting certain fields and having a server-side routine allow only specific characters (XSS custom tag library) All other characters would be removed Such result could not contain a malicious script Conclusion Cross-site scripting is one of the most dangerous and most common website vulnerability on the internet. An XSS attack comes in many forms that range from something as small as pop up in a window, to something as destructive as a virus or a worm, and even worse; XSS is capable of compromising a person s identity. Nobody in this world is ever completely safe from it. As XSS vulnerabilities continue to grow, the best way to protect yourself against it is to always be on the alert, and be aware of what you should do when you come across it.

14 Lam 14 References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] Underestimated-Exploit.html Picture References [1] lities/vulnerable02.jpg [2] [3] og/image.axd%3fpicture%3dcross%2beyed%2bscripting%2bbug.png&imgrefurl=http :// 7A8nC- 4J6Jd1heOY4HEg1bo4YRQ=&h=592&w=709&sz=292&hl=en&start=60&tbnid=bytIySB5 LrMoKM:&tbnh=117&tbnw=140&prev=/images%3Fq%3Dcrosssite%2Bscripting%26start%3D40%26gbv%3D2%26ndsp%3D20%26hl%3Den%26sa%3 DN [4] Ex5xbTHiHI/AAAAAAAAAOE/2xtRR9cT2Jo/s200/NoScript.png&imgrefurl= nfopowered.blogspot.com/&usg= rjx_euzpz0y8_tewb818rzd8ccs=&h=200&w=200&sz =37&hl=en&start=225&tbnid=5ULzggLJ0pPHmM:&tbnh=104&tbnw=104&prev=/images %3Fq%3Dcrosssite%2Bscripting%26start%3D220%26gbv%3D2%26ndsp%3D20%26hl%3Den%26sa%3 DN [5] sizer.ashx%3fn%3dhttp://backoffice.ajb.com.au%252fimages%252fnews%252fphishing money.jpg%26w%3d218&imgrefurl= oo-and-ebay-hook-up-on-phisherblocker.aspx&usg= 9kqYJaZ4d7WxWMuzvcv_VENQy6Q=&h=329&w=218&sz=19&hl= en&start=299&tbnid=0arllxgiugeqm:&tbnh=119&tbnw=79&prev=/images%3fq%3dcrosssite%2bscripting%26start%3d280%26gbv%3d2%26ndsp%3d20%26hl%3den%26sa%3 DN