Problem/Motivation

As we know this theme uses CDNs and does not host its bootstap files locally. That way code could be injected into every bootstap theme if someone is able to add malicious code to the CDNs.

Proposed resolution

To protect against such attacks the integrety and crossorigin need to be specified. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

<script src="https://example.com/example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Comments

hass created an issue. See original summary.

hass’s picture

Issue summary: View changes
markhalliwell’s picture

Status: Active » Closed (won't fix)
Issue tags: -Security, -Needs backport to D7
hass’s picture

Status: Closed (won't fix) » Active
Issue tags: +Security improvements, +Needs backport to D7
Related issues: +#1664602: Allow attributes to be passed to drupal_add_[css|js] (SRI)

Why was this case closed? These is a serious security issue if a theme uses CDNs. Arbitrary code could be injected in every website if the CDN account may has been hacked.

Bootstrap 4 implements it by default, see https://v4-alpha.getbootstrap.com/getting-started/download/.

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.6/css/bootstrap.min.css" integrity="sha384-rwoIResjU2yc3z8GV/NPeZWAv56rSmLldC3R/AZzGRnGxQQKnKkoFVhFQhNUwEyJ" crossorigin="anonymous">
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.6/js/bootstrap.min.js" integrity="sha384-vBWWzlZJ8ea9aCX4pEW3rVHjgjt7zpkNpZk+02D9phzyeVkE+jo0ieGizqPLForn" crossorigin="anonymous"></script>

For D7 we need to wait for #1664602: Allow attributes to be passed to drupal_add_[css|js] (SRI), but it does not mean this will not be available in core. In D8 it can already be implemented. If you do not like to do it in D8.3, move it to D8.4, but do not close such a serious security problem, please.

hass’s picture

Also for 3.x the same, see https://getbootstrap.com/getting-started/

<!-- Latest compiled and minified CSS -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">

<!-- Optional theme -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css" integrity="sha384-rHyoN1iRsVXV4nD0JutlnGaslCJuC7uwjduW9SVrLvRYooPp2bWYgmgJQIXwl/Sp" crossorigin="anonymous">

<!-- Latest compiled and minified JavaScript -->
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
markhalliwell’s picture

Status: Active » Postponed
Related issues: +#2657138: Refactor providers to utilize new data.jsdelivr.com API

Why was this case closed?

Because the API that's queried doesn't provide them: https://api.jsdelivr.com/v1/bootstrap/libraries

I just opened up a ticket: https://github.com/jsdelivr/api/issues/137

But I'm not 100% sure that issue will even go anywhere.

We could, in theory, generate our own SRI based on the contents of the remote file provided by the API...

From https://tenzer.dk/generating-subresource-integrity-checksums/:

function checksum($input) {
    $hash = hash('sha256', $input, true);
    $hash_base64 = base64_encode($hash);
    return "sha256-$hash_base64";
}

But that would mean that this is still postponed, at the very least, on #2657138: Refactor providers to utilize new data.jsdelivr.com API.

markhalliwell’s picture

This has now been, technically, implemented in #3031415-26: Overhaul CDN Providers API (now that it's using jsDelivr's new API endpoint).

There is a core bug that prevents the CSS from displaying SRIs though: #2716115: Allow attributes passed with CSS in libraries (SRI).

However, using AdvAgg would likely, temporarily, fix this.

Given how complex the CDN Providers are and the amount of time it would require to achieve the same functionality/quality of code, this isn't going to be backported to 7.x-3.x (especially considering it only has < 2 years left).

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.