And then the last stage is recovery.
Okay, so you've responded, you've recovered,
you've had a forensic investigator in maybe,
and believe me, that's no great fun.
You've worked out how to get rid of the JavaScript,
and now your job is to make sure it doesn't happen to you again.
So, is recovery sort of part of the response,
because when you said make sure it doesn't happen to you again,
we just spoke about identifying the vector by which it was included,
but you sort of,
I guess breaking this out into a separate phase here in
terms of patching the vulnerable framework,
for argument's sake.
Yeah, there's the first response, which is like,
okay, we've got a problem, let's stop the immediate problem,
and then there's the recovery, okay, now how do I get back to a known good state?
And if we think about, say, you've got malware on your machine,
how would you get to a known good state with malware?
I'd be nuking the machine.
Rebuilding it.
And that's your recovery phase.
On a web server, you probably are not going to be doing that,
it's probably unlikely you've got malware,
it's nowadays, because the great, if you're a criminal,
and terrible, if you're a merchant,
thing about these attacks is they're not noisy.
You know, we looked at, let's go right back to the beginning,
we talked about attacks where the criminal had to compromise the web server,
put their own code on it, put memory scraping malware on it,
write files to disk, that's a noisy, persistent attack.
This attack requires me to insert one line of JavaScript.
I might be able to do it through a content management system,
so my attack is quiet, and therefore,
that's why detection often doesn't work in the traditional sense.
Yeah, your antivirus isn't going to pick it up.
No.
And actually what I look like is I look like the person in the marketing
department who's just adding a line of JavaScript.
Which again makes me feel increasingly uncomfortable about the
marketing department being able to do that,
but that's probably another story.
I think we are where we are in the world,
I mean,
we can look at some websites and I can show you a website that's making
about 100 requests for third party bits of JavaScript.
I'll show you one newspaper website, it's a newspaper here in the UK,
and I'm just, rather than using dev tools,
because I'm not a dev tools sort of guy,
I'm using this really cool website that will actually just go
out and it'll do a footprint of this website.
And if you look, so this is the Manchester Evening News,
it's got 99 cookies set, it's got 213 third-party requests,
and 100 different third parties contacted,
and if I scroll, I'm going to scroll right down to the end --- And to be fair,
you've not picked this site because they do it particularly badly,
it's that this is reflective of many sites on the internet today.
Yeah, this is just like every newspaper web,
I could have picked any newspaper website or many big e-commerce websites that
are doing targeted advertising and tracking of customers.
And to put this back into context, your point here is that they,
I mean,
you're looking at cookies if you scroll down a little bit from
memory we had things like external script requests.
Yeah, so 213 requests to 100 unique hosts.
And if I scroll, I'm going to get to the, it's a long scroll.
But the point here as well is that if any of those external script requests had,
let's call it a BrowseAloud situation --- Correct.
--- we're back to the same problem.
Exactly back to the same problem.
But this also kind of demonstrates the point that it can be very,
very hard to lock this stuff down,
maybe less so with SRI because you do that at the point you read the script,
but it can be very,
very hard to lock that down with the CSP when you've
got so many things that are in there, and I imagine this is volatile,
too, insofar it's your point the marketing department is going to say,
look,
we need to add in another tracker or advertising network or whatever it may be.
It's even worse now,
that advertising will come to you and say put our tracking
JavaScript on it and we'll give you a $1.
00 a user or $2.
00 a user.
So it's an easy way of monetizing.
You say even worse because it's like there's a monetization angle too,
but it's still exactly the same risk.
It's exactly the same risk.
But, you know, commercially if someone is coming to you and they're saying,
I will give you this amount of money to include that
piece of JavaScript on your website,
that's compelling for the marketing department,
and if you're a newspaper and you're not getting the ad revenue you used to get,
you need a way of getting the revenue.
So again, I think, you know,
if we went back and --- Put a crypto-miner on the page ---
I wonder when that will become a thing.
You know, it is a thing,
like literally these crypto-miners position themselves as,
people don't like ads, instead of that put a crypto-miner on it,
because apparently people are okay with crypto-miners.
People are okay with crypto-miners.
That's great.
But you know, I think if we came back and looked at this in a year's time,
this would have changed,
and that's that whole thing about keeping the CSP up-to-date,
requires a processor,
requires you to decide to do that as a business rather than just some
person on technology's side and they're going to do it.
We've seen it keep sort of coming around on a full circle here where we go,
look at it's kind of hard to do things like the CSP because
there are so many external dependencies,
but by the same token, we're going, oh my gosh,
there's so many external dependencies,
look at all the risks that a typical website introduces.
Absolutely.
I just think, you know, we change the state of how people build websites.
When I built my first website, everything came from my web server.
Right.
I had complete control over everything.
Now, you've lost that, and the criminals know that.