[Autogenerated] one of the major changes to have happened to the
security of cardholder data since version three of Pc DSS was published
are skimming attacks against e commerce websites,
the ones which used JavaScript to harvest the cardholder data from a
payment page as the data is entered by the consumer.
And so there are now two new requirements designed to protect
against this attack and also to detect it.
If it occurs firstly,
a payment page has been more clearly defined in the glossary,
it now makes it clear that the payment page consists of the form elements
that capture account data and that these form elements might be presented as
a single page or as all the form elements in a single iFrame or the form
elements contained in multiple I frames.
What's important is that it clarifies the parent page hosting I
frames or an iFrame is not a payment page although there is a note
in the good practice section that recommends using a content
security policy in the parent page,
which can fix the location that I friends can be loaded from skimming attacks,
work by the attacker managing to have their own JavaScript executed on
the payment page and this can happen either by the attacker tampering
with the JavaScript served from the merchants.
website or JavaScript serve from any third party that's incorporated into
the payment page when it's rendered by the consumer.
browser Requirements 6.4.3 Firstly states that the only Javascript
that can be present in a payment page is Javascript that's wholly
necessary for the payment transaction.
So this excludes advertising tracking or other type
of user experience monitoring.
Javascript secondly,
all scripts present in the payment page must have been
authorized by management and finally that the integrity
of those scripts is validated.
The standard is technically neutral about how this
validity checking should happen,
but it helpfully provides some examples in the guidance column.
Ways of accomplishing this are typically using the content security
policy and sub resource integrity directors built into web protocols or
alternatively using commercial products such as those provided by content
distribution networks to verify the integrity of scripts as they're
served to the consumer Sitting alongside this requirement to ensure that
scripts are necessary,
authorized and validated is requirement 11.6.1 which aims to alert the
organization if scripts in the payment page or the content security
policy have been changed now because of the way that modern web pages
are assembled in the consumer browser,
it's not possible to just rely on final integrity monitoring on the merchant's
website and to detect changes in scripts because practically changes can only be
detected as the whole web page is rendered in the consumer's browser So
typically this will require an organization to use a content security policy and
then look for either violations of the content security policy or changes to the
CSP in the http header.
Alternatively,
you could employ commercial service which you might
hear called synthetic user monitoring,
which requests the payment page and then compares it with a
previously known good version of the payment page.
And together these two requirements would stop and detect the
majority of e commerce phishing attacks.
The final change to the standard that's designed to protect e commerce websites,
is that now a web application firewall or a UAF is required.
Previously,
version three of the standard allowed an entity to either use a web
application firewall or to do another set of code reviews.
Now all entities must use a web application firewall.
Remember all these new requirements are future dated
requirements and so only need to be in place for an
assessment on or after one April 2025.
However, if I was running an e commerce website today,
I would have all this protection in place now.