All right, so this is the attack.
Where do we go from here?
We need to work out how to defend against it.
Okay.
So we're sort of into what we call the protect phase.
We know what the attack is.
How are we going to protect ourselves?
And I guess, you know, you hit it on the head to begin with,
don't let your web server get owned.
Yeah, okay, seems easy.
But I think that's just one stage of it.
Because, you know,
lots of web servers now are pulling libraries from all over the internet,
they're pulling resources from lots of places,
but get assembled in that consumer browser,
so that we've also seen supply chain attacks,
so where people have attacked a piece of JavaScript that's
been pulled in by lots of other websites.
Okay, so let me share something, because I want to give an example.
So, in February 2018 we had an incident,
we being the industry,
had an incident where there was a third party library called BrowseAloud,
helps for accessibility.
So this library was embedded just like this,
so that this looks a little bit similar to before
insofar as there was a script tag,
the source of this is loading content from an external source,
and in this particular case, this ba.
js file was maliciously modified.
And that ended up looking like this.
Now what we're actually looking at here is this is
embedding a script from Coinhive,
so it actually put a crypto-miner on every single page
that had the BrowseAloud plug-in, or rather had the browser had script,
that's kind of a plug-in, pulled into the browser.
Now I think the point that you are making,
you know, when I said don't get your web server owned,
it's like, good, don't get your web server owned,
but you're also saying, look,
there are times when we pull libraries off other locations
locations and your web server might not be owned,
but if someone else's web server gets owned,
this executes in the context of your browser,
and just as these guys put a crypto-miner in here,
they could just as easily have put the script that you just
showed to grab anything that gets entered into the form
fields and off async to the attack.
Absolutely.
And I know we're talking about card data security today,
but that's because that's sort of my pet interest,
right?
But that keylogger that reads the form data, that could be on a login page.
Right.
Or it could be on a health record.
It could be --- Harvesting credentials.
Harvesting medical records.
--- it could be harvesting anything you're asking a user to type in.
Sure.
It's a serious problem, and so that supply chain's really important.
We all saw a really clever attack whereby someone had mistyped the word Google,
so they were pulling in Google Analytics,
and they had mistyped the word Google in the URL,
so the criminal went and registered the mistype and
then put their own code in there.
Right.
And then you've got your own arbitrary code executing
the context of someone else's browser.
And I guess the problem is as well,
when we look at the way these things are embedded,
they are literally saying go and get that script from a third party,
bring it in, and whatever is in there just execute it.
Yeah, absolutely.