Srikar Nadipally. Outline Finding and Exploiting XSS Vulnerabilities Standard Reflected XSS Stored...

Srikar Nadipally

XSS Vulnerabilities

Outline

Finding and Exploiting XSS VulnerabilitiesStandard

Reflected XSS

Stored XSS

DOM based XSS

Prevention of XSS attackReflect

Stored

DOM

Standard

Use standard proof of concept

“><script>alert(document.cookie)</script>

Detecting Reflected XSS

Systematic approach of finding reflected attackFind all the entry points of the user input

Submit a benign alphabetical string in each entry point

Identify all the locations where the string is reflected in the applications response

For each reflection identify the syntactic context in which string appears

Submit modified data tailored to the reflection syntactic context, attempting to introduce the arbitrary script in to response.

If reflected data is blocked, try to understand and circumvent the application defensive filter

Example 1

Tag attribute valueReturn page contains the code

<input type=“text” name=“address1” value=“myxssscript”>

Ways to craft XSS exploit “><Script>alert(1)</script>“ onfoucus=“alert(1)

Example 2

Java Script String

If return page code is

<script> var a=‘myxsstest’; var b =123; </script>

Ways to craft XSS exploit

‘; alert(1); var foo=‘

Example 3

Atrribute Containing URL

Returned page code

<a href=“myxssscript”>Click here…</a>

Ways to craft XSS exploito javascript:alert(1)o #”onclick=“javascript:alert(1)

Stored XSS

Stored XSS vulnerability identification is quite similar to that of reflected XSS – submitting a unique string in every entry point within the application.

Once you identify every instance in which user controllable data is stored by the application and later displayed back to the browser, same process is followed as that of reflected XSS – determining what input to be submitted to embed valid JavaScript within the surrounding HTML and then besiege the filters that intervene with your attack payload process.

Techniques to test for stored XSS

Testing for XSS in Web Mail applicationsSend all kinds of unusual HTML content within emails to test for bypasses in input filters.

Restricting to standard email client will not give you enough control over the raw message content or the client may itself sanitize or clean up your malformed syntax.

Using UNIX sendmail command a raw email can be created in a text editor and send it.

Sendmail –t [email protected] < email.txt

mailto:[email protected]

Example

Raw email fileMIME-Version: 1.0From: [email protected]: text/html; charset=us-asciiContent-Transfer-Encoding: 7bitSubject: XSS test<html><body><img src=``onerror=alert(1)></body></html>

Techniques to Detect stored XSS

Testing for XSS in Uploaded Files

Hybrid File attacks – “hybrid files” - two different formats

Example: GIFAR (GIF + JAR)

Uploaded file attack using GIFAR

The attack using GIFAR files can be prevented in current versions of Java browser plug-in by validating whether JAR files being loaded actually content hybrid content.

Detecting DOM-based XSS

Manually walk through the application with your browser and modify each URL parameter to contain a standard test string.

“<script>alert(1)</script>

“;alert(1)//

‘-alert(1)-’

Displaying each returned page in the browser causes all client side scripts to execute referencing the modified URL parameter.

If you see a dialog box containing cookies, you will have found a vulnerability.

Detecting DOM-based XSS

Effective approach:

Review all client-side JavaScript for any use of DOM properties that may lead to a vulnerability.

DOM-tracer is a tool that helps you to automate this process

Preventing XSS attacks

Due to the different root causes different defense mechanisms needs to be applied for reflected and stored XSS on one hand and DOM-based on the other.

Reflected and Stored XSSIdentify every instance within the application where user-controllable data is being copied into responses including data that is copied from immediate request and also any stored data that is originated from any user at any prior time, including via out-of-band channels.

After identification, follow a threefold approach to prevent any actual vulnerabilities from arising.

…Continued

Threefold approach-Validate input

Validate output (Encode the output)

Eliminate dangerous insertion points

Validate input: The application should perform context-dependent validation of data when application receives user-supplied data that may copy into one of its responses at any future point.

Potential features to validate – data is not too long, contains only a certain permitted character set, matches a particular regular expression.

Different Validation rules should also be applied – names, email id’s, account numbers etc.

…Continued

Validate OutputData should be HTML-encoded to sanitize potentially malicious characters.

HTML encoding involves replacing literal characters with their corresponding HTML entities.

HTML encodings of the primary problematic characters are as follows –

“ — "

‘ — '

& — &

< — <

> — >

…Continued

Eliminate dangerous insertion pointsInserting user-controllable data directly into existing script code should be avoided wherever possible. This applies to the code within <script> tags, and also code within event handlers.

Allowing limited HTML

…Continued

Preventing DOM-based XSSApplication should avoid using client-side scripts to process DOM data and insert it into the page.

DOM-based XSS flaws can be prevented through two types of defenses-

Validate input

Validate output

Validate input:Attack can be prevented by validating the data about to be inserted into the document containing only alphanumeric characters and white space.

…Continued

Example:<script>

var a = document.URL;

a = a.substring(a.indexOf(“message=”) + 8, a.length);

a = unescape(a);

var regex=/^([A-Za-z0-9+\s])*$/;

if (regex.test(a))

document .write(a);

</script>

…Continued

Server-side validation can also be employed to detect requests that may contain malicious exploits by verifying the following:

The query string contains a single parameter.

The parameter’s name is message (case-sensitive check).

The parameter’s value contains only alphanumeric content

…Continued

Validate output:Applications can perform HTML encoding of user-controllable DOM data before it is inserted into the document.

HTML encoding can be implemented in client-side Javascript with a function like the following:

function sanitize(str)

{

var d = document.createElement(‘div’);

d.appendChild(document.createTextNode(str));

return d.innerHTML;

}

Request forgery

Also known as “Session riding” is related to session hijacking attacks, in which an attacker captures a user’s session token and thereby uses that application as that user.

Request Forgery vulnerabilities comes in two flavors:

On-site Request Forgery (OSRF)

Cross-Site Request Forgery (CSRF)

OSRF

Attack for exploiting stored XSS vulnerabilities.

OSRF vulnerabilities can exist even in situations where XSS is not possible.

Consider a message board application that lets users submit items that are viewed by other users. Messages are submitted using a request like the following:

POST /submit.phpHost: wahh-app.comContent-Length: 34type=question&name=daf&message=foo

…Continued

This request results in the following being added to the messages page:

<tr> <td><img

src=”/images/question.gif”></td> <td>daf</td> <td>foo</td>

</tr>

CSRFAttacker creates the innocuous-looking website causes the user’s browser to submit a request directly to the vulnerable application to perform some unintended action that is beneficial to the attacker.

CSRF attacks are “one-way” only.

Consider an application in which administrators can create new user accounts using requests like the following:

POST /auth/390/NewUserStep2.ashx HTTP/1.1Host: mdsec.netCookie: SessionId=8299BE6B260193DA076383A2385B07B9Content-Type: application/x-www-form-urlencodedContent-Length: 83

realname=daf&username=daf&userrole=admin&password=letmein1&confirmpassword=letmein1

…Continued

This request has three key features that make it vulnerable to CSRF attacks:

The request performs a privileged action. In the example shown, the request creates a new user with administrative privileges.

The application relies solely on HTTP cookies for tracking sessions. No session-related tokens are transmitted elsewhere within the request.

The attacker can determine all the parameters required to perform the action. Aside from the session token in the cookie, no unpredictable values need to be included in the request

…ContinuedAttacker can construct a web page that makes a cross-domain request to the vulnerable application containing everything needed to perform the privileged action.

Example of such attack:<html><body><form action=”https://mdsec.net/auth/390/NewUserStep2.ashx” method=”POST”><input type=”hidden” name=”realname” value=”daf”><input type=”hidden” name=”username” value=”daf”><input type=”hidden” name=”userrole” value=”admin”><input type=”hidden” name=”password” value=”letmein1”><input type=”hidden” name=”confirmpassword” value=”letmein1”></form><script>document.forms[0].submit();</script></body></html>

Questions

Srikar Nadipally. Outline Finding and Exploiting XSS Vulnerabilities Standard Reflected XSS Stored...

Documents

Transcript of Srikar Nadipally. Outline Finding and Exploiting XSS Vulnerabilities Standard Reflected XSS Stored...