Information Security Training Web Application Security Xss and XSRF

Information Security Training Web Application Security XSS and XSRF
Copyright Justin C. Klein Keane
XSS

Cross Site Scripting

Also known as Arbitrary Script Injection Extremely pervasive vulnerability on the web
Why XSS Exists
Web applications need to display user supplied data back to the user
Difficulty in parsing user supplied data properly
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

Effects

Attacker can take control of the browser

Session hijacking Because browsers are becoming miniature operating 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

How XSS Works

Attacker injects JavaScript into display The Javascript can take many forms:

<img src=javascript:foo/> <script>alert('foo');</script>
<a onMouseOver=javascript:alert('foo');>
<p style=foo:expression(alert('foo'))>
Any tag or attribute that supports JavaScript can be used!

Reflected XSS
Script that is passed to the site is rendered back to the browser Like string format vulnerabilities, originally considered a harmless bug Common scenarios is a search engine that returns a value of Your search for X returned Y records Developers didn't care if site users cause popups to appear
Reflected XSS Takes Imagination
Attackers quickly figured out ways to exploit reflected XSS

URL passed variables used to redirect users to other sites
Combined with e-mail or link or form on another site to create a trust compromise Generally involves social engineering of some sort
Example

User enters search term

Code for search results page:
<?php
echo 'Your search for ' . $_POST['term']; echo ' found ' . $count . ' results.';
?>
This is Reflected XSS
What happens
When user searches for
<script>Some javascript;</script>
The Javascript executes in the search results page Most developers, understandably, look at this and dismiss it
If you want to run JavaScript in your own browser who cares!

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
Sanitizing Text

Is not as easy as it seems

Eliminating '<' and '>' 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 be evaded
Simple Evasion Example
Application searches input for all occurrences of '<script' and replaces them with ''
Attacker enters: The substitution actually corrects the tag
<<scriptscript>Some JavaScript;</script>

Just one of many, many examples
Persistent XSS
When malicious user input is actually stored by the website

Used to affect all site users, or target site administrators Some persistent XSS will only be visible to admins
Ex: Usage reporting screens or log analysis
Another Example
Example:
User can upload an image file, with a description

The app code displays:
<?php
echo '<img src=file.jpg alt=' . $user_desc . '>'; ?>
User escapes the tag using double quotes
Sources of User Controlled Input

Form posts (POST)

URL variables (GET) Cookie data HTTP header variables (Referer, User Agent, etc.)
Client side data stores
Typical XSS Attacks
Attacker sends an e-mail to a user insisting they change their account credentials and includes a link to your site the link actually includes an XSS that redirects the user to attacker controlled site where credentials are harvested Attacker injects JavaScript to steal cookies which are used for session hijacking
More XSS Attacks
Attacker injects JavaScript to manipulate display by hiding or 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 for drive by downloading Attacker injects JavaScript that exploits browser vulnerabilities (or browser object vulnerabilities such as PDF)
XSRF Attacks
Client side scripts that perform background actions using the authentication of a user Can be extremely useful in bypassing authentication XSRF exploits the fact that browsers send cookies by default with every page request Limited somewhat by the same domain origin policy of JavaScript
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 AJAX request with attacker determined values Can be used to do things like change the user's password or perhaps exploit other vulnerabilities in authenticated areas of the site Attacker uses XSRF to reset SOHO router settings
Protecting Against XSRF
Forms contain a transitory token that is tied to the user account Token must then be passed in the form submission in order to carry out an action Even this is not foolproof as a clever XSRF can instantiate an iframe that includes a legitimate call to the form, with a valid token
Other XSRF Defenses
Require a user to fill in existing password in order to change it Auto complete on form fields can defeat even this protection, however
XSS & XSRF Obfuscation
JavaScript is commonly encoded

URL encoding Base64 encoding ROT13
JavaScript may be calling externally hosted JavaScript
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
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
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 maintained as it can easily evolve Still a broadside approach, not as effective as limiting to known good
Useful PHP Functions
htmlspecialchars()
'&' to '&' to " ' to '
< to <
> to > Much more thorough, all characters with HTML equivalents are translated.
htmlentities()
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
More Useful PHP Functions
ereg_replace()
Allow only characters you want
eregi_replace() preg_replace()
Testing for XSS

Largely manual
Include input that contains multiple control characters (',,>,<, \, ;)
View the source of the displayed input to determine if the result is vulnerable
Viewing source code is not always helpful in this testing
Automated Testing

Automated testing for XSS is extremely difficult

XSS only functions in the browser environment Complex testing could potentially crash the target web application, or at least destroy display It is much easier for a human to deduce filtering strategies used by an application
Filter Evasion Techniques

Alternating case: <ScRiPt Inject legal characters

script/src= <scr%00ipt
URL encoding input
<script>alert('foo');</script> <script>al& #101;rt('foo')&# 059;</script&#062 %3cscript%3e %253script%253e

Filter Exploitation
Be careful that any filters you use can't be used against you Filters that remove text might actually be used to de-mangle input:
A filter that removes the string <script> can be defeated using the input:
<scr<script>ipt>
Other Concerns

XSS in uploaded files (images, PDF, etc.) Code analysis may not be as effective Extremely difficult to spot given the dynamic nature of HTML display AJAX and other interactions complicate page rendering
Exploit Techniques
Enter text such as <script>alert('foo');</script> in every possible input value and observe results Be sure to examine source to reveal subtleties or partially effective injection that can be manipulated to full XSS Upload images with names like
<iframe src='blah' onerrror='alert(document.cookie)'>.jpg

Information Security Training Web Application Security Xss and XSRF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Security Training Web Application Security Xss and XSRF

Uploaded by

Copyright:

Available Formats

Information Security Training Web Application Security XSS and XSRF

Copyright Justin C. Klein Keane

Cross Site Scripting

Copyright Justin C. Klein Keane

Why XSS Exists

Copyright Justin C. Klein Keane

XSS results from the failure to segragate:

HTML uses plain text in the body of an HTTP response deliver:

Instructions about layout Content to be displayed

Delimited using XML style tags

Attacker can take control of the browser

This can lead to buffer overflow or other client side attacks

How XSS Works

<img src=javascript:foo/> <script>alert('foo');</script>

Any tag or attribute that supports JavaScript can be used!

Reflected XSS Takes Imagination

Attackers quickly figured out ways to exploit reflected XSS

Copyright Justin C. Klein Keane

User enters search term

This is Reflected XSS

Copyright Justin C. Klein Keane

When user searches for

If you want to run JavaScript in your own browser who cares!

HTML can be encoded to obscure it

It is trivial to trick a user into clicking on links or submitting forms

Copyright Justin C. Klein Keane

Is not as easy as it seems

Copyright Justin C. Klein Keane

Simple Evasion Example

Just one of many, many examples

Copyright Justin C. Klein Keane

When malicious user input is actually stored by the website

Ex: Usage reporting screens or log analysis

Copyright Justin C. Klein Keane

User can upload an image file, with a description

User escapes the tag using double quotes

Copyright Justin C. Klein Keane

Sources of User Controlled Input

Form posts (POST)

Client side data stores

Copyright Justin C. Klein Keane

Typical XSS Attacks

Copyright Justin C. Klein Keane

More XSS Attacks

Attacker injects JavaScript to manipulate display by hiding or overwriting page elements

Protecting Against XSRF

Copyright Justin C. Klein Keane

Other XSRF Defenses

Copyright Justin C. Klein Keane

XSS & XSRF Obfuscation

JavaScript is commonly encoded

JavaScript may be calling externally hosted JavaScript

Copyright Justin C. Klein Keane

Preventing XSS & XSRF

Copyright Justin C. Klein Keane

Use a library for translation

Useful PHP Functions

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

Copyright Justin C. Klein Keane

More Useful PHP Functions

Copyright Justin C. Klein Keane

Testing for XSS

Copyright Justin C. Klein Keane

<script>alert('foo');</script> <script>al& #101;rt('foo')&# 059;</script&#062 %3cscript%3e %253script%253e