вход по аккаунту


Protecting Web Applications from Universal XSS - owasp

код для вставкиСкачать
Protecting Web Applications
from Universal PDF XSS:
A discussion of how weird the web
application security world has become
Ivan Ristic
Chief Evangelist
Breach Security
Version 1.3 (28 June 2007)
Copyright В© 2007 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the
terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this
license, visit
The OWASP Foundation
Table of Contents
1. Introducing the PDF XSS
2. Fixing the problem.
3. Experimenting with content
4. Conclusions, lessons learned,
V1.3 - 28 June 2007
About Ivan Ristic
пЂјSoftware developer/technical
architect/security analyst/whatever.
пЂјWeb application security and web
application firewall specialist.
пЂјAuthor of Apache Security.
пЂјAuthor of ModSecurity.
пЂјEmployed by Breach Security
to work on ModSecurity.
V1.3 - 28 June 2007
V1.3 - 28 June 2007
DOM-based Cross-Site Scripting (1)
пЂјIt all started back in 2005 when Amit Klein
published DOM Based Cross Site Scripting
or XSS of the Third Kind.
пЂјAmit observed that XSS does not necessarily
need a vulnerable server-side programme to
manifest itself. Everything can take place in the
browser itself.
пЂјHe also observed how the # character can be
used to, very conveniently, avoid sending attack
payload to the server.
V1.3 - 28 June 2007
DOM-based Cross-Site Scripting (2)
пЂјDOM-based XSS typically uses JavaScript.
Example (taken from Amit’s paper):
var pos = document.URL.indexOf("name=") + 5;
пЂјNormally invoked with:
пЂјDoes not work equally well when invoked with:
V1.3 - 28 June 2007
Enter Acrobat Reader Universal PDF XSS (1)
пЂјIn December 2006 Stefano Di Paola and
friends speak about the universal XSS flaw in the
Acrobat Reader plug-in on Windows.
пЂјThe world found out when the advisory went out
on January 3rd, 2007. (The flaw was already
fixed in Reader v8 in early December 2006.)
пЂјThe word spread like fire among security
bloggers (pdp) and on the mailing lists.
пЂјRSnake discovered the attack can be used
against PDF files hosted on the local filesystem.
V1.3 - 28 June 2007
Enter Acrobat Reader Universal PDF XSS (2)
For many people this was the
last straw. They acknowledged
that the end of the World is near.
V1.3 - 28 June 2007
So What Was the Problem?
пЂјIt turns out the Reader plug-in loved JavaScript
so much it would execute it when a link in the
following format is encountered:
пЂјNotice the # character!
V1.3 - 28 June 2007
Threat Assessment (1)
пЂјDiscoverability - 10
пЂјReproducibility - 10
пЂјExploitability - 7
пЂґAttack code not trivial but not very difficult to write.
пЂґVictim must click a link (e.g. in email) or visit a
malicious web site. Both attack vectors are examples
of CSRF.
пЂјAffected users - 10
пЂґPDF is a standard for printable documentation.
пЂґMost computers have Adobe Reader installed.
пЂґMost sites carry PDF files.
V1.3 - 28 June 2007
Threat Assessment (2)
пЂјDamage potential - 8
пЂґAfter a successful attack the code is executed in the
context of the site that hosts the PDF file.
The attacker is in full control of the victim’s browser
(think session hijacking, request forgery, etc.).
пЂґIndividual users are fully compromised.
пЂґSystem compromise is possible through escalation.
пЂґWhen a locally-hosted PDF file is targeted attackers
can gain access to the workstation (requires further
tricks to be used, e.g. the QTL hack, but doable).
пЂґDamage potential depends on site content.
V1.3 - 28 June 2007
Threat Assessment (3)
пЂјThe potential for damage is there, all right, but
where are the exploits?
пЂґMany expected doom and gloom but no major scale
attacks reported so far. Why?
пЂјWhere do we stand today?
пЂґThe excitement is gone.
пЂґSecurity-aware people have fixed the problems (or
have they?).
пЂґBut how many vulnerable people and sites remain?
пЂјThis problem is as dangerous as it was a few
months ago.
V1.3 - 28 June 2007
Fixing the
V1.3 - 28 June 2007
Fixing The Problem - Users
пЂјIn many ways this is a simple problem to solve.
Just upgrade the client-side software:
пЂґAdobe Reader 8 not vulnerable.
пЂґInternet Explorer 7 not vulnerable.
пЂґOther PDF viewers (e.g. Foxit Reader) not vulnerable.
пЂјAlternatively, you can
configure the browser not
to open PDF files at all.
пЂјBut we know many users
will not upgrade.
V1.3 - 28 June 2007
Fixing The Problem – Sites (1)
пЂј Not possible to detect attack on the server.
пЂґ Sites that allow user-contributed content can scan
links to prevent attacks against their users.
 Therefore our only option is to “protect” all PDF files
no matter if they are being attacked or not.
пЂј Proposed mitigation revolves around three ideas:
1. Moving PDF files to some other domain name.
2. Preventing browsers from recognising PDF files. (Some are
very stubborn in this regard.)
3. Forcing browsers to download PDF files.
пЂј This can be done via header modification in web server
configuration (all files or static files only, depending on
the web server) or application (dynamic files only).
V1.3 - 28 June 2007
Fixing The Problem – Sites (2)
пЂјKey headers:
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=x.pdf
пЂјApache "fix":
AddType application/octet-stream .pdf
<FileMatch "\.pdf$">
Header set Content-Disposition \
"attachment; filename=document.pdf“
пЂјDetailed instructions available from Adobe:
V1.3 - 28 June 2007
Forcing PDF Documents to Open Inline
пЂј Interestingly, it is possible to force PDFs to be opened
inline using the <OBJECT> tag:
<object data=""
пЂј This works in spite of the specification, which is clear on
this issue (HTML 4):
"If the value of this attribute differs from the HTTP Content-Type
returned by the server when the object is retrieved, the HTTP
Content-Type takes precedence."
пЂј In my tests (using FireFox 2.0.1) such PDFs have access
to the page that embeds them and not to the site where
they originate from. There appear to be other
restrictions (e.g. XMLHttpRequest does not work).
V1.3 - 28 June 2007
Analysis of the Solution So Far
пЂґEasy to use. The web server configuration-based
approach is very easy to implement.
пЂґNot all web servers support the technique. The
alternative, changing application code, is very time
пЂґForcing downloads of PDF files is not very user
friendly (many users will get confused).
пЂґDynamically-generated PDF
files are easy to forget (and thus miss).
V1.3 - 28 June 2007
Let's Look at the Fix Again!
пЂјApache "fix":
AddType application/octet-stream .pdf
<FileMatch "\.pdf$">
Header set Content-Disposition \
"attachment; filename=document.pdf“
пЂјThis works for static files only!
V1.3 - 28 June 2007
Sidebar: Approaches That Do Not Work
пЂјTrying to detect attack from the server.
пЂґNot possible to see the attack from the server.
пЂјRelying on the Referer request header.
It’s not always there.
пЂґCan be forged (e.g. from Flash).
пЂјChanging Content-Type alone.
пЂґIE will sniff the content to override the C-T.
пЂјURI Encryption & Requiring sessions:
пЂґDefied using session fixation.
пЂґNot usable on public sites anyway.
V1.3 - 28 June 2007
Using Redirection (1)
пЂј Amit Klein proposed a defence mechanism, which was
subsequently discussed and refined on the mailing lists:
пЂј While searching for a better solution many people
noticed that it is possible to overwrite the attack payload
using redirection and a harmless fragment
пЂј If we get:
We redirect to:
V1.3 - 28 June 2007
Using Redirection (2): Preventing Loops
But how do we tell we’ve already redirected the
If we don’t we’ll just end up with an endless loop.
пЂјWe can use one-time tokens as flags.
пЂјSo this:
Is now redirected to:
V1.3 - 28 June 2007
Using Redirection (3): Token Generation
пЂјIf we want to use random tokens then we have
to keeping state on the server (i.e. have a token
repository with a garbage collection mechanism
to collect expired tokens).
It’s a fine approach.
пЂґBut it can have non-negligible impact on the
performance and maintenance of non-trivial sites.
пЂґIt can also affect cacheability.
пЂјAlternatively, we can store state on the client.
пЂґUse cryptography to validate tokens.
пЂґEmbed the expiry time in tokens.
V1.3 - 28 June 2007
Using Redirection (4): Token Hijacking?
пЂјUnfortunately, our solution is not foolproof yet.
пЂјThe attacker can simply generate a number of
tokens to use against his victims.
пЂґWe have to associate tokens with clients
somehow. We need something people have.
First thought to use application sessions but…
пЂґNot all sites use sessions.
пЂґExploitation possible through session fixation anyway.
пЂґThus we have no choice but use the IP address.
пЂјBut what happens if the IP address changes
(user behind a proxy)?
пЂґWe fall back to forced download.
V1.3 - 28 June 2007
Using Redirection (5): It’s Not Foolproof!
пЂјThere are still holes in our solution!
пЂјIf the attacker shares the same IP address as
the victim (proxy, NAT) he will be able to obtain
tokens to use in attacks.
пЂґThe timeout feature does not help much.
пЂґIf the attacker can get the victim to browse a
malicious web site he can:
 Generate responses dynamically while…
 …obtaining valid tokens behind the scenes.
пЂјAt best, we can prevent mass-exploitation.
пЂґFocused attacks remain an issue.
V1.3 - 28 June 2007
A Foolproof Protection Mechanism Would…
пЂјA foolproof protection mechanism would:
пЂґAssociate tokens with client SSL certificates. (Or to
session IDs where sessions have already been
associated with client SSL certificates.)
пЂґThis would prevent session fixation.
пЂјAnd it would only work on:
пЂґSites that have sessions and
пЂґWe would have to know where the session ID
пЂјNot usable as a general purpose protection
V1.3 - 28 June 2007
Implementation Details
пЂјMost protection mechanisms rely on detecting
PDF extension in the request URI.
Let’s have a look at some request types:
пЂґ GET /innocent.pdf
пЂґ GET /download.php/innocent.pdf
пЂґ GET /download.php?file=innocent.pdf
пЂґ GET /download.php?fileid=619
пЂґ POST /generateReport.php
(with a bunch of parameters in the request body)
пЂјTo catch all use cases we have to inspect the
outgoing headers. Just one example:
Content-Type: application/pdf
V1.3 - 28 June 2007
Potential Performance Issue
пЂјThere is a potential performance issue if we
redirect a GET request based on what we see in
the response headers.
пЂґThe PDF is going to have to be generated twice.
Think long-running reports… not good.
There is a way to solve this but it’s a bit of a
stretch – suspend response:
пЂґStore the response (PDF) into a temporary file.
пЂґRedirect request, serving the PDF (from the
temporary file, without invoking the backend) when
we see the corresponding token again.
V1.3 - 28 June 2007
Can we deal with POST requests?
пЂјNo; all redirections are to a GET.
пЂґWe lose POST parameters.
пЂјWell, strictly speaking, there is a way:
пЂґWe could respond with a page that contains a selfsubmitting form with original parameters.
пЂґOr, as we did on the previous slide we could
suspend the response or suspend the request
пЂјBut that would be a bit too much:
пЂґIt could break applications in subtle ways.
It’s probably “cheaper” to simply force PDF download
in such cases.
V1.3 - 28 June 2007
Redirection Defence Implementations
пЂјModSecurity (as of 2.5.0-dev1):
пЂјJava Servlet filter:
пЂј.Net filter:
пЂјUsing mod_rewrite:
пЂјF5 Solution using iRules:
пЂјThere may be others...
пЂґLet me know if you know of any.
V1.3 - 28 June 2007
ModSecurity Implementation
пЂјAs of ModSecurity 2.5.0-dev2 you can choose
whether you want to use token-based defence
or force download of all PDF files.
пЂґThe only implementation (at this time, at least)
that detects PDF files dynamically.
SecPdfProtect On
SecPdfProtectMethod ForceDownload
SecPdfProtect On
SecPdfProtectMethod TokenRedirection
V1.3 - 28 June 2007
Universal PDF XSS Defence Conclusion
пЂјThere is no perfect solution - only a trade-off
between security, usability, and performance.
пЂґIsn't everything?
пЂјFlaws to be aware of:
пЂґToken-based protection cannot protect from
attackers sharing IP address with you.
пЂґMust fall back to forced download for
dynamic requests.
пЂјIn general:
пЂґCarefully examine your chosen defence method
to understand exactly when you are protected!
V1.3 - 28 June 2007
Experimenting with
Content Injection
V1.3 - 28 June 2007
Client-side Defence Using Content Injection
пЂјCan we detect DOM-based XSS attacks?
Why don’t we inject a JavaScript fragment at the
top of all outgoing HTML pages?
пЂґThe JavaScript fragment will run in the browser.
пЂґIt can get to the fragment identifier.
пЂґIt can talk back to the server if anything suspicious is
 But it’s trivial for someone (i.e. the adversary) to willingly
produce too many to cause false positives.
– Come to think of it, the same goes for any attack type.
пЂґPrevention might even work!
V1.3 - 28 June 2007
Content Injection Example
пЂј Starting with 2.5.0-dev1 ModSecurity supports content
injection (prepend & append features).
пЂґ We are likely add features to inject content at arbitrary places in
HTML at a later date.
пЂј Example code:
SecRule RESPONSE_CONTENT_TYPE ^text/html \
пЂј With JavaScript:
SecRule RESPONSE_CONTENT_TYPE ^text/html \
'<script>document.write(\'Hello World\')</script>'
V1.3 - 28 June 2007
Content Injection Use Cases
пЂјPossible uses of content injection:
пЂґDetect & prevent DOM-based
Cross-Site Scripting attacks.
пЂґDetect anomalies (potential attacks) in DOM.
пЂґPerform DOM hardening at run-time.
пЂґInstall code to intercept JavaScript events.
пЂґEven non-HTML responses can be replaced with an
intermediate self-refreshing HTML page.
V1.3 - 28 June 2007
lessons, etc...
V1.3 - 28 June 2007
пЂјThe PDF XSS issue goes to the checklist of
security professionals as a new problem all web
applications must deal with.
пЂјIt's practically impossible to design and deploy a
web application securely.
пЂґIt's possible to get very close in a small number of
cases – but at what cost?
пЂјThere is no hope for the current web application
security model.
пЂґAnd we are sick from having to deal with it!
V1.3 - 28 June 2007
Collaborative Security Research
пЂјIndividually we are not smart enough to deal
with the web application security issues.
пЂґToo many environments and too many moving parts.
Takes too long – we need parallelism for speed.
пЂјExciting things happen when a discussion is
sparked in the community.
пЂјCollaborative security research is the only viable
option. It's not perfect:
пЂґIt lacks form and structure.
пЂґThere is a lot of bad advice given.
пЂґGood advice and conclusions need to be gathered.
V1.3 - 28 June 2007
Links and Resources
пЂј Vulnerability information:
пЂј Blogs:
пЂј Mailing lists:
V1.3 - 28 June 2007
The End!
пЂјDo you have any questions?
пЂјCredits (in chronological order):
Amit Klein
Stefano Di Paola
Giorgio Fedon
Elia Florio
Petko D. Petkov (pdp)
Robert Hansen (RSnake)
James Landis
Anonymous Slashdot user
Robert Auger
Martin O'Neal
Tom Spector
Ofer Shezaf
Ivan Ristic
пЂґ...and others from the community.
 You know who you are!
V1.3 - 28 June 2007
Размер файла
342 Кб
Пожаловаться на содержимое документа