WEBVTT

00:00:02.040 --> 00:00:04.290
Although not really a header, I think to

00:00:04.290 --> 00:00:06.869
Subresource Integrity check is important

00:00:06.870 --> 00:00:10.045
to explain in this course. In a demo app,

00:00:10.045 --> 00:00:12.650
we now have this line in the layout page

00:00:13.040 --> 00:00:15.340
that downloads the Bootstrap CSS from a

00:00:15.340 --> 00:00:18.970
CDN. CDNs are great. We don't have to

00:00:18.970 --> 00:00:21.729
store the files ourselves anymore, and,

00:00:21.730 --> 00:00:24.390
more importantly, no need to do physical

00:00:24.390 --> 00:00:27.750
file updates anymore. Also, we don't get

00:00:27.750 --> 00:00:29.910
charged for the bandwidth it takes to

00:00:29.910 --> 00:00:32.930
download the files. On top of that, we get

00:00:32.930 --> 00:00:35.540
the benefit of the browser cache. The

00:00:35.540 --> 00:00:37.980
browser caches the files for each URL's

00:00:37.980 --> 00:00:40.849
accesses separately. So when we serve up

00:00:40.850 --> 00:00:43.850
the file in our app, it will be downloaded

00:00:43.850 --> 00:00:46.025
the first time the user accesses the site,

00:00:46.025 --> 00:00:48.820
but chances are that the user has already

00:00:48.820 --> 00:00:51.420
used the site that used the same Bootstrap

00:00:51.420 --> 00:00:54.610
CDN. In that case, it can just grab the

00:00:54.610 --> 00:00:58.430
file from cache. However, we explicitly

00:00:58.430 --> 00:01:01.050
trust the CDN to serve up the right file.

00:01:01.740 --> 00:01:04.300
What if a CDN is compromised by an

00:01:04.950 --> 00:01:08.110
attacker? That person could just swap the

00:01:08.110 --> 00:01:10.660
file on the CDN with something completely

00:01:10.660 --> 00:01:15.720
different, something malicious. With CSS,

00:01:15.750 --> 00:01:17.780
it will probably just have a weird effect

00:01:17.780 --> 00:01:19.750
on the layout of the pages of the site.

00:01:20.240 --> 00:01:22.880
But CDNs also serve JavaScript files,

00:01:23.040 --> 00:01:25.120
opening yet another possibility for

00:01:25.120 --> 00:01:27.957
cross‑site scripting. So, what to do? On

00:01:27.957 --> 00:01:31.830
most websites that describe the CDN, you

00:01:31.830 --> 00:01:34.370
can find a longer version of the link tag

00:01:34.380 --> 00:01:37.570
that includes an integrity attribute. The

00:01:37.570 --> 00:01:39.929
attribute's value starts with the name of

00:01:39.930 --> 00:01:44.450
a hashing algorithm, in this case, sha384.

00:01:45.090 --> 00:01:47.649
What follows is the hash of the file. A

00:01:48.520 --> 00:01:51.130
hash is a form of encryption. Once this

00:01:51.310 --> 00:01:53.309
kind of encryption has been done, there's

00:01:53.310 --> 00:01:57.390
no way to reverse or decrypt it. The hash

00:01:57.390 --> 00:02:00.880
you see here is base64 encoded. So the

00:02:00.880 --> 00:02:03.250
browser has a pre‑configured hash of the

00:02:03.250 --> 00:02:05.589
file in the integrity attribute of the

00:02:05.590 --> 00:02:08.799
link rel tag. When the file arrives at the

00:02:08.800 --> 00:02:11.780
browser, the browser will hash the content

00:02:11.920 --> 00:02:14.929
using the same algorithm and then compare

00:02:14.930 --> 00:02:17.369
the computed hash with the one supplied in

00:02:17.369 --> 00:02:20.260
the integrity attribute. If there's no

00:02:20.260 --> 00:02:23.450
match, it will just reject it. There's

00:02:23.450 --> 00:02:25.290
also the crossorigin attribute edition,

00:02:26.900 --> 00:02:29.320
which tells it to do the request without

00:02:29.320 --> 00:02:33.380
sending user credentials. We can quickly

00:02:33.380 --> 00:02:34.990
find out what happens when the hash

00:02:34.990 --> 00:02:36.960
doesn't match by changing the supplied

00:02:36.960 --> 00:02:39.760
hash and run the application. There's the

00:02:39.810 --> 00:02:42.329
weird layout again, and in the console is

00:02:42.330 --> 00:02:44.780
now an error that it couldn't verify the

00:02:44.780 --> 00:02:47.109
hash correctly, and the file has been

00:02:47.110 --> 00:02:50.350
blocked. If your CDN doesn't provide the

00:02:50.350 --> 00:02:52.760
hash, or if you're afraid the webpage

00:02:52.760 --> 00:02:55.040
where the hash is on is compromised, you

00:02:55.040 --> 00:02:57.570
can also calculate the hash yourself, for

00:02:57.570 --> 00:03:01.040
example, by using srihash.org. There's

00:03:01.040 --> 00:03:03.359
also the possibility to enforce

00:03:03.490 --> 00:03:05.990
Subresource Integrity on all external

00:03:05.990 --> 00:03:09.630
files by adding require‑sri for style to

00:03:09.630 --> 00:03:12.720
the Content‑Security‑Policy for CSS and

00:03:12.720 --> 00:03:16.680
script for JavaScript files. If you have

00:03:16.680 --> 00:03:19.240
this in your Content‑Security‑Policy, the

00:03:19.240 --> 00:03:21.880
browser won't load style or script files

00:03:21.880 --> 00:03:24.310
from an external source unless you have

00:03:24.310 --> 00:03:26.720
the Subresource Integrity check in place

00:03:26.720 --> 00:03:29.670
for them. In the next clip, I'll talk

00:03:29.670 --> 00:03:31.460
about creating privacy with the

00:03:31.460 --> 00:03:32.950
Referrer‑Policy header.
