25

A sibling department has created an HTML file that is effectively a scaffold for a handful of iframes. The iframes each call a report, which is hosted on a web server, with slightly different parameters. The called report will show a sign-on form to unauthenticated users, or the report contents to already-authenticated users.

scaffold.html:

<html>
   <head>
      <title>I just show the output from a bunch of report calls</title>
   </head>
   <body>
      <iframe src="https://somesite.com/useful_report.html?parameter1=a&parameter2=1" id="iframe1"></iframe>
      <iframe src="https://somesite.com/useful_report.html?parameter1=b&parameter2=2" id="iframe2"></iframe>
      <iframe src="https://somesite.com/useful_report.html?parameter1=c&parameter2=3" id="iframe3"></iframe>
      <iframe src="https://somesite.com/useful_report.html?parameter1=d&parameter2=4" id="iframe4"></iframe>
   </body>
</html>

The sibling organization explained to us that if a user was signed on to https://somesite.com, the above setup worked great--each of the iframes would display the useful_report.html content...until a few days ago.

When I

  1. sign on to https://somesite.com, then
  2. load file:///C:/Users/me/Desktop/scaffold.html into Chrome

each of the iframes returns the https://somesite.com sign on form. If I then open useful_report.html in a separate tab, the report content loads (proving somesite.com knows I am still signed on‡).

Using developer tools, I can see that the request headers to useful_report.html do not include the "Cookie:" attribute, so this explains why useful_report.html returns the sign on form.

My question is why are the iframe requests not sending cookies? What Chrome and/or server setting/policy/directive prevents it?

‡ - and now it knows that I know that it knows.

Jeromy French
  • 11,812
  • 19
  • 76
  • 129
  • Is `somesite.com` setting `SameSite` in its cookie? https://www.chromestatus.com/feature/4672634709082112 – cody Dec 18 '18 at 22:38
  • @cody I am looking at the cookie, but I don't see any attributes by that name (or similar). Is the `SameSite` attribute something I would be able to see in Developer Tools? – Jeromy French Dec 18 '18 at 22:43
  • yeah, you would see it as a name/value pair in the cookie in developer tools, like session id or anything else.. scratch that off the list I guess – cody Dec 18 '18 at 22:46
  • Can you quickly fire up a local http server, serve the file with the iframes via that, and see if it makes a difference? – cody Dec 18 '18 at 23:13
  • @cody Yes, it does make a difference; when hosted on somesite.com, scaffold.html iframes load the report content (the request headers include the cookie). – Jeromy French Dec 20 '18 at 15:08
  • HI @JeromyFrench do not think this has anything to do with `content-security-policy`. Any reason why you have added `content-security-policy` tag? Do you have `csp` in place? if yes, does it works without it? – Ankit Vijay Dec 29 '18 at 21:42
  • @AnkitVijay I suspect a content-security-policy setting is at play here (based on something I read while researching this before posting my question), but I'm reaching. I don't know enough about the subject--how CSP works--to rule it out. – Jeromy French Jan 02 '19 at 18:11

1 Answers1

12

That's because of the SameSite cookie policy that Chrome defaults to Lax, meaning the cookies won't be sent unless the user can see the URL which excludes iframes.

If you own the somesite.com you can opt-out of this policy by setting SameSite policy to None and deal with the risk of CSRF attacks by Double Submit Cookie.

Arash.m.h
  • 320
  • 2
  • 11