Il modulo di pagamento da http è sicuro? [chiuso]

Question

Il modulo di pagamento da http è sicuro? [chiuso]

#1 da (1 voti)
#2 da (1 voti)

2

Ci sono molti gateway di pagamento (Worldpay, PayPal, ..) che offrono una facile integrazione, quando la semplice pagina web utilizza il reindirizzamento dell'URL alla pagina di pagamento. HTTPS (worldpay, paypal), in cui l'utente pubblica i dettagli della sua carta e i dati di pagamento, viene crittografato e considerato affidabile.

Ci sono due pagine Web HTTP e HTTPS (sicuro) per il pagamento. L'utente dalla pagina HTTP non crittografata viene reindirizzato alla pagina HTTPS, utilizzando l'URL di reindirizzamento come: link

La pagina HTTPS viene aperta all'utente da una normale pagina HTTP, facendo clic su un pulsante che apre un nuovo URL. La stringa dell'URL con i suoi parametri sta viaggiando in chiaro sul sito HTTPS. Il parametro URL contiene l'ID commerciante e l'importo.

L'HTTPS (worldpay) visualizza tutti i dati inviati tramite url (quindi se l'attacco MITM cambia, i dati modificati verranno visualizzati) e l'utente inserisce i dettagli della sua carta lì. Questa pagina di destinazione è crittografata e l'utente può ricontrollare i dettagli del pagamento. Come pagare per chi, qual è l'importo, ecc.

La domanda è, è sicuro?

Per il feedback, cerco di ri-modificare e chiarire di più. 2015/04/17 EDIT: "abbastanza sicuro" = è affidabile, e puoi pagare senza il rischio che un hacker rubi i tuoi soldi. Non sono sicuro, non è un trucco facile per imbrogliare quel tipo di sistema. Btw. questo è il modo suggerito dalle società di gateway di pagamento di terze parti (paypal, worldpay).

link Afferma: "Tutta l'elaborazione dei pagamenti è gestita dal server sicuro di WorldPay, quindi tu ei tuoi acquirenti potete essere sicuri che i loro dettagli di pagamento siano sicuri."

Supporto / kb / bg / pdf / rhtml.pdf "I vantaggi sono che quasi tutti i browser supportano le stringhe URL e sono semplici da codificare e da utilizzare, tuttavia, poiché il destinatario può vedere tutti gli attributi e i valori nella stringa dell'URL, potrebbe non essere sicuro."

http web-browser tls man-in-the-middle

posta oupse1234 15.04.2015 - 16:35

fonte

2 risposte

Leggi altre domande sui tag http web-browser tls man-in-the-middle

è OSSEC efficace nella protezione di un'installazione Drupal? RSA private / public keys

score 1 · Answer 1

Tale impostazione può essere considerata attendibile, poiché i dettagli del pagamento non possono essere estratti dal tuo hacker e i dettagli del pagamento possono essere verificati in modo sicuro.

La cosa a cui prestare attenzione è che molti utenti potrebbero non preoccuparsi di ricontrollare i dettagli sulla pagina https, o se ci sono dei parametri "nascosti" inviati che non vengono visualizzati e verificati esplicitamente.

score 1 · Answer 2

"Abbastanza sicuro" e "fidato" sono frasi rischiose.

Se stai parlando di trasmettere un numero di carta di credito, un indirizzo e-mail, SSN o altre informazioni personali non crittografate come testo normale tramite un parametro URL, questo è sicuramente non sicuro, indipendentemente da dove sta andando. La pagina dovrebbe essere una pagina crittografata affinché tali informazioni vengano crittografate durante il transito. Se non lo è, allora chiunque nel mezzo con un ascoltatore passivo potrebbe raccogliere tali informazioni.

Se stai facendo sandbox puoi aprire uno sniffer di pacchetti (come wireshark) e controllare per vedere cosa viene effettivamente trasferito.

Se la pagina che cattura (contiene il modulo) le informazioni sensibili sono crittografate, è probabile che vada bene.

Nel certificato ti consigliamo di verificare il livello che stanno utilizzando per l'autenticazione, ovvero quanti bit di crittografia.
Dovrai assicurarti che il certificato che stanno utilizzando sia fatto da un'adeguata autorità di certificazione di terze parti, quindi non è facilmente falsificato.
Idealmente il sito avrebbe il proprio certificato che crittografa la connessione per il resto del modulo.

Se una pagina non protetta sta caricando elementi da una pagina protetta, i rischi con contenuti non protetti possono esistere in relazione a Javascript o ad altre funzionalità di scripting lato client. Se ad esempio un Javascript viene compromesso su quella pagina, in teoria può acquisire i dati da un modulo utilizzando listener di eventi qualcosa come onChange e AJAX prima che il contenuto del modulo venga inviato tramite la connessione protetta. Javascript potrebbe anche consentire un attacco man-in-the-middle che cancella i contenuti in trasmissione tramite un gestore come onSubmit . Questo dipende molto dal fatto che il sito stesso sia "abbastanza sicuro" da non consentire attacchi di iniezione e cose del genere.

Spesso le persone non pensano a cose come gli annunci banner che spesso eseguono Javascript. Un banner pubblicitario può facilmente acquisire dati da qualsiasi altra cosa nella pagina purché abbia le stesse autorizzazioni. Lo stesso vale per i plugin lato client a seconda del browser.