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 ...
Really?
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...
- 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.
- 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.
- 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.
- 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...
- 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
$app.AllowedInlineDownloadedMimeTypes.add("test/111")
$app.Update()
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.
-Maurice