SEO

SharedArrayBuffer warnings in Search Console: Clarifying a new cross-origin isolation security policy

Web-facing pages are an information security battle zone as we fight hackers who try to steal company secrets. Modern webpages often leverage resources from more than one origin (domain). This often leads to vulnerabilities. As pressure mounts surrounding security concerns that affect new features, webmasters have a growing list of options from browser makers, including directives for handling “cross-origin” resources to help prevent information leaks.

Security measures

You may already be familiar with rel="noopener", a way to make sure a page’s hypertext links and form elements that have outbound actions, like links which open another site in a new browser tab, don’t allow Javascript access by an external page to an internal page via the Window.opener property. Imagine clicking a link that opens a new tab. When you close the new tab, the original page was secretly switched to one with phishing lures. The opener property enables attackers to change URLs of the original tab.

You might be thinking: “I would never link to a page that would that!” Here at SEL, we constantly link out to lots of pages and we don’t have the luxury of time to check source code. We use rel="noopener" so that we don’t have to. Browser makers give us sophisticated security options so we can lock things down in all sorts of ways in order to prevent us getting exposed to exactly such attacks.

You may have seen reference to the Cross-Origin-Resource-Sharing (CORS) http response header. This is technically more difficult to manage when you don’t have control over your web server. CORS (Access-Control-Allow-*) values will limit access to only a set of domains that you specify as a list. When your page includes analytics, advertisements, and other third-party script resources, those not specifically on an allow list (when you use CORS) get blocked and will trigger browser console error messages to let you know.

Spectre meltdown

When things just get too heated, it’s safer for browser makers to turn off a feature altogether. That’s exactly what’s happened a few years ago with SharedArrayBuffers when it was disabled by default 6-months after its debut and until a solution was prepared and agreed on by consensus recently. The problem was that a proof of concept post was published which demonstrated a “side-channel” vulnerability accessing shared memory, a more serious problem than URL switching.

In a nutshell, CPUs vulnerable to a timing flaw by virtue of Spectre allowed access to the memory cache where SharedArrayBuffers store information. This allows a malware page to access other pages not only those opened by following a link from one to the other, but any page that you have sitting open.

Imagine that you pin a personal banking page open with your account details. Separately browsing a page containing the exploit an attacker can retrieve everything the bank page contains. Information leaking from that sort of attack can constitute highly sensitive, personally identifying information that can expose one to identity theft, and potentially enable targeted attacks against organizations, including government systems.

Return of SharedArrayBuffers

Google’s Android Chrome 88 and desktop Chrome 91, plus Firefox 79+, all now implement SharedArrayBuffers again after a new security policy can mitigate danger from access to private memory. Any resource not specifically on your “allowed” list will get blocked. Since the feature was off by default, now that it is back on, JavaScript APIs that made use of it are starting to trigger blocking actions when they failed silently beforehand.

For example, WebGLRenderingContext implements the SharedArrayBuffers which failed silently during the blackout period. The security settings to accommodate it are new enough very few developers have heard of it. As reports of blocking actions pile up at google, the sudden appearance of notices in Google Search Console can catch us off guard.

Implementing the new security policy

Given the surprise, the time has never been better to undertake the best practice that establishes a security policy using CORS. as a perimeter around only those third-party resources which you intend to utilize. Without a security policy in place, third-party resources are cause for enough havoc already, let alone potentially leaking your secrets. You want to limit the allow-list using a “distrust by default” security policy methodology. To limit your risk, work intentionally from blocking all scripts to white-list as few as you can get away with.

The settings should be configured using your entry point page’s http response headers. When you manage your own web server, you can edit page headers using configuration settings in the framework or technology stack which powers your website. Alternatively, some Content Delivery Networks (CDNs) offer the ability to change response headers on-the-fly. Either way, it’s a matter of adding field names and values, one directive per line.

Cross-origin isolation

The security environment where you lock down access, while allowing the new implementation of SharedArrayBuffers, is called cross-origin isolation. To configure Cross-Origin Isolation, add two new page headers, COOP and COEP, as depicted below, which work in tandem with one or more other security headers, namely CORS and or CORP, which individually or in combination provide your white-listed cross-origin domains.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Google uses the open source Chrome reporting API to collect actions which take place against these security policies. When a significant number pile up, they might try and find a way to notify you such as appears to be the case when you are a Google Search Console user.

A Chrome specific Report-To page header field can be used to transmit data to your own repository, although it’s far easier to simply check the boolean state of the crossOriginIsolated property of the experimental WindowWorkerGlobalScope API during development. That way, you get to handle these issues directly from within your development workflow.

if(crossOriginIsolated) {   // Post SharedArrayBuffer   console.log("CrossOriginIsolation: true") } else {   // Do something else   console.log("CrossOriginIsolation: false") }

Why we care

Given that security policy best practice failures already trigger warnings in Lighthouse and error messages in browser consoles, and in this case the Google’s Search Console service, we need to understand the details in order to offer our advice for what to do. If we’re involved in web development, then we want to have specific information prepared so that we can guide or conduct the implementation of a fix as part of our job.

For more information like this, check out SMX’s SEO for Developers Workshop, intended to provide us a platform to discuss technical issues we face which can be unique to search engine optimization practitioners. In a live-code workshop environment, we often demonstrate what SEO savvy web developers do when facing these issues, and more. Information security is important, as evidenced by SharedArrayBuffers, cookie policy changes, and many more such matters are likely on the horizon.

About The Author

Detlef Johnson is the SEO for Developers Expert for Search Engine Land and SMX. He is also a member of the programming team for SMX events and writes the SEO for Developers series on Search Engine Land. Detlef is one of the original group of pioneering webmasters who established the professional SEO field more than 20 years ago. Since then he has worked for major search engine technology providers, managed programming and marketing teams for Chicago Tribune, and consulted for numerous entities including Fortune 500 companies. Detlef now works as a ninja for Internet Marketing Ninjas lending a strong understanding of Technical SEO and a passion for Web programming to company reports and special services.

Let’s block ads! (Why?)

Channel: SEO – Search Engine Land

Leave a Reply

Your email address will not be published. Required fields are marked *