Re: Universal PDF XSS Remediation (Fix)

["Ivan Ristic" <ivan.ristic () gmail com>]

Hi Cyrill,

Thank you for an entertaining read. I was looking forward to reading a
comprehensive coverage of the PDF XSS issue when I saw your email. But
I was disappointed when I discovered your document falls short of
being the advertised "definitive solution".

In brief I think you failed to support your claims that other
competing approaches are faulty where your proposed solutions is not.
Let me elaborate further.

1) You say that "Some entry server products can partly mitigate
Universal PDF XSS attacks..." but you don't really go into how they do
that, when they are successful and when they aren't. In particular you
used the word "partly" but we can only speculate if you meant to say
that none of these solutions are 100% effective, or if they can be
100% effective but only in certain circumstances. Furthermore you talk
about one "feature" but I am pretty sure there are differences in
implementations among products, making it difficult to treat all of
them in the same manner.

2) On the second page you say "Furthermore, the referrer can be
spoofed (e.g. using Flash)". It would have been nice to explain
exactly how this can be done and quantify the impact of the
possibility of spoofing in addressing the PDF issue.

3) I have essentially the same comment for the "Internet Explorer
MIME-Sniffing feature still causes the Plug-in to start". Won't MIME
sniffing affect the Content-Type of the response only. Which versions
of IE will override the Content-Disposition attachment setting?

4) When you say "Unfortunately, the client IP address in entry server
and proxy environments is always the same and therefore an attack
during the ten seconds timeout is still possible", I take it you mean
the real client IP address is hidden from a backend web server when a
reverse proxy is used? If so that is true, but also trivial to handle
(e.g. by inspecting the X-Forwarded-For request header at the backend
server, which contains the required real IP address). It is true that
there is a window of opportunity of ten seconds (by default) in
certain circumstances but this risk needs to be quantified. It would
have been interesting to see a discussion here of how proxies using IP
addresses that change with every request, and attackers that share a
proxy (or a NAT network) with the victims.

As for your proposed solution - I agree it can be more secure, but
only in certain circumstances. I have three points to make:

1) The solution is pretty good if you can rely on the existence of
Cookie-based session tokens. Where it falls short, however, is when
clients won't accept cookies. You suggest using URL-rewriting to
handle the issue but that would not only not solve the problem (the
attacker would be getting both the session ID and the PDF token) but
would make the application vulnerable to session fixation.

2) There is also an issue of enabling session tracking on sites that
are not using it already. It can cause performance degradation before
state must now be persisted between requests and it affects the
cacheability of resources. In order to be implemented efficiently,
session-based PDF protection must be tightly integrated with the web
server but not all platforms have the luxury of Java Servlets where
the web server also knows about sessions. Such implementations would
have to pretty-much guess what constitutes a session, allowing more
room for problems.

3) You are not addressing the case when it is not possible to identify
a request for a PDF file because the file is being generated
dynamically and the extension is not part of the name. To do this you
would have to inspect the response headers and search for the
corresponding MIME type. If you do this then you'd have to either have
to accept the performance penalty of serving the PDF files twice
(because you will have to redirect the user to re-request the file
with the correct token) or serve the file as an attachment.

Same discussion applies to the case when a PDF file is generated in
response to a POST transaction. It is not possible to redirect such
requests as you would lose the parameters transported in the request
body. To solve this problem one would have to preserve the response in
a temporary file, redirect the user to a completely different URI, and
serve the response from the temporary file when the user comes back.
Icky, but possible.

To conclude, fixing the PDF XSS issue is a balance between ease of use
and effectiveness. I don't think there's a solution that fits all so
great care must be taken to explain each advantage and disadvantage
for the people to be able to make an informed decision.

Personally I still believe Amit's approach is better to use overall
(reasonably easy to deploy, provides reasonable security). The few
deployments that use client-side certificates might consider creating
PDF tokens using their client's identities, which are impossible to
fake and always available.

I do believe you are right to raise concerns and investigate other
avenues - I just think you need to provide more evidence to support
your case.


On 2/12/07, Cyrill Brunschwiler <cyrill.brunschwiler () csnc ch> wrote:
> #####################################################################
> #
> # Subject: Universal PDF XSS
> # Author: Cyrill Brunschwiler (cyrill.brunschwiler () csnc ch)
> # Date: Februar 9th, 2007
> #
> #####################################################################
>
> Dear reader
>
> Compass worked out an advanced technical paper which explains the
> recently identified Adobe Acrobat Plug-in vulnerability. The document
> highlights the numerous useless remediation trials. Furthermore, you
> will experience why even the Open Web Application Security Project
> (OWASP) proposed solution seldom meets the requested security
> requirements.
>
> The full featured report is prepared for download at...
> http://www.csnc.ch/ (Anti-PDF-XSS Actions 9. Februar 2007)
>
> Best regards
> Your Compass Security Team
>
>
> -------------------------------------------------------------------------
> Sponsored by: Watchfire
>
> Cross-Site Scripting (XSS) is one of the most common application-level
> attacks that hackers use to sneak into web applications today. This
> whitepaper will discuss how traditional XSS attacks are performed, how to
> secure your site against these attacks and check if your site is protected.
> Cross-Site Scripting Explained - Download this whitepaper today!
>
> https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008fHA
> --------------------------------------------------------------------------


--
Ivan Ristic

-------------------------------------------------------------------------
Sponsored by: Watchfire

As web applications become increasingly complex, tremendous amounts of 
sensitive data - personal, medical and financial - are exchanged, and 
stored. Consumers expect and demand security for this information. This 
whitepaper examines a few vulnerability detection methods - specifically 
comparing and contrasting manual penetration testing with automated 
scanning tools. Download "Automated Scanning or Manual Penetration 
Testing?" today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008fH6
--------------------------------------------------------------------------