InfoSec Training - Web App Sec

Comments

Transcription

InfoSec Training - Web App Sec
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
©Copyright Justin C. Klein Keane
Why XSS Exists


Web applications need to display user supplied
data back to the user
Difficulty in parsing user supplied data properly
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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!
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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!”
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
Simple Evasion Example


Application searches input for all occurrences of
'<script' and replaces them with ''
Attacker enters:
<<scriptscript>Some JavaScript;</script>

The substitution actually corrects the tag

Just one of many, many examples
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
Sources of User Controlled Input

Form posts (POST)

URL variables (GET)

Cookie data


HTTP header variables (Referer, User Agent,
etc.)
Client side data stores
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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)
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
XSS & XSRF Obfuscation

JavaScript is commonly encoded
– URL encoding
– Base64 encoding
– ROT13

JavaScript may be calling externally hosted
JavaScript
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
Useful PHP Functions


htmlspecialchars()
–
'&' to '&amp;'
–
“ to &quot;
–
' to &#039;
–
< to &lt;
–
> to &gt;
htmlentities()
–
Much more thorough, all characters with HTML
equivalents are translated.
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
More Useful PHP Functions

ereg_replace()
–


Allow only characters you want
eregi_replace()
preg_replace()
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
Filter Evasion Techniques



Alternating case: <ScRiPt
Inject “legal” characters
–
script/src=
–
<scr%00ipt
URL encoding input
–
<script>alert('foo');</script>

&#060;&#115;&#099;&#114;&#105;&#112;&#116;&#062;&#097;&#108;&#
101;&#114;&#116;&#040;&#039;&#102;&#111;&#111;&#039;&#041;&#05
9;&#060;&#047;&#115;&#099;&#114;&#105;&#112;&#116;&#062

%3cscript%3e

%253script%253e
©Copyright Justin C. Klein Keane
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>
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane
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
©Copyright Justin C. Klein Keane

Similar documents