Queste istruzioni di integrazione del commerciante sono errate sull'interazione server-cliente?

Question

Queste istruzioni di integrazione del commerciante sono errate sull'interazione server-cliente?

#1 da (3 voti)
#2 da (0 voti)

2

Sto lavorando con un gateway di pagamento che sembra avere un fondamentale fraintendimento dei "clienti" e come proteggere i dati sensibili.

Le istruzioni di integrazione riguardano principalmente una modalità operativa di "reindirizzamento", in cui un cliente viene indirizzato al sito Web del gateway per inserire i dati della carta di credito, dove visualizzano una ricevuta e poi vengono reindirizzati al tuo sito web.

Documenti :

https://www.myvirtualmerchant.com/VirtualMerchant/download/developerGuide.pdf

Ecco un esempio

<form 
action="https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process
.do" method="POST"> 
<input type="hidden" name="ssl_merchant_id" 
value="my_virtualmerchant_id">
<input type="hidden" name="ssl_user_id" value="my_user_id"> 
<input type="hidden" name="ssl_pin" value="my_pin">
<input type="hidden" name="ssl_transaction_type" value="ccsale">
<input type="hidden" name="ssl_show_form" value="true"> 
<input type="hidden" name="ssl_amount" value="14.95"> 
<input type="submit" value="Click to Order"> 
</form>

Questo è il paragrafo che mi riguarda:

All sensitive data, specifically your VirtualMerchant credentials, should be placed in server side code rather than placing hidden value fields on an HTML form. This will limit the ability of malicious users to edit and use this data for their own fraudulent purposes. The use of server-side scripting allows custom HTML to be delivered to a client machine. The code that generates the custom HTML is processed on the Web server before the HTML is sent to the user's machine over the Internet. This is in contrast to client-side scripting where the HTML is modified, typically by java-script in the client's machine after the HTML and java are sent from the Web server. The primary strength of using serverside scripting with VirtualMerchant integration is the ability to hide the sensitive processing credentials from the browser.

Sembra eccezionale, non esponendo il mio ID account al client.

Tuttavia non penso che ciò che stanno suggerendo si prenda cura di esso. Posso solo vedere due modi per nascondere completamente i dettagli dal client:

Chiedi al server di agire come client e il browser non viene mai indirizzato al sito web del gateway di pagamento

Offrono questa modalità, ma la maggior parte dei documenti si riferisce invece alla modalità di modulo HTML / lato client.
Utilizza un token firmato di qualche tipo - che non supportano.

Questo paragrafo, tuttavia, sembra pretendere qualcosa sull'utilizzo di "scripting lato server" per fornire "HTML personalizzato" e quindi nascondere i dettagli? Semplicemente non vedo alcun modo - anche se il reindirizzamento è avvenuto tramite un'intestazione Location , i dati sarebbero comunque stati esposti al browser e chiunque con intenti malevoli potrebbe facilmente ottenerlo.

Qualcuno può aiutarmi a capire perché mi sembra così sbagliato?

pci-dss web-service

posta Nicole 29.06.2012 - 10:40

fonte

2 risposte

Leggi altre domande sui tag pci-dss web-service

Perché i sistemi di accesso dicono agli utenti che un indirizzo e-mail non è nel sistema? [duplicare] 'Ripresa sessione SSL con ID sessione memorizzata nella cache'

score 3 · Answer 1

A colpo d'occhio, sembra che le istruzioni nella guida per sviluppatori non siano tanto < em> sbagliato semplicemente fuorviante. Come si nota, praticamente tutti gli esempi mostrano i campi sensibili ssl_merchant_id , ssl_user_id e ssl_pin incorporati come campi modulo nascosti nel codice HTML inviato al cliente. Tuttavia, se lavori a modo tuo fino al capitolo 9, "Sicurezza delle transazioni", troverai il seguente paragrafo sotto "Suggerimenti per le migliori pratiche" ( boldface originale, corsivo mio):

"Server Side Code – Your users can read HTML source code from your Web pages when they are downloaded to their Web browser. Although our simple examples in the document show this as a method for passing data to VirtualMerchant, we do not recommend this for your production website. All sensitive merchant data, including transaction amounts and your VirtualMerchant credentials, should be placed in server side code, rather than in hidden value fields on an HTML form. This will reduce the ability of malicious users to exploit client browser vulnerability to edit and use this data for their own fraudulent purposes. If you are not knowledgeable enough to implement this on your own, there are quite a few shopping cart providers that inherently provide this service and are compatible with VirtualMerchant."

Quindi, in sostanza, è un caso di "fai come dico, non come faccio io (ti mostro come farlo)".

Detto questo, mi sembra che se tu segui attentamente tutti i altri consigli di sicurezza, passando il commerciante / l'ID utente e il PIN al cliente potrebbero non essere così cattivo come potrebbe sembrare. Fatto bene, avere questi valori dovrebbe solo consentire al cliente l'accesso a un account utente limitato che consente loro solo di effettuare pagamenti - ma è ciò che stai permettendo loro di fare comunque, quindi dovrebbe essere nessun grosso problema.

Ovviamente, ciò vale solo se si può realmente (e si fa) rendere l'account utente utilizzato per il modulo in modo così limitato che è sicuro distribuire ai clienti. Senza ulteriori studi, non posso davvero dire se sia possibile o meno.

score 0 · Answer 2

Ho lavorato con gateway di pagamento per un po 'di tempo e questo può essere un po' confuso.

In primo luogo la seconda affermazione di Elavon contenuta nel capitolo 9, "Sicurezza delle transazioni" afferma che il codice lato server ".. ridurrà la capacità degli utenti malintenzionati di sfruttare la vulnerabilità del browser client per modificare e utilizzare questi dati per i propri scopi fraudolenti. "

L'affermazione sopra è corretta che ridurrà le conoscenze tecniche necessarie per ottenere l'accesso a queste credenziali. Invece di un client che fa clic su Visualizza origine e vede i dati del post, dovrebbero utilizzare il violinista o simili per acquisire i dati del post. Indipendentemente da ciò, si tratta di una vulnerabilità intrinseca di questa architettura. Prima del 2008, la maggior parte dell'elaborazione CC passava come una chiamata API server-server che può determinare un sistema compromesso che raccoglie migliaia di numeri CC, dati utente, ecc. Questa architettura consente una facile manipolazione dei dati su base 1 a 1, ovvero ogni cliente può facilmente cambiare e raccogliere questi dati ma non su larga scala. Anche la regolamentazione della conformità PCI imporrà un enorme carico alla tua organizzazione se completi le transazioni da server a server.

Cosa è necessario fare per mitigare eventuali potenziali compromessi:

Assicurati di creare un utente non amministratore per completare queste transazioni.
DEVI riconciliarti ogni giorno con il fornitore di pagamenti. Per fare ciò è possibile utilizzare l'API per connettersi con il fornitore del gateway di pagamento e prendere TUTTE le transazioni regolate per il numero di giorni x (I do 7). Esegui il ciclo su ciascun batch e controlla ogni singola transazione per verificare la precisione tra entrambi i sistemi (gateway di i tuoi e di pagamento). Ho creato una sofisticata routine di riconciliazione che invia e-mail al personale IT e al nostro ufficio sicurezza se qualcosa non corrisponde correttamente. Questo può essere un utente che modifica l'importo della fatturazione usando il violinista o manipolando il risultato della transazione. Ricorda che sia il post della transazione che il risultato passano attraverso il client con alcune impostazioni e non puoi fare affidamento sul client per essere "veritiero". Se si sta creando un sistema che invia merci fisiche, è necessario attendere che la transazione sia risolta e riconciliata prima di spedire il prodotto per evitare frodi e abusi.

La compromissione delle chiavi di transazione non significa molto in quanto l'attore malintenzionato invierà denaro al tuo conto bancario e nessuno vuole farlo. È necessario assicurarsi che le credenziali di accesso alla console di amministrazione non siano compromesse e non vedo come ciò potrebbe accadere in un ambiente sicuro.

È tuttavia necessario creare un nuovo utente indipendente da quello utilizzato per elaborare le transazioni da riconciliare con il fornitore del gateway. Con l'utente che hai creato per elaborare le transazioni DEVI disattivare l'accesso API per riconciliare. Se qualcuno ottiene l'accesso alle credenziali dell'utente di riconciliazione, può scrivere il codice di riconciliazione utilizzando tali credenziali e ottenere una copia di tutti i tuoi clienti insieme agli importi di acquisto e tutti i tipi di altri dati come nome, indirizzo, ecc.

Il meglio della fortuna, Eric