What about the JavaScript attacks?
How can you detect and defend against those?
I know Troy and I,
we looked at some of the ways of detecting and defending against them.
Have you got any other tips?
Customers can protect themselves if they want to get into some of the
more sophisticated security policies of their browsers,
but --- I'm shopping, right?
I'm not, yeah, but as a merchant what do ______you do?
______--- for a merchant,
you have to be aware of the code that you're putting out there,
and you need to go look at what the client is seeing versus
what your server thinks it's putting out.
And so that needs to monitored.
You need to have your different antivirus software and things like that
running that can often detect those type of things.
And don't just run it on your server,
but have a test procedure where you're running it as if you were the client.
So see your web server as clients see your web server.
I would absolutely, I mean,
there are some scanning services that will do that for you and tell you,
like in the cloud FIM services that I like to think them,
that would actually pull your website every day and say,
it changed, right?
There's more JavaScript than there was yesterday.
It might be okay, but it's like cloud FIM, effectively.
Are you seeing clients taking advantage of Content Security
Policy and Subresource Integrity yet?
Not a whole lot.
It does seem to be on their minds.
People are starting to talk about it, but not a whole lot of adoption yet.
Would you advise that the people learn how to do that today?
Yes, absolutely.
I mean, that's by big --- and there is a Pluralsight course on it,
obviously, but like learn how to use CSP and SRI.
Because the two attacks that happened last week,
they used jQuery to get the data out.
They used the XMLHttpRequest thing in jQuery,
which I believe CSP would've stopped because it would be a
nonapproved endpoint for that type of request.
So you can, I mean the bad guys are doing well,
but we can do stuff in e-comm to defeat them.
Yeah.
Again, it's move, countermove.
It will be always move, countermove though, won't it?
Yes, always.
Okay,
I think --- And you can't be lax on it because
they're always going to be moving, so you have to be moving.
And the standard doesn't move quickly enough.
Because the standard moves on a much slower basis,
so you can be very, you can be PCI DSS compliant,
but still be subject to these attacks if --- Yeah.
You have to look at PCI compliance as a floor.
It's not the ceiling.
It's a guideline to get you secure, but being secure is the goal,
not just checking the boxes that, oh yeah,
we met that requirement, and we met that requirement.
You have to understand your environment and what
security means in your environment.
So I think we've wrapped e-comm attacks up there.
I think we've looked at server side.
We looked at client side.
Client side, you've astounded me that that's now 80% of the work.
There are defenses against it.
But I think the two key learning points were if you use carts,
patch them as quickly as possible.
If you don't look at your website like your customers look at your website,
you need to start doing that tomorrow.