Bluedog Limited > SharePoint Thoughts > Posts > Pretty Dangerous Files - why enabling in-browser viewing of PDFs is risky
February 22
Pretty Dangerous Files - why enabling in-browser viewing of PDFs is risky
Back in January, I was on a Delta flight somewhere ... can't remember where because my flights just tend to blend together at some point...  anyways, I picked up the Delta magazine and noticed a little article that talked about the new meaning of PDF - pretty dangerous files.
It was a quick read that basically said that attackers are really starting to push into the pdf space b/c it's fairly easy to get code to run within the context of the pdf file.
I started grinning...  why?
For a long time, I've been telling folks there is a reason PDFs are no longer allowed to be viewed in-browser in SharePoint 2010. 
The reason is fairly simple - the client object model.
This little article was a nice reminder that SharePoint had 3 major changes to reduce the cross-site scripting surface.  The change in rendering behavior of PDFs (and other files types) was intentional (and basically #1 of 3 changes).  The client object model changed our world ...
Well, the client object model is pretty powerful.  There are a lot of things you can do with just a small bit of javascript. The client object can delete/add/modify a wide variety of things within your SharePoint site. Every SharePoint site uses the client object model.
Now add in the fact that you can embed javascript into a PDF document. 
What does that give you?  A cross-site scripting attack window of opportunity.
Now, I challenge you to do a quick search on open, pdf, and SharePoint 2010.  More than likely you will find a whole litany of links that basically fit into the following buckets:
  • SharePoint is broken because PDFs have to be downloaded, rather than viewed in-line
  • The way to fix the problem is to basically open up your web applications to a whole new set of attack surfaces by removing a security safeguard.

Let's dissect those buckets...

  1. SharePoint is not broken.  It's by design that the SharePoint team has disabled PDF in-browser rendering.  Cross-site scripting is a big nasty problem.  This is a safe default.

    The reason downloading a PDF is safer than viewing the file in-browser/inline is because once you download a file, you are no longer associated with the browser session.  In other words, the cross-site scripting opportunity is removed.  Your downloaded PDF can't/won't operate under the authenticated context of your browser session.

  2. All of the articles that claim to fix the problem by setting the Browser File Handling property on a web application to Permissive are just wrong. 

    Yes, it's a way to "fix" the problem but it's the wrong way

What is the right way to deal with PDFs (or any other file type)?

  • Understand the fundamentals of cross-site scripting first.  If you don't, stop.  Leave the defaults as-is. 

    The last thing you want to do is enable in-browser viewing of Pretty Dangerous Files and then get the report that someone stole/deleted/hijacked data because someone posted a malicious PDF on your site.

  • If you understand cross-site scripting, then evaluate who is allowed to contribute content to the sites within the web application.
  1. It is entirely possible that you may have some sites where enabling in-browser viewing of PDFs is safe because you have a small number of trusted authors.
  2. It is also entirely possible that you evaluate your user base and simply decide that you can't trust the users to not author safe PDFs.  This is very much along the same lines as "do you want everyone to write and upload code?" - well, if you don't let everyone install Features and Solution Packages...
  3. Since this is a web application setting, it's ok to have mixed environments. For example, I've worked with many companies where the company portal web application (with 4-5 authors, everyone else read only) allows PDFs, but all other web apps remain with the safe defaults. 

This is really nothing more than a classic risk assessment exercise.  Are you willing to move away from a safe default?

Finally, if you are willing to accept the risk, do not set Brower File Handling to Permissive.  This is a big hammer that opens up cross-site scripting problems for a wide variety of file types, not just PDFs. 

What you need to do is *selectively* allow PDFs by setting specifying the right MIME type (and leaving Browser File Handling set to Restrictive).  This can be done via the OM... and hence via PowerShell.

The PowerShell commands to do this is fairly straightforward:

$app = Get-SPWebApplication http://myWebApp

You’ll need to replace “test/111” with the appropriate mime type for the file you would like to enable.  Likewise, you can remove items from the list by using the Remove command.

In closing... be safe.  I always tell my clients and students that the first answer to requests to "turn on" PDFs should be No.  Admins have a safe default that is designed to protect users - so use that argument as your first response.  Then go back and *evaluate* whether or not it makes sense to allow inline viewing of PDFs (and other files) within your environment, but no matter what you do, don't just willy-nilly use Permissive. 




This is a very interesting article, Maurice, and it is good to find an alternative solution to the PDF problem; setting the Browser File Handling to permissive - which 99% of solutions suggest - has not sat well with me, I have to admit.

Where the quandary arises however is that when users are having to download PDFs all the time, they ask what is the point of putting them on Sharepoint at all if they have to download them to read them?  And they have a point.

I guess the only problem I have with your solution is that I work for a scientific research company which uses some pretty obscure file types, and finding the MIME types for them is not quite such a simple task.

Overall, thank you for such a clear and concise argument, your warnings will be well heeded.

 on 8/17/2011 2:59 AM

Re: Pretty Dangerous Files - why enabling in-browser viewing of PDFs is risky


Don't forget that this is a per web app setting. 

If your system has multiple web apps setup, then you can pick and choose how you want to appropriate download rights.  For example, in a web app that is deemed secure with trusted authors, you may want to allow downloads.  In other web apps that are a little more "loosey goosey" with less trusted authors, a tighter reign is probably needed.

Also, something worth throwing out... use SharePoint Workspace to connect to your sites.  Then you can easily use SPW to view your PDFs locally w/o having to force users through the download process. I do this on practically all sites where I am expected to review/edit PDFs. Super easy.

Maurice PratherNo presence information on 8/17/2011 8:16 AM

Re: Pretty Dangerous Files - why enabling in-browser viewing of PDFs is risky

Thanks for a great article Maurice.  Was very informative.  Helps me to understand the risk.

We recently migrated from SharePoint 2007 to SharePoint 2010 SP1.  This "Browser File Handling" property came as a surprise to our user community.  And many feel it as an hamper.  It hits the usability.  But after going through this article, the design is justified.
A question though, if Java Script can be embeded in a PDF document, so does macros in MS Office files.  Any idea how does SharePoint 2010 protects itself from this ?

- Yash

 on 10/13/2011 10:27 AM

Re: Pretty Dangerous Files - why enabling in-browser viewing of PDFs is risky


Macros were never designed to run in the context of the browser.  Additionally, Word has safeguards that the user must accept in order to run macros once the file has been downloaded and opened from the client.

Maurice PratherNo presence information on 10/17/2011 6:33 PM


We were having issues with a third party jQuery plugin called DataTables.  This plug-in had an swf that didn't seem to be working.  I remembered this blog posting from the class you taught in Houston... and it saved the day...

 on 10/18/2011 6:27 PM

Blog Rendering

btw... maybe it's just my multiple machines...but are you aware your blog postings only work correctly on IE?  If I view them in Safari or Firefox... the scroll bar on the right never appears.. so it's very difficult to view your posts.

 on 10/18/2011 7:01 PM

Re: Pretty Dangerous Files - why enabling in-browser viewing of PDFs is risky

Thanks for clarifying, Maurice.
 on 10/19/2011 6:42 AM

PDF Safety (use protection)

We came across this issue when we recenly migrated a Web App that wsa still being hosted in 2007 and moved to SP2010 and found several articles detailing how to make PDF's available to open in Cental Administration and also in PowerShell, both worked in our test environments just fine.

As I discussed my findings with fellow Web Admin on site, we were really curious why SP2010 was blocking this, so we did some research and this is one of the articles I found and it confirms our paranoia.

Now, I am curious what procedure would be advised for making this available to our customers but doing so securely; Would we need added malware/antivirus protection or is there not a known secure way to do this yet?

SharePoint Admin
 on 1/25/2012 12:31 PM

Re: Pretty Dangerous Files - why enabling in-browser viewing of PDFs is risky

Unfortunately, there is no easy fix.  AV won't help.  The only true fix is to remove javascript.  Otherwise, you need to trust your authors.  It all depends on your intended use, in a company new portal, Trusted Authors are trained and most likely held accountable for what they publish.  In a more loosely structured collaboration site, then you probably don't have any concept of a trusted, trained, accountable author. In that case, separation of web applications help.  Make the portal web app work with your target mime types, and leave other web apps locked down.
Maurice PratherNo presence information on 2/16/2012 4:30 PM

© 2004-2013 Okean Solutions
Aptillon, Inc.
Microsoft Certified Master - SharePoint 2010 & 2007
Sign In