PCI Compilance - Processore di pagamento personalizzato

Per quanto riguarda PCI-DSS, qualsiasi sistema che tocchi (non archivi, non processi, ma tocca) o CAN TOUCH (cioè, sullo stesso segmento di rete di un sistema che tocca) deve essere conforme allo standard PCI-DSS. Il server A sta chiaramente toccando il PCI e dovrebbe quasi certamente essere conforme.

Effettuando un reindirizzamento tokenizzato, si risolve il problema perché l'utente non immette i dettagli PCI sul proprio sito e i sistemi non gestiscono mai i dati PCI. Tutto ciò che invii è i dettagli su ciò che deve essere addebitato e quindi recuperare un token che è effettivamente la ricevuta del pagamento. Poiché nessuna di queste informazioni è PCI e non si ha alcuna connessione fisica diretta con il gateway di pagamento, il punto vendita non dovrebbe rientrare nel PCI al momento della stesura di questo documento (per quanto ne so, non sono un avvocato né coinvolto attivamente con la conformità PCI in questo momento).

Per quanto riguarda la descrizione di un keylogger che compromette la sicurezza, PCI-DSS è uno standard di sicurezza dei dati per proteggere PCI dal lato server / fornitore. Un client exploit sarebbe un client compromesso e si trova sul lato del cliente, quindi non rientra nell'ambito di PCI-DSS. Questo è il motivo per cui se l'utente riceve un virus da te prima del reindirizzamento, non compromette la conformità PCI di PayPal in quanto il virus proviene da un sistema non coperto e si trova sul lato client. Non è un compromesso di PayPal, solo un compromesso di un sito a caso che non ha bisogno di essere conforme PCI che porta a un computer client compromesso.

Come QS PCI precedente , la mia opinione è no. Con i dettagli disponibili, sembra che il server A venga considerato parte dell'ambiente del titolare della carta in quanto le transazioni con carta di credito vengono trasferite attraverso di esso tramite il POST. In questa situazione, non si è in linea con il Requisito 6: Sviluppo e manutenzione di sistemi e applicazioni sicuri e Requisito 11: testare regolarmente i sistemi ei processi di sicurezza.

No, non è conforme allo standard PCI.

Perché? Perché "A" è la parte della catena di elaborazione delle informazioni del titolare della tessera. In questo caso, "A" è una parte essenziale del tuo POS basato su IP.

- Nel primo caso: Breaking PCI-DDS 6.5 (in particolare 6.5.7) [Pagina 42]

We can ask for credit card details at server A, and send it via POST to server B

Questo è semplice, "A" compromesso = informazione del titolare della carta compromessa . Un utente malintenzionato può inserire codice malevolo (più comunemente JavaScript) per rubare le informazioni del titolare della carta.

- Nel secondo caso: Rompendo PCI-DDS 6 [Pagina 38 ]

We can ask for credit card details at server B using iframe, and send it via POST to same server

Fortunatamente, grazie alla Politica Same-Origin , l'utente malintenzionato non può accedere ai contenuti di l'iFrame servito da "B" utilizzando script su una pagina servita da "A" (presumo che tu li abbia in due domini diversi).

Tuttavia, se l'utente malintenzionato ha accesso a "A", è in grado di utilizzare gli exploit Java o Flash per installare maleware / keylogger sulla macchina del client che porta al compromesso delle informazioni del titolare della carta. Un'altra possibilità è di indurre l'utente a installare volontariamente alcuni malware mascherati come plug-in richiesto o consigliato o "software di sicurezza bancario".