WEBVTT

00:00:00.357 --> 00:00:01.888
What about the JavaScript attacks?

00:00:01.888 --> 00:00:03.715
How can you detect and defend against those?

00:00:03.716 --> 00:00:04.731
I know Troy and I,

00:00:04.731 --> 00:00:07.784
we looked at some of the ways of detecting and defending against them.

00:00:07.785 --> 00:00:09.631
Have you got any other tips?

00:00:09.632 --> 00:00:14.971
Customers can protect themselves if they want to get into some of the

00:00:14.971 --> 00:00:17.813
more sophisticated security policies of their browsers,

00:00:17.813 --> 00:00:20.901
but --- I'm shopping, right?

00:00:20.902 --> 00:00:22.683
I'm not, yeah, but as a merchant what do ______you do?

00:00:22.683 --> 00:00:23.720
______--- for a merchant,

00:00:23.720 --> 00:00:27.591
you have to be aware of the code that you're putting out there,

00:00:27.591 --> 00:00:29.725
and you need to go look at what the client is seeing versus

00:00:29.725 --> 00:00:31.670
what your server thinks it's putting out.

00:00:31.670 --> 00:00:33.722
And so that needs to monitored.

00:00:33.723 --> 00:00:41.200
You need to have your different antivirus software and things like that

00:00:41.200 --> 00:00:44.360
running that can often detect those type of things.

00:00:44.361 --> 00:00:46.581
And don't just run it on your server,

00:00:46.581 --> 00:00:50.633
but have a test procedure where you're running it as if you were the client.

00:00:50.633 --> 00:00:54.536
So see your web server as clients see your web server.

00:00:54.536 --> 00:00:56.687
I would absolutely, I mean,

00:00:56.687 --> 00:00:59.573
there are some scanning services that will do that for you and tell you,

00:00:59.573 --> 00:01:03.089
like in the cloud FIM services that I like to think them,

00:01:03.089 --> 00:01:06.355
that would actually pull your website every day and say,

00:01:06.355 --> 00:01:07.352
it changed, right?

00:01:07.352 --> 00:01:09.133
There's more JavaScript than there was yesterday.

00:01:09.133 --> 00:01:13.069
It might be okay, but it's like cloud FIM, effectively.

00:01:13.069 --> 00:01:15.882
Are you seeing clients taking advantage of Content Security

00:01:15.882 --> 00:01:18.407
Policy and Subresource Integrity yet?

00:01:18.408 --> 00:01:20.788
Not a whole lot.

00:01:20.788 --> 00:01:24.708
It does seem to be on their minds.

00:01:24.708 --> 00:01:32.032
People are starting to talk about it, but not a whole lot of adoption yet.

00:01:32.032 --> 00:01:34.412
Would you advise that the people learn how to do that today?

00:01:34.413 --> 00:01:35.046
Yes, absolutely.

00:01:35.046 --> 00:01:38.559
I mean, that's by big --- and there is a Pluralsight course on it,

00:01:38.559 --> 00:01:40.852
obviously, but like learn how to use CSP and SRI.

00:01:40.852 --> 00:01:44.180
Because the two attacks that happened last week,

00:01:44.180 --> 00:01:47.014
they used jQuery to get the data out.

00:01:47.015 --> 00:01:50.320
They used the XMLHttpRequest thing in jQuery,

00:01:50.320 --> 00:01:53.618
which I believe CSP would've stopped because it would be a

00:01:53.618 --> 00:01:56.676
nonapproved endpoint for that type of request.

00:01:56.676 --> 00:01:58.593
So you can, I mean the bad guys are doing well,

00:01:58.593 --> 00:02:01.672
but we can do stuff in e-comm to defeat them.

00:02:01.673 --> 00:02:02.407
Yeah.

00:02:02.407 --> 00:02:05.344
Again, it's move, countermove.

00:02:05.344 --> 00:02:08.277
It will be always move, countermove though, won't it?

00:02:08.277 --> 00:02:11.113
Yes, always.

00:02:11.113 --> 00:02:11.362
Okay,

00:02:11.362 --> 00:02:13.480
I think --- And you can't be lax on it because

00:02:13.480 --> 00:02:16.523
they're always going to be moving, so you have to be moving.

00:02:16.523 --> 00:02:18.694
And the standard doesn't move quickly enough.

00:02:18.694 --> 00:02:21.041
Because the standard moves on a much slower basis,

00:02:21.041 --> 00:02:24.241
so you can be very, you can be PCI DSS compliant,

00:02:24.241 --> 00:02:27.303
but still be subject to these attacks if --- Yeah.

00:02:27.303 --> 00:02:29.884
You have to look at PCI compliance as a floor.

00:02:29.884 --> 00:02:31.455
It's not the ceiling.

00:02:31.455 --> 00:02:34.919
It's a guideline to get you secure, but being secure is the goal,

00:02:34.919 --> 00:02:38.009
not just checking the boxes that, oh yeah,

00:02:38.009 --> 00:02:40.549
we met that requirement, and we met that requirement.

00:02:40.550 --> 00:02:43.152
You have to understand your environment and what

00:02:43.152 --> 00:02:45.646
security means in your environment.

00:02:45.646 --> 00:02:47.545
So I think we've wrapped e-comm attacks up there.

00:02:47.546 --> 00:02:48.746
I think we've looked at server side.

00:02:48.746 --> 00:02:50.648
We looked at client side.

00:02:50.648 --> 00:02:55.294
Client side, you've astounded me that that's now 80% of the work.

00:02:55.294 --> 00:02:58.214
There are defenses against it.

00:02:58.214 --> 00:03:02.835
But I think the two key learning points were if you use carts,

00:03:02.835 --> 00:03:05.734
patch them as quickly as possible.

00:03:05.734 --> 00:03:09.542
If you don't look at your website like your customers look at your website,

00:03:09.542 --> 00:03:14.193
you need to start doing that tomorrow.