04-webappsec-xss-xsrf

7/29/2019 04-webappsec-xss-xsrf

1/35

Copyright Justin C. Klein Keane

Information Security Training

Web Application SecurityXSS and XSRF


2/35


XSS

Cross Site Scripting

Also known as Arbitrary Script Injection

Extremely pervasive vulnerability on the web


3/35


Why XSS Exists

Web applications need to display user supplieddata back to the user

Difficulty in parsing user supplied data properly


4/35


Causes

XSS results from the failure to segragate:

Data

Instructions HTML uses plain text in the body of an HTTP

response deliver:

Instructions about layout Content to be displayed

Delimited using XML style tags


5/35


Effects

Attacker can take control of the browser

Session hijacking

Because browsers are becoming miniatureoperating systems this is extremely dangerous

Attacker can also load third party plugins from

remote sources This can lead to buffer overflow or other client

side attacks


6/35


How XSS Works

Attacker injects JavaScript into display

The Javascript can take many forms:

alert('foo');

Any tag or attribute that supports JavaScript

can be used!
http://foo/http://alert/http://alert/http://foo/


7/35


Reflected XSS

Script that is passed to the site is rendered backto the browser

Like string format vulnerabilities, originallyconsidered a harmless bug

Common scenarios is a search engine thatreturns a value of Your search for X returned Y

records Developers didn't care if site users cause pop-

ups to appear


8/35


Reflected XSS Takes Imagination

Attackers quickly figured out ways to exploitreflected XSS

URL passed variables used to redirect users to othersites

Combined with e-mail or link or form on another siteto create a trust compromise

Generally involves social engineering of some sort


9/35


Example

User enters search term

Code for search results page:

This is Reflected XSS


10/35


What happens

When user searches for

Some javascript;

The Javascript executes in the search resultspage

Most developers, understandably, look at thisand dismiss it

If you want to run JavaScript in your ownbrowser who cares!


11/35


Weaponizing

HTML can be encoded to obscure it

HTML can be included in e-mail, text

messages, and other mediums It is trivial to trick a user into clicking on links or

submitting forms


12/35


Sanitizing Text

Is not as easy as it seems

Eliminating '' will prevent most XSS, but

not all Often times developers want users to be able to

enter SOME tags (like bold, italics, etc.)

Many strategies for sanitizing XSS can beevaded


13/35


Simple Evasion Example

Application searches input for all occurrences of'


14/35


Persistent XSS

When malicious user input is actually stored bythe website

Used to affect all site users, or target siteadministrators

Some persistent XSS will only be visible toadmins

Ex: Usage reporting screens or log analysis


15/35


Another Example

Example:

User can upload an image file, with adescription

The app code displays:

User escapes the tag using double quotes


16/35


Sources of User Controlled Input

Form posts (POST)

URL variables (GET)

Cookie data

HTTP header variables (Referer, User Agent,etc.)

Client side data stores


17/35


Typical XSS Attacks

Attacker sends an e-mail to a user insisting theychange their account credentials and includes alink to your site the link actually includes an

XSS that redirects the user to attackercontrolled site where credentials are harvested

Attacker injects JavaScript to steal cookieswhich are used for session hijacking


18/35


More XSS Attacks

Attacker injects JavaScript to manipulate display by hidingor overwriting page elements

Attacker injects a link or image that drives traffic to another

site (click fraud and Google jacking) Attacker injects JavaScript that records each keystroke

Attacker injects JavaScript that calls a malicious URL fordrive by downloading

Attacker injects JavaScript that exploits browservulnerabilities (or browser object vulnerabilities such asPDF)


19/35


XSRF Attacks

Client side scripts that perform backgroundactions using the authentication of a user

Can be extremely useful in bypassingauthentication

XSRF exploits the fact that browsers sendcookies by default with every page request

Limited somewhat by the same domain originpolicy of JavaScript


20/35


Typical XSRF

User logs into a target site as an admin

User views a page with a persistent XSS

The script then calls a form or submits an AJAXrequest with attacker determined values

Can be used to do things like change the user'spassword or perhaps exploit othervulnerabilities in authenticated areas of the site

Attacker uses XSRF to reset SOHO routersettings


21/35


Protecting Against XSRF

Forms contain a transitory token that is tied tothe user account

Token must then be passed in the formsubmission in order to carry out an action

Even this is not foolproof as a clever XSRF caninstantiate an iframe that includes a legitimate

call to the form, with a valid token


22/35


Other XSRF Defenses

Require a user to fill in existing password inorder to change it

Auto complete on form fields can defeat eventhis protection, however


23/35


XSS & XSRF Obfuscation

JavaScript is commonly encoded

URL encoding

Base64 encoding ROT13

JavaScript may be calling externally hostedJavaScript


24/35


Obscure XSS

Image tags can be used to display JavaScript

CSS can also be used to display JavaScript on

IE using the exec() statement Iframe source can be JavaScript

META refresh tags

Object tags For more see http://ha.ckers.org/xss.html


25/35


Preventing XSS & XSRF

Essentially a problem of validating user input

Filters for known bad are especially

dangerous with XSS New techniques emerge regularly

Browsers change

New web browsers emerge


26/35


Mitigation Strategy

Disallow HTML

Don't utilize user supplied input in display

(including scripts) without careful sanitization DO NOT ALLOW BAD DATA INTO THE DB!

Do NOT sanitize exclusively on output!

Use a library for translation

This can be useful if the library is centrally maintainedas it can easily evolve

Still a broadside approach, not as effective as limitingto known good


27/35


Useful PHP Functions

htmlspecialchars()

'&' to '&'

to " ' to '

< to to >

htmlentities()

Much more thorough, all characters with HTMLequivalents are translated.


28/35


More PHP

strip_tags() - strips out all HTML (and PHP)tags

Can optionally allow certain tags fgetss() - same as fgets(), which gets a line

from a pointer, but strips tags


29/35


More Useful PHP Functions

ereg_replace()

Allow only characters you want

eregi_replace() preg_replace()


30/35


Testing for XSS

Largely manual

Include input that contains multiple control

characters (',,>,


31/35


Automated Testing

Automated testing for XSS is extremely difficult

XSS only functions in the browser environment

Complex testing could potentially crash thetarget web application, or at least destroydisplay

It is much easier for a human to deduce filteringstrategies used by an application


32/35


Filter Evasion Techniques

Alternating case:


33/35


Filter Exploitation

Be careful that any filters you use can't be usedagainst you

Filters that remove text might actually be usedto de-mangle input:

A filter that removes the string canbe defeated using the input:


34/35


Other Concerns

XSS in uploaded files (images, PDF, etc.)

Code analysis may not be as effective

Extremely difficult to spot given the dynamicnature of HTML display

AJAX and other interactions complicate pagerendering


35/35


Exploit Techniques

Enter text such as alert('foo');in every possible input value and observeresults

Be sure to examine source to reveal subtletiesor partially effective injection that can bemanipulated to full XSS

Upload images with names like.jpg

04-webappsec-xss-xsrf

Documents