Tags: security

127

sparkline

So We Got Tracked Anyway

Even using a strict cookie policy won’t help when Facebook and Google are using TLS to fingerprint users. Time to get more paranoid:

HTTPS session identifiers can be disabled in Mozilla products manually by setting ‘security.ssl.disablesessionidentifiers’ in about:config.

On HTTPS and Hard Questions - TimKadlec.com

A great post by Tim following on from the post by Eric I linked to last week.

Is a secure site you can’t access better than an insecure one you can?

He rightly points out that security without performance is exlusionary.

…we’ve made a move to increase the security of the web by doing everything we can to get everything running over HTTPS. It’s undeniably a vital move to make. However this combination—poor performance but good security—now ends up making the web inaccessible to many.

Security. Performance. Accessibility. All three matter.

Google AMP - A 70% drop in our conversion rate. - Rockstar Coders

Google hijacking and hosting your AMP pages (in order to pre-render them) is pretty terrible for user experience and security:

I’m trying to establish my company as a legitimate business that can be trusted by a stranger to build software for them. Having google.com reeks of a phishing scam or fly by night operation that couldn’t afford their own domain.

Securing Web Sites Made Them Less Accessible – Eric’s Archived Thoughts

This is a heartbreaking observation by Eric. He’s not anti-HTTPS by any stretch, but he is pointing out that caching servers become a thing of the past on a more secure web.

Can we do anything? For users of up-to-date browsers, yes: service workers create a “good” man in the middle that sidesteps the HTTPS problem, so far as I understand. So if you’re serving content over HTTPS, creating a service worker should be one of your top priorities right now, even if it’s just to do straightforward local caching and nothing fancier.

When 7 KB Equals 7 MB - Cloud Four

I remember Jason telling me about this weird service worker caching behaviour a little while back. This piece is a great bit of sleuthing in tracking down the root causes of this strange issue, followed up with a sensible solution.

BBC News on HTTPS – BBC Design + Engineering – Medium

BBC News has switched to HTTPS—hurrah!

Here, one of the engineers writes on Ev’s blog about the challenges involved. Personally, I think this is far more valuable and inspiring to read than the unempathetic posts claiming that switching to HTTPS is easy.

Update: Paul found the original URL for this …weird that they don’t link to it from the syndicated version.

I discovered a browser bug - JakeArchibald.com

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.)

The crooked timber of humanity | 1843

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.

Artificial Intelligence for more human interfaces | Christian Heilmann

An even-handed assessment of the benefits and dangers of machine learning.

Password Tips From a Pen Tester: Common Patterns Exposed

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…

CORS

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.

A cartoon intro to DNS over HTTPS – Mozilla Hacks – the Web developer blog

This is a great illustrated explanation of how DNS resolution works.

CSS Is So Overpowered It Can Deanonymize Facebook Users

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.”

Google and HTTP

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.

Third party CSS is not safe - JakeArchibald.com

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.

Let’s talk about usernames

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:

  1. System-level identifier, suitable for use as a target of foreign keys in our database
  2. Login identifier, suitable for use in performing a credential check
  3. Public identity, suitable for displaying to other users

Many systems ask the username to fulfill all three of these roles, which is probably wrong.

We need more phishing sites on HTTPS!

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.

Bad Month for the Main Thread - daverupert.com

JavaScript is CPU intensive and the CPU is the bottleneck for performance.

I’m on Team Dave.

But darn it all, I just want to build modular websites using HTML and a little bit of JavaScript.

I’m harvesting credit card numbers and passwords from your site. Here’s how.

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.

For users, the solution is to disable JavaScript.

(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.)