CODEWITHSUNDEEP
htmlgoogle-chromepdfiframe
kklepper
kklepper

Reputation: 813

Unexpected blocked page when called from link in iframe to PDF file with chrome based browsers

I have a webpage in an iframe which contains a link to a foreign page with attributes target="_blank" rel="noopener". This link works well from the page itself and also from the iframe but only when called via context menu with the option open in new tab. A regular click opens a new tab and shows the correct URL but results in This page has been blocked by Opera ERR_BLOCKED_BY_CLIENT.

I looked around for help, disabled all addons to no avail and played the scenario in incognito mode as well, no change. The console on the error page shows VM589:1460 crbug/1173575, non-JS module files deprecated. This hint left me in the dark, however. I manipulated the attributes to target="_blank" rel="noopener" rel="noreferrer" or rel="noopener noreferrer" with no success. This all applies to Opera.

I tried Brave with the same result and error message, except Brave instead of Opera, of course. Edge joins the failure band. No surprise then to see This page has been blocked by Chrome proper as well.

This error applies to all PDF-file links from the iframe, normal external links work well. Firefox shows briefly PDF.js viewer in the new tab and then works normal. I had no chance to try links to YouTube or the like, but I guess there is ample evidence I hit a bug in the chrome PDF-rendering engine.

What to do? Who is interested in this bug and how to reach them? Or is there anything I can do in my code?

Upvotes: 6

Views: 16797

Answers (2)

jeremy vanlanda
jeremy vanlanda

Reputation: 21

I set super lax Content Security Policies in my website and in my Nginx server block and the embedded PDFs were still getting blocked - but only on certain computers.

It turns out Google Workspace managed browsers have a setting on them by default to block iframe navigation. The setting is here, in case it helps someone:

  1. Login to https://admin.google.com/
  2. Navigate to Devices>Chrome>Settings>Users & Browsers
  3. In the "Content" Section, look for "iframe navigation" and set it to "Allow navigation to external protocols inside a sandboxed iframe"

Upvotes: 2

David
David

Reputation: 6084

Browser use already longer time the Content Security Policy (CSP) to protect users from undesired content. The definition of undesired content can be made by the site owner. if the site owner hasn't done that, then some standard values are used, which are more restrictive.

The website https://content-security-policy.com/ explains it like this

What is Content-Security-Policy? Content-Security-Policy is the name of a HTTP response header that modern browsers use to enhance the security of the document (or web page). The Content-Security-Policy header allows you to restrict how resources such as JavaScript, CSS, or pretty much anything that the browser loads.

Although it is primarily used as a HTTP response header, you can also apply it via a meta tag.

The term Content Security Policy is often abbreviated as CSP.

What types of attacks does Content-Security-Policy help mitigate? CSP was first designed to reduce the attack surface of Cross Site Scripting (XSS) attacks, later versions of the spec also protect against other forms of attack such as Click Jacking.

In your case you have to configure two hurdles for the user:

  1. The iframe, required rule: frame-src 'self'
  2. The PDF, required rule: object-src 'self' blob;

Essentially it's relatively safe to allow most things with 'self' but it's always good to disallow elements that are not used at all on the site.
Your Content Security Policy should look similar to this, and should allow PDFs in iframes:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'self' blob:; style-src 'self'; frame-src 'self';

The best is to configure the CSP in the server configuration. This is not possible for every site owner though, and it's possible to configure the CSP in meta tags too. You could add this to your site inside the head-tag:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'self' blob:; style-src 'self'; frame-src 'self'">

Setting the CSP in the server configuration is the stronger approach though:
https://content-security-policy.com/examples/meta/

Here are more examples, including CSP related server configuration for Apache Web Server and Nginx Webserver:
https://content-security-policy.com/examples/

EDIT

If the PDF is hosted on another domain, then the CSP has to adjusted differently, more openly. Different options for sources are explained here:
https://content-security-policy.com/#source_list

  1. The iframe, required rule has to be adjusted. It should be restricted either to a special domain with *.example.com or to a nonce with 'nonce-rAnd0m'.
  2. The PDF, required rule has to be adjusted, the same advise like for point 1. is applying.

So even the PDF is external then, it doesn't mean that everything could be injected somehow in the website.

Assumed you use the option with the domain *.example.com it would look like or similar to this then:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src '*.example.com' blob:; style-src 'self'; frame-src '*.example.com'

Assumed you use the option with the nonce it would look like or similar to this then:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'nonce-rAnd0m' blob:; style-src 'self'; frame-src 'nonce-rAnd0m'

I didn't test it, so slight adjustments might be required.

Upvotes: 1

Related Questions