Consequences for PCI DSS

[mozfreddyb]

PCI DSS appears to mandate that websites ensure the integrity of their scripts, which works well with existing SRI.

We were wondering if a signature would fulfill this requirement, given that it provide provenance much more than content integrity (cf. #52).

Filing this as a separate issue from #52, to discuss typical interpretation of PCI DSS in particular.

[mikewest]

I've been told that the signed resource is enough, but IANAL. I'll defer to folks like @yoavweiss and @ScottHelme who are more familiar with those requirements than I.

[swijckmans]

PCI SSC APO here too and also member of w3c.
We contribute to the PCI community meetings in AMER, EMEA and APAC. We speak to a lot of the assessors.
The PCI DSS requirements are attached.
There are 2 that relate to this discussion. 6.4.3 and 11.6.1

6.4.3 relates to a few points:

• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script

=> its unclear if this means blocking unauthorized scripts and PCI SSC is not willing to take a stance on it. The spec ALSO says "Unauthorized code cannot be executed in the payment page as it is rendered in the consumer’s browser." which sounds like a conclusive answer but... PCI SSC is not taking a stance, 'ask your QSA'. So many vendors are selling static scanners.

• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.

11.6.1
A change- and tamper-detection mechanism is deployed as follows:

• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
• The mechanism is configured to evaluate the received HTTP headers and payment pages.
• The mechanism functions are performed as follows: At least weekly, or specified timeframe...

TLDR: check all security headers AND script contents, detect changes and report on them weekly.

This is a poorly written spec that is very open to interpretation and the people that are meant to hold merchants accountable are not technical enough to really understand the full issue and its exploits. Therefore, any self respecting merchant approaches it like this:

1. Keep the script list in a nice tool that maintains that list for you (even if subrequests are made, if they are not bad automatically add them to the list etc)
2. Use a service to stop scripts from loading if they are not trusted. CSP can be used here but realistically most vendors are opting for JS here because CSP has a break first tell later logic which is just not acceptable for most businesses.
3. Check the FULL LIST of security headers to comply with 11.6.1.
4. Download the scripts regularly or actively to maintain some level of forensics of changes. Not having the script payloads is a bad idea.

However, many assessors are approving large logo merchants based on using a static website scanner which are not able to block, verify or secure anything. A static solution to a dynamic problem.

The reason why that HORRENDOUS solution became an option:

1. GRCs struggle to get engineering to add any thing to a page
2. GRCs don't want to maintain or hold responsibility for anything on a page unless they have to
3. Many assessors are allowing it, PCI SSC is not clear on whether its satisfies the requirement or not.

To clarify: a client-side script by a bad actor is very likely to avoid serving a malicious script to a scanner by avoiding cloud IPs or sampling that attacks to specific user agents in certain timezones etc etc. A scanner is as effective as having a fire alarm that only works on Monday for 15 minutes.

The real request here is:

1. A mechanism to stop client-side executed/injected attacks aiming to exfiltrate credit card information either by listening in on form, rendering an iframe over it, hijacking XHR...

PCI-DSS-v4_0_1.pdf

[ScottHelme]

PCI SSC APO here too.

I guess ultimately this question will come down to a QSA to approve the method or not, but my view is that SB-SRI would be a positive step up from SRI and I would recommend it to our customers. SB-SRI solves the main fragility of SRI which is that it requires a static asset, and so can be deployed more widely, resulting in better coverage.