X-Content-Type-Options + passive content?

The question of how X-Content-Type-Options: nosniff interacts with passive content came up today on Twitter. I had always assumed that browsers would block passive content where the MIME type was incorrect and nosniff was set, but I decided to test.

Below is a delightful image of a Snorlax. It's a PNG, but the extension is .jpg and nginx delivers its MIME type as image/jpeg:

Sleeping Snorlax
© Nintendo or The Pokémon Company or Something

Can you see this image? I sure can. If you're using Firefox, Chrome, Safari, Edge — really anything but Internet Explorer — it shows up just fine.

Here is the same image, but with no extension. By default, nginx sets its MIME type as application/octet-stream:

Sleeping Snorlax
© Same corporations or people. But I repeat myself, apparently.

Here, Firefox (50+), Edge, and Internet Explorer block it, but Chrome and Safari display it just fine.

How about audio? With HTML5 audio, you get to tell it exactly what the MIME type is! Here is an mp3 (audio/mpeg), but it has a .ogg (audio/ogg) extension and I've set the HTML5 audio type attribute to audio/mp4:

© Hiroyuki Masuno? Maybe?

IE11, Edge, and Safari fail due to MIME type confusion, but not because of X-Content-Type-Options. Firefox and Chrome? They play that sweet, sweet 1987 video game music just fine.

In conclusion, I should stop making assumptions about how browsers behave, particularly when it comes to quasi-standards like X-Content-Type-Options.

[Category: Security] [Permalink]


Offensive playmats in Magic

Last Saturday (May 14th), I participated in a panel at a local judge conference on the topic of women in Magic:

It was a ton of fun, and I'm always excited for an opportunity to collaborate alongside Morgan and the Magic the Amateuring cast. Unfortunately, it led to a huge uproar on Reddit, YouTube, and Twitter.

One topic in particular led to a much outrage, and that was on the subject of “offensive” playmats. I completely understand this: players invest a lot of time in choosing the perfect playmat that represents their hobbies and personalities. I know I've spent countless hours searching for the ideal image and ended up having to write a heartfelt email in Japanese to get the high-resolution version of the image that I use for my current playmat:

お世話になった方々, by ポージョンX
お世話になった方々, by ポージョンX

To that end, I wanted to help dispel some of the misconceptions around these playmats, at least from my experiences as a judge.

  • Who are you or anyone else to decide what is or is not offensive?

This is a completely fair question, and was certainly the most common and pointed of the questions I received. And it's totally justified: nobody wants to participate in a community where they are made to feel like they are being censored. And the line on what is or is not offensive is extremely hard to draw. For example, is this offensive?

This is a popular playmat that currently being sold, and is one that I have seen at a event that I've judged. While I don't find it personally offensive, it's exactly the sort of playmat that I feel doesn't belong at an event that is open to the public at large.

Of course, who am I to judge whether a playmat, card sleeve, or altered card belongs at an event or not? Well, it's part of the job. Judges have a document that outlines what behaviors do and don't constitute infractions. And while many rulings are very clear cut, e.g., drawing four cards off of Ancestral Recall, many infractions and situations require the judge to use their best judgment. For example, here is one of the criteria for Unsporting Conduct — Minor:

  • A player uses excessively vulgar and profane language.

As with playmats, what can be considered “vulgar” and “profane” varies extremely widely depending upon on the audience. There's no strict definition of what these terms mean, and so it is left up to judges to determine whether or not such language falls under that classification in that circumstance. Playmats are no different. Judges use their best judgment — based upon the event and audience — to determine whether a playmat should or should not be usable at an event. This happens regardless of whether the judge takes action under their own initiative, or whether they are approached by a player. And when it does occur, it almost always involves the agreement of multiple members of the judge staff.

  • Why are you and other judges constantly imposing your morality on Magic players?

We're not! I've been judging since Innistrad block, and have judged everything from prereleases to Grand Prix. In all those events over the last five years, I've only seen or heard of a player being asked to put away their playmat about a half dozen times — roughly once a year. Although I regularly see playmats that make me, personally, a bit uncomfortable, taking action requires something truly extraordinary.

And despite concerns that players will approach me complaining about playmats featuring art like this:

Bloodbraid Elf, by Steve Argyle
Bloodbraid Elf, by Steve Argyle

…it's just something that doesn't happen. And if it did, I would inform the player that the playmat is perfectly acceptable and while I empathize with their concerns, I'm not going to ask the player to put it away.

  • Why should players be punished for liking what they like?

First of all, it should be clear that requests that involving players putting away their playmat are not an infraction and are not accompanied by any sort of penalty. Instead, players are politely asked to put their playmat into their backpack, and are provided with an alternative playmat if they don't have one available. And in all those half-dozen experiences, I've never seen a player express any serious outrage; these requests have always been a complete non-event.

L3 judge Rob McKenzie recounted a conversation that he had with a player about his playmat:

Rob: Uh, could you please turn it [a playmat featuring a guy giving the opposing player the middle finger] over?
Player: Oh! Yeah! [turns playmat over] Why did I think this was okay, and why did you not catch this in the last six rounds?
Everyone: much laughter
  • Is this not a violation of a player's first amendment right to free speech?

Restrictions on free speech are about the government restricting the free speech of the public. It has absolutely nothing to do with what art a player is allowed to display at a private event on private property that is nevertheless open to the public. I and other judges take a player's right to self-expression extremely seriously, and attempt to tread very lightly when it comes to these requests.

Overall, I want to reiterate that these events are extremely rare and that judges and the community are extremely lenient and forgiving when it comes to a player's choice of playmats and sleeves. Asking a player to put away their favorite playmat is only done with extreme circumspection and typically involve the agreement of multiple members of the judge staff.

[Category: Magic] [Permalink]


Analysis of CSP in the Alexa Top 1M sites (April 2016)

I recently wrote about the state of security in the Alexa Top 1M sites, particularly the depressingly low utilization of the many security headers available to site developers. Today, I'm talking about Content Security Policy (CSP).

By whitelisting specific sources of content and by disabling the use of inline JavaScript, CSP can nearly eliminate the class of attacks known as cross-site scripting (XSS) attacks. So how common is its usage amongst the Internet's most popular websites? Let's take a look:

Result Count Percentage
CSP implemented without using 'unsafe-inline' or 'unsafe-eval' 45 .0047%
CSP implemented the same as above, but with default-src 'none' 8 .0008%
CSP header allows style-src 'unsafe-inline' 61 .0064%
CSP header allows script-src 'unsafe-eval' 68 .0071%
CSP header uses http: source on an https site 15 .0016%
CSP header invalid 27 .0028%
CSP header allows script-src 'unsafe-inline' 3392 .3540%
No CSP header 954791 99.62%
Total number of successfully completed scans 958407  

Yes, that's correct: only about .37% of the top million sites use CSP at all, and of that tiny percentage, only 3.3% (.012% overall) have strong CSP policies that block the use of inline JavaScript. For a specification that has had wide browser support for over two years, that's almost embarrassingly low. I'm not sure if it's because the CSP specification is too complicated to understand or too complicated to implement, but web security professionals are failing here.

Of that meager .37%, what CSP directives are seeing use?

Directive Count Percentage
script-src 2500 69.66%
style-src 2016 56.17%
default-src 1913 53.30%
img-src 1555 43.33%
frame-src 1344 37.45%
font-src 1317 36.70%
connect-src 1203 33.52%
report-uri 1037 28.89%
object-src 980 27.31%
frame-ancestors 916 25.52%
media-src 912 25.41%
child-src 126 3.51%
form-action 70 1.95%
reflected-xss 39 1.09%
referrer 33 0.92%
base-uri 22 0.61%
sandbox 15 0.42%
plugin-types 4 0.11%
manifest-src 1 0.03%
block-all-mixed-content 0 0.00%
upgrade-insecure-requests 0 0.00%

It's interesting to note how common frame-src, referrer, and reflected-xss are, considering they have been deprecated since CSP1. I myself struggled with removing frame-src, simply because child-src is not yet supported everywhere.

Although the HTTP Observatory doesn't currently try to catch errors in CSP policies, they are quite common. In my investigations, I discovered that over 3% of CSP policies contained errors. Here are some of the more common errors I discovered:

Content-Security-Policy: *
Content-Security-Policy: 'self'
Content-Security-Policy: allow https://example.com ...
Content-Security-Policy: "default-src https://example.com ..."

I have no idea how the browsers interpret these errors, but it's almost certainly not what the site operator intended. Whoops! The upcoming version of the HTTP Observatory should report on these types of errors so that site operators can be certain that browsers aren't misinterpreting their intentions.

[Category: Security] [Permalink]


Analysis of the Alexa Top 1M sites (April 2016)

One of unsung heroes out there when it comes to advancing the overall security of the Internet is Scott Helme. In addition to report-uri.io (a CSP/HPKP violation reporting service), he runs securityheaders.io, a site that helps show you if you're utilizing the many available options when it comes to securing your web site.

It was the latter that inspired the creation of the Mozilla HTTP Observatory, a public service that goes a bit deeper and tells you not just whether you are using these headers, but if you're using them correctly and securely.

Having recently gotten the HTTP Observatory to a usable state, I decided to scan the Alexa Top 1M sites to see how well that engineers and developers on the biggest sites on the Internet are doing. As Scott found out, the results are pretty dismal. I'll be doing more detailed posts on each of these sections as I find the time, but even the basic statistics are depressing.

Content Security Policy (CSP) .005%1 / .012%2
Cookies3 1.88%
Cross-origin Resource Sharing (CORS)4 93.78%
HTTPS 29.64%
HTTP → HTTPS Redirection 5.06%5 / 8.91%6
Public Key Pinning (HPKP) 0.43%
  — HPKP Preloaded7 .414%
Strict Transport Security (HSTS)8 1.75%
  — HSTS Preloaded7 .158%
Subresource Integrity (SRI) 0.015%9
X-Content-Type-Options (XCTO) 6.19%
X-Frame-Options (XFO)10 6.83%
X-XSS-Protection (XXSSP)11 5.03%

Because these tests are a lot more strict than on securityheaders.io, the overall grade distribution is much lower:

Grade HTTP Observatory securityheaders.io
A+ .003% .020%
A .006% .072%
B .202% 2.38%
C .321% .029%
D .999% 3.16%
E .870% 6.10%
F 97.60% 88.20%

And just who are the .003% that managed to land an A+ grade with a score of 100 or greater on the HTTP Observatory?

Notes:

  1. Allows 'unsafe-inline' in neither script-src nor style-src
  2. Allows 'unsafe-inline' in style-src only
  3. Amongst sites that set cookies
  4. Disallows foreign origins from reading the domain's contents within user's context
  5. Redirects from HTTP to HTTPS on the same domain, which allows HSTS to be set
  6. Redirects from HTTP to HTTPS, regardless of the final domain
  7. As listed in the Chromium preload list
  8. max-age set to at least six months
  9. Percentage is of sites that load scripts from a foreign origin
  10. CSP frame-ancestors directive is allowed in lieu of an XFO header
  11. Strong CSP policy forbidding 'unsafe-inline' is allowed in lieu of an XXSSP header

If you're in a hurry and want to start digging into my data before I can, feel free to grab the data dump and have at it.

[Category: Security] [Permalink]