CROSS-SITE SCRIPTING (XSS) ATTACKS

Transcription

1 CROSS-SITE SCRIPTING (XSS) ATTACKS Abu Khleif & Haitham Topics In security, Nov 28, 2016

2 CONTENTS Overview Types of XSS Vulnerabilities How to Determine If You Are Vulnerable? How to Protect Your Website? XSS Attack Code Examples Let s Do a demo! References

3 OVERVIEW

4 INTRODUCTION TO WEB APPLICATIONS Client-Side and Server-Side Front-End languages (HTML, CSS, JS,...) Back-End languages (PHP, ASP.NET, Java Servlet,...)

5 WHAT IS CROSS-SITE SCRIPTING (XSS)? Cross-Site Scripting (XSS) attacks are a type of injection. Malicious scripts are injected into otherwise trusted websites. An attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

6 WHAT IS CROSS-SITE SCRIPTING (XSS)? The end user s browser has no way to know that the script should not be trusted, and will execute the script; Because it thinks the script came from a trusted source. The malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

7 PROCEDURE OF XSS ATTACK Cross-Site Scripting (XSS) attacks occur when: 1. Data enters a Web application through an untrusted source, most frequently a web request. 2. The data is included in dynamic content that is sent to a web user without being validated for malicious content. The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute.

8 TYPES OF XSS ATTACKS

9 PERSISTENT (STORED, TYPE I) XSS ATTACK Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.

10 PERSISTENT (STORED, TYPE I) XSS ATTACK

11 PERSISTENT (STORED, TYPE I) XSS ATTACK

12 REFLECTED (NON-PERSISTENT, TYPE II) XSS ATTACK Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an message, or on some other web site. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user s browser. The browser then executes the code because it came from a "trusted" server.

13 REFLECTED (NON-PERSISTENT, TYPE II) XSS ATTACK

14 OTHER TYPES OF XSS VULNERABILITIES In addition to Stored and Reflected XSS, another type of XSS, DOM Based XSS was identified by Amit Klein in DOM: When a web page is loaded, the browser creates a Document Object Model of the page. The HTML DOM model is constructed as a tree of Objects.

15 DOM BASED (TYPE 0) XSS ATTACK A form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write). May be considered as a sub-class of reflected XSS attacks.

16 REFLECTED VS PERSISTENT XSS ATTACKS Reflected XSS Attack Most common type of web vulnerability. User input is immediately returned by a web application. No permanently storing for the user provided data. Persistent XSS Attack More devastating variant of a cross-site scripting flaw. Data provided by the attacker is saved by the server. Data provided by the attacker permanently displayed on "normal" pages returned to other users.

17 HOW TO DETERMINE IF YOU ARE VULNERABLE?

18 HOW TO DETERMINE IF YOU ARE VULNERABLE? XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

19 HOW TO PROTECT YOUR WEBSITE?

20 HOW TO PROTECT YOUR WEBSITE? Essentially, you need to treat all user input into your site as untrusted. It could be someone genuinely reaching out to you, or it could be malicious code. For example, a user might put a comment on your site consisting of some text between these two characters: <text>. Unfortunately < and > usually mean <executable code goes here> in HTML it could be a trap! With encoding, < and > get transformed into < and > which are gibberish to both you and your HTML renderer.

21 HOW TO PROTECT YOUR WEBSITE? If you re in search of more information, OWASP has put together a comprehensive cheat sheet for preventing XSS. First 2 rules are listed on the next slides. There are also companies who will, for a fee, scan your website for XSS vulnerabilities which aren t all as obvious as an unprotected comment-box and suggest remediation.

22 XSS PREVENTION RULES RULE #0 - Never Insert Untrusted Data Except in Allowed Locations Examples: <script>...never PUT UNTRUSTED DATA HERE...</script> directly in a script <!--...NEVER PUT UNTRUSTED DATA HERE...--> inside an HTML comment <div...never PUT UNTRUSTED DATA HERE...=test /> in an attribute name <NEVER PUT UNTRUSTED DATA HERE... href="/test" /> in a tag name <style>...never PUT UNTRUSTED DATA HERE...</style> directly in CSS

23 XSS PREVENTION RULES RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content Examples: <body>...escape UNTRUSTED DATA BEFORE PUTTING HERE...</body> <div>...escape UNTRUSTED DATA BEFORE PUTTING HERE...</div> Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. Using hex entities is recommended in the spec. In addition to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML entity. & & < < > > " " ' &#x27; / /

24 XSS ATTACK CODE EXAMPLES

25 XSS ATTACK CODE EXAMPLES <script> alert("xss"); </script> <iframe src= > <object type="text/x-scriptlet" data="

26 XSS ATTACK CODE EXAMPLES <html xmlns=" <head> <title>test Layout</title> <style type="text/css"> body, html { margin: 0; padding: 0; height: 100%; overflow: hidden; } #content { position:absolute; left: 0; right: 0; bottom: 0; top: 0px; } </style> </head> <body> <div id="content"> <iframe width="100%" height="100%" frameborder="0" src=" /> </div> </body> </html>

27 LET S DO A DEMO!

28 REFERENCES Cross-site Scripting (XSS) Types of Cross-Site Scripting Cross-site scripting Cross Site Scripting (XSS) Attacks How to Protect Your Website from Being Hacked XSS (Cross Site Scripting) Prevention Cheat Sheet Cross-site Scripting (XSS) Attack Learn About XSS Vulnerabilities, Injections and How to Prevent Attacks

29 GOODBYE =) Abu Khleif & Haitham