Cross-Site Scripting

Transcription

1 Cross-Site Scripting (XSS) Computer and Network Security Seminar Fabrice Bodmer UNIFR - Winter Semester

2 XSS: Table of contents What is Cross-Site Scripting (XSS)? Some statistics Security in client-side scripting How does XSS work? Types of XSS How to prevent XSS? Demonstration

3 What is XSS? (1) The term cross-site scripting is a not very accurate description of a class of vulnerabilities It isn t just about scripting, and there isn t necessarily anything cross-site about it. (Marc Slemko) XSS CSS In short, XSS is a class of vulnerabilities which allow injection of code into the client side of a web application.

4 What is XSS? (2) It allows malicious users to : bypass access controls gain higher-level rights deface web pages get sensitive data (e.g. usernames & passwords or credit card numbers) etc. It often involves or is used in conjunction with socialengineering techniques (often the victim is fooled with a prepared URL).

5 What is XSS? (3) The most obvious targets are sites which allow the publication of content displayed to other users (blogs, forums, web 2.0, etc.) Basically, XSS is possible because of client-side execution of scripts and the lack of filtering of the content submitted by users The scope of the attack is limited to manipulations on the client view of the victim. XSS is not about hacking the server (at least not directly).

6 What is XSS? (4) XSS vulnerabilities are very frequent because: It is not considered as a serious flaw by web developers (in opposition to sql injection vulnerabilities) the consequences are largely under-estimated Seems to be #1 cause of security holes in today s web applications All this piqued our interest and we decided to see how secure other popular social networking sites are against "wormable" XSS vulnerabilities. We picked two among the top social networking sites with a reported combined user base of 80 million. Within half an hour we had discovered over half a dozen potentially "wormable" XSS vulnerabilities in each site! We stopped looking after finding half a dozen, but we are sure there are a lot more holes in there. With about a day's work a malicious attacker with a half-decent knowledge of javascript could create a worm using just one of these vulnerabilities. SGMasood on f-secure weblog (July 27, 2006)

7 Some statistics... Redirection Phishing Path Traversal Known Vulnerabity Insufficient Anti-automation HTTP Response Splitting Directory Indexing Denial of Service Defacement Brute Force Worm Other Content Spoofing Abuse of Functionality Weak Password Recovery Validation Information Leakage Predictable Resource Location OS Commanding Insufficient Authentication SQL Injection Credential/Session Prediction Insufficient Authorization Unknown Cross-site Scripting Insufficient authorisation & authentication 16% These statistics only include media reported security incidents that can be associated with a web application security vulnerability. Only targeted attacks are tracked. [number of incidents] Other / Unknown 39% SQL injection 9% Credential / Session prediction Cross-site scripting 9% 27% Source:

8 Security in client-side scripting With the introduction of client-side scripts (Netscape 2.0), the developers realized the necessity of defining a security policy. Problems to solve: Access to properties of a page in another window Access to cookies definition of the same-origin policy

9 The same-origin policy Netscape s solution to prevent document or script loaded from one origin from getting or setting properties of a document from a different origin. Two pages are considered to have the same origin if the protocol, port, and host are the same for both pages. Example: Other browsers implement similar access-control policies (security zones in IE).

10 How does XSS work? Theoretically it is impossible to get information from a page or from a browser session with a script contained on a page with a different origin host. The art of XSS is about finding a hole allowing to bypass the security mechanisms implemented by the browsers. For example, by finding clever ways of injecting malicious code into pages seen by the victim.

11 XSS Attack vectors Injecting through (html) form inputs URL injection (URL sent by or IM to the victim, or posted on public sites) Referrer injection Injection through other inputs ( , sms, etc.)

12 The (malicious) payload To be malicious, the payload has to be interpreted by the client (most of the time it is a web browser) when rendered on the victim s screen. simple HTML / CSS javascript / vbscript (?) flash etc.

13 Ideas to bypass input verification... (1) Even web applications which validate user inputs can be the target of XSS attacks... Some strategies to bypass such checks: <div style="background:url('javascript:alert(1)')"> Some browsers accept javascript in CSS <div style="background:url('java\nscript:alert(1)')"> If the keyword javascript is filtered out, you can try to write it as follows, some browser will still interpret it... alert(eval('document.body.inne' + 'rhtml')); // innerhtml is filtered out If keywords representing useful javascript methods are filtered out, you can use the powerful eval() function to interpret a concatenation of string. Why not even encode the javascript...

14 Ideas to bypass input verification... (2) If some character is filtered out, the method String.fromCharCode(int ascii) will return it from its ASCII number... Character encoding inconsistencies: <?php header('content-type: text/html; charset=utf-7'); $string = "<script>alert('xss');</script>"; $string = mb_convert_encoding($string, 'UTF-7'); echo htmlentities($string);?>

15 Different types of XSS XSS attacks are classified in 3 types: 1. DOM based or local 2. Non-persistent or reflected 3. Stored, persistent or second-order

16 Types of XSS (1) 1. DOM based or local XSS Precondition: the vulnerable page uses data from the document.location, document.url or document.referer properties in an insecure manner. The payload is never located in the html but in the URL. Thus also works with static pages. Only works with browser which do not modify the URL characters (of course IE 6.0 does not...) Used with social-engineering.

17 Types of XSS (2) 2. Non-persistent or reflected XSS Such holes show up when data provided by a web client is immediately used by the server to generate a page of result. Payload vector: mostly malicious URLs/links Used with social engineering.

18 Types of XSS (3) 3. Stored, persistent or second-order XSS The payload is stored on the server. Used with or without social engineering.

19 Types of XSS (4) Web application worms Second order XSS may lead to XSS viruses/worms. c.f. myspace XSS worm.

20 Some recent examples... WHID : Myspace Hack Spreading Date: 16 July 2006 WASC Threat Classification: Cross-site Scripting, Worm Source: Myspace seems to be a heaven for XSS worms. This one seems to be even more interesting as it uses JavaScript embedded in a flash file. It is also interesting as it seems to combine the popular political defacement trend with high level application layer exploit. WHID : Another google XSS Date: 04 July 2006 WASC Threat Classification: Cross-site Scripting An XSS vulnerability in the feature allowing adding an arbitrary RSS to personal web pages. Since this page resides on the main host, the executed JavaScript can access any google resource. WHID : PayPal Flaw Gets Accidental Two-Year Reprieve? Date: 16 June 2006 WASC Threat Classification: Cross-site Scripting While XSS vulnerabilities in public web sites are found daily, this one is of special interest. It was found in one of the sites most targeted by Phishers, it is exploitable for Phishing and was exploited. On top of that, it seems to have been discovered and reported to PayPal already two years ago but ignored due to a communication failure.

21 MySpace Hack Spreading The payload was a flash file with malicious javascript code inside. The payload simulated a user interaction with the server to modify the user s profile by adding html code which embeds the same flash file in every page the About Me section of the infected user is displayed. Like a worm, this XSS attack replicates itself... Fix: Remove the line below from the About Me section: <embed allowscriptaccess="never" src=" Hole which allowed the injection: Myspace was only partially filtering out html tags... the <embed> tag was still allowed...

22 How to prevent XSS? Validate and filter user-input At introduction time and before such content is displayed again in a web page. Encode special characters in html entities. Filter out html tags if the data is not rich text. Verify that incoming parameters are conform to what is expected. Use a firewall to drop frames containing known XSS based on a signature

23 Demonstration 2 real-life examples! 1. Stealing the PHP session id 2. Getting the user to type its username/password again Of course, the demoed holes will be corrected right after the presentation...

24 Conclusion XSS is an easy to abuse security hole... in particular if the user-inputs are not validated... kiddy-hackers will enjoy making funny scripts if you don t validate user-inputs... New XSS techniques are discovered regularly that find new ways to evade various security measures implemented by the browser scripting languages and new ways to fool users into falling into an XSS trap

25 References (1) Wikipedia.org, Cross-site scripting (2) Amit Klein, , DOM Based Cross Site Scripting or XSS of the Third Kind (3) Steve Champeon, Webmonkey.com, , XSS, Trust, and Barney (4) NGS / NISR, Gunter Ollmann, Second-order Code Injection Attacks (pdf file) (5) LWN.net, Cross-site scripting attacks (6) XSS (Cross Site Scripting) Cheat Sheet (7) Technical explanation of the MySpace worm