Jake’s blow-by-blow account of uncovering a serious browser vulnerability is fascinating. But if you don’t care for the technical details, skip ahead to to how different browser makers handled the issue—it’s very enlightening. (And if you do care for the technical details, make sure you click on the link to the PDF version of this post.)
Tom Standage—author of the brilliant book The Victorian Internet—relates a tale of how the Chappe optical telegraph was hacked in 19th century France, thereby making it one of the earliest recorded instances of a cyber attack.
An even-handed assessment of the benefits and dangers of machine learning.
I’ve been wondering about this for quite a while: surely demanding specific patterns in a password (e.g. can’t be all lowercase, must include at least one number, etc.) makes it easier to crack them, right? I mean, you’re basically providing a ruleset for brute-forcing.
Turns out, yes. That’s exactly right.
When employees are faced with this requirement, they tend to:
- Choose a dictionary word or a name
- Make the first character uppercase
- Add a number at the end, and/or an exclamation point
If we know that is a common pattern, then we know where to start…
A thorough explanation of the history and inner workings of Cross-Origin Resource Sharing.
Like tales of a mythical sea beast, every developer has a story to tell about the day CORS seized upon one of their web requests, dragging it down into the inexorable depths, never to be seen again.
This is a great illustrated explanation of how DNS resolution works.
First of all, don’t panic—this browser vulnerability has been fixed, so the headline is completely out of proportion to the reality. But my goodness, this was a clever technique!
The technique relies on luring users to a malicious site where the attacker embeds iframes to other sites. In their example, the two embedded iframes for one of Facebook’s social widgets, but other sites are also susceptible to this issue.
The attack consists of overlaying a huge stack of DIV layers with different blend modes on top of the iframe. These layers are all 1x1 pixel-sized, meaning they cover just one pixel of the iframe.
Habalov and Weißer say that depending on the time needed to render the entire stack of DIVs, an attacker can determine the color of that pixel shown on the user’s screen.
The researchers say that by gradually moving this DIV “scan” stack across the iframe, “it is possible to determine the iframe’s content.”
I share many of these concerns.
The web is huge. Even bigger than Google. I love that the web preserves all the work. I don’t think anyone has the right to change the web so they no longer work.
We all know that adding a third-party script to your site is just asking for trouble. But Jake points out that adding a third-party anything to your site is a bad idea.
Trust no one.
This post goes into specifics on Django, but the broader points apply no matter what your tech stack. I’m relieved to find out that The Session is using the tripartite identity pattern (although Huffduffer, alas, isn’t):
What we really want in terms of identifying users is some combination of:
- System-level identifier, suitable for use as a target of foreign keys in our database
- Login identifier, suitable for use in performing a credential check
- Public identity, suitable for displaying to other users
Many systems ask the username to fulfill all three of these roles, which is probably wrong.
All the books, Montag.
If we want a 100% encrypted web then we need to encrypt all sites, despite whether or not you agree with what they do/say/sell/etc… 100% is 100% and it includes the ‘bad guys’ too.
I’m on Team Dave.
This is a “what if?” scenario, but it’s all too plausible.
For site owners, the (partial) solution is to have a strong Content Security Policy.
(In the wake of Spectre and Meltdown, this is now a perfectly legitimate action for security-conscious web users to take; I hope your site can support that.)
How a certificate with extended validation makes it easier to phish. But I think the title could be amended—here’s what’s really broken:
On Safari, the URL is completely hidden! This means the attacker does not even need to register a convincing phishing domain. They can register anything, and Safari will happily cover it with a nice green bar.
This article about a specific security flaw in voice-activated assistants raises a bigger issue:
User-friendliness is increasingly at odds with security.
This is something I’ve been thinking about for a while. “Don’t make me think” is a great mantra for user experience, but a terrible mantra for security.
Our web browsers easily and invisibly collect cookies, allowing marketers to follow us across the web. Our phones back up our photos and contacts to the cloud, tempting any focused hacker with a complete repository of our private lives. It’s as if every tacit deal we’ve made with easy-to-use technology has come with a hidden cost: our own personal vulnerability. This new voice command exploit is just the latest in a growing list of security holes caused by design, but it is, perhaps, the best example of Silicon Valley’s widespread disregard for security in the face of the new and shiny.
Hadley points to the serious security concerns with AMP:
Fundamentally, we think that it’s crucial to the web ecosystem for you to understand where content comes from and for the browser to protect you from harm. We are seriously concerned about publication strategies that undermine them.
The anchor element is designed to allow one website to refer visitors to content on another website, whilst retaining all the features of the web platform. We encourage distribution platforms to use this mechanism where appropriate. We encourage the loading of pages from original source origins, rather than re-hosted, non-canonical locations.
That last sentence there? That’s what I’m talking about!
Got questions about the security of service workers? This document probably has the answer.