In juni 2024 publiceerde PCI een nieuwe versie (4.0.1) en vanaf april 2025 is deze versie actief.
De impact voor webshops die card betalingen accepteren binnen de eigen checkout is groot. Benieuwd naar de impact van PCI 4.0.1 voor jouw webshop?
Lees het artikel PCI DSS voor uitleg over wat PCI is.
Paragraaf 6.4.3 van de Requirements and Testing Procedures (Engelstalig)
Defined Approach Requirements
All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: A method is implemented to confirm that each script is authorized. A method is implemented to assure the integrity of each script. An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
Customized Approach Objective
Unauthorized code cannot be executed in the payment page as it is rendered in the consumer’s browser.
Purpose
Scripts loaded and executed in the payment page can have their functionality altered without the entity’s knowledge and can also have the functionality to load additional external scripts (for example, advertising and tracking, tag management systems).
Such seemingly harmless scripts can be used by potential attackers to upload malicious scripts that can read and exfiltrate cardholder data from the consumer browser.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Examples
The integrity of scripts can be enforced by several different mechanisms including, but not limited to:
- Sub-resource integrity (SRI), which allows the consumer browser to validate that a script has not been tampered with.
- A CSP, which limits the locations the consumer browser can load a script from and transmit account data to.
- Proprietary script or tag-management systems, which can prevent malicious script execution.
Wat is een Content Security Policy / CSP?
Een CSP is een technische security standaard die ervoor zorgt dat in de browser alleen scripts worden uitgevoerd die vooraf zijn vastgelegd. Dit voorkomt dat er onwenselijke scripts uitgevoerd worden.
Wat is het gevaar van geen Content Security Policy / CSP in een webshop?
Dit is een voorbeeld wat er in de praktijk in webshops gebeurt die geen CSP hebben:
- Een hacker krijgt toegang tot de webshop en voegt een script toe.
- Dit script voegt creditcard velden toe aan de checkout en stuurt de betaler naar de betaalprovider om daar nogmaals de creditcard gegevens in te voeren (waardoor de betaling doorgaat en niemand iets doorheeft).
- De betaler vult creditcard gegevens in, de hacker laat deze naar zichzelf sturen.
Samengevat zijn de aandachtspunten voor webshops:
| Aandachtspunt | Toelichting |
|---|---|
| Zorg dat je webshop een Content Security Policy heeft. | Ook als de betaler de kaartgegevens bij de betaalprovider invult. Want zodra een kwaadwillige deze op jouw webshop laat invullen valt je webshop in scope van PCI. |
| Zorg voor een overzicht van de toegestane scripts. | Voor Magento webshops is Sansec Watch een goede keuze. Deze gebruikt de standaard report functionaliteit van Magento om een overzicht te maken, te beheren en vervolgens in Magento te voorkomen dat ze ingeladen worden. |
| Zorg dat je zo min mogelijk scripts gebruikt. | Dit voorkomt een te grote header. Als voorbeeld, Magento laadt standaard erg veel scripts in. Dit beperken is aan te raden om het beheersbaar en snel te houden. Veel extensies laden scripts in (die ze ook toevoegen aan de CSP) maar die niet relevant zijn. Als voorbeeld, betaalproviders laden bijvoorbeeld Google Pay scripts in terwijl deze niet aan staat. |