Conformità PCI e risorse esterne http / https

(IANAQSA)

Il PCI DSS richiede solo la crittografia per proteggere i dati dei titolari di carta:

Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.

Il contenuto di una pagina accidentale che non coinvolge i dati dei titolari di carta non richiede quel livello di protezione. Ovviamente, se il checkout del carrello (che deve essere protetto in quanto viene immesso il dato della carta) include un'immagine http: // non protetta, la maggior parte dei browser si lamenterà, quindi generalmente vorrai proteggere anche le immagini e altri contenuti.

Se utilizzi una libreria js di terze parti come applicazione di pagamento, la conformità PCI è un problema, probabilmente solo assicurandoti che sia conforme allo standard PA-DSS. Tuttavia, se stai utilizzando una js di terze parti per rendere la tua pagina carina, e non gestisce i dati delle carte o incide in alcun modo sui flussi di comunicazione dei dati delle carte, non avrà alcun impatto sulla conformità.

Aggiornato per rispondere al commento di @cchamberlain:

I credo che le librerie di terze parti come Angular rientrino in DSS ( versione 3.1 citato qui) sezione 6.2:

6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Install critical security patches within one month of release.

Contrastare ciò con "software personalizzato o personalizzato sviluppato da una terza parte" nella sezione 6.3:

6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:

• In accordance with PCI DSS (for example, secure authentication and logging)
• Based on industry standards and/or best practices.
• Incorporating information security throughout the software-development life cycle

Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.

Quindi, se si tratta di un prodotto software per la distribuzione generale, si presume che non sia dannoso e che sia necessario mantenerlo aggiornato e reagire agli avvisi di sicurezza. Ma se qualcuno sviluppa un codice personalizzato per te, devi trattarlo con livelli equivalenti di scrutinio per il tuo codice.

Penso che questo si riduca a "fidarsi del fatto che i proprietari della biblioteca non abbiano cattive intenzioni" per qualcosa come Angular. Sei ancora responsabile se fanno qualcosa di inappropriato, naturalmente.

L'uso di immagini non protette su pagine che richiedono dati dei titolari di carta o (più spesso) potrebbe non mettere in pericolo i dati dei titolari di carta, ma dovresti aspettarti un'obiezione dalla Guida per il requisito 4.1:

Generally, the web page URL should begin with "HTTPS" and/or the web browser display a padlock icon somewhere in the window of the browser.

Se l'UI di avviso con contenuto misto interrompe la lettera di questa guida dipende dal browser in questione, ma certamente è contro lo spirito.

Avere JavaScript ospitato su HTTP per qualsiasi pagina del sito è inoltre estremamente pericoloso in quanto consentirebbe a un utente malintenzionato MitM di eseguire il cross-site-script nella pagina di pagamento. Lo stesso vale per i CSS poiché su alcuni browser ci sono estensioni che consentono di includere script attivi negli stili.

Avere script / fogli di stile ospitati esternamente rientrerebbe in "Uso di provider di servizi di terze parti". Esistono provider di hosting che mantengono la certificazione PCI per questo scopo; specchi per uso generico dovrebbero essere evitati. Raramente vale il rischio di mettere in contatto una terza parte con i dati del titolare della carta (che potenzialmente qualsiasi JS sul tuo sito è) solo per evitare alcuni K di traffico di hosting statico.