Le stesse informazioni sensibili nella risposta HTML che erano state pubblicate prima

Naviga le tue risposte
4

È un problema inviare le stesse informazioni sensibili (PCI, PII) dal server nella risposta HTML che un utente ha precedentemente pubblicato sul server?

Sulla nostra pagina web, l'utente inserisce alcune informazioni chiave (nome / indirizzo / tessera / numero di conto / ecc.), che viene quindi pubblicato sul nostro server e viene inviata una pagina contenente alcuni dati non sensibili (date, account bilanciamento, ecc.) insieme alle informazioni chiave che ha appena fornito, in modo che l'utente possa modificare ulteriormente alcuni valori chiave per alterare la ricerca.

Esempio:
POST al server: ...&cardNumber=1111222233334444&...
Risposta dal server: <html> ... <input name="cardNumber" value="1111222233334444" ... /> Here are some details about your card... </html>

Recentemente il sito Web è stato sottoposto a una valutazione della sicurezza in cui il revisore ha segnalato questo comportamento come una vulnerabilità ad alta priorità, che non dovremmo restituire alcuna informazione sensibile non mascherata nella risposta HTML dal server ( value="111122223333444" nell'esempio precedente). Hanno menzionato l'attacco MITM, dove qualcuno può rubare informazioni sensibili dai dati HTML.

Gli sviluppatori hanno contestato questo dicendo che il MITM può rubare i dati da entrambi i modi di traffico, quindi il MITM potrebbe rubare i dati dal messaggio POST e il server non sta rinviando dati più sensibili di quanto è stato originariamente inviato al server. E hanno fornito alcune tracce di rete che mostravano alcuni siti Web ben conosciuti su Internet anche facendo questa pratica.

Chi ha ragione: il revisore della sicurezza o gli sviluppatori e perché?

Nota che il sito web è accessibile solo tramite HTTPS e altre misure di sicurezza (controllo della cache, scadenza della pagina, ecc.) anche implementate.

    
posta Tamás Somogyi 25.10.2017 - 14:25
fonte

2 risposte

1

I tuoi sviluppatori hanno ragione. Se HTTPS viene utilizzato dal client al server che elabora la richiesta, la connessione deve essere altrettanto sicura in entrambe le direzioni. Se entrambe le comunicazioni si trovano nella stessa sessione SSL, la chiave utilizzata per la crittografia effettiva dovrebbe essere identica.

Tuttavia, si prega di chiedersi perché lo stai facendo? Se il cliente ha appena inviato i dettagli della carta, perché questi devono essere restituiti nell'HTML? Questo non può essere gestito con JavaScript sul client?

Inoltre, non conosco completamente gli standard di sicurezza dei dati PCI, ma ciò potrebbe violare quelli. So che per le ricevute ci sono dei limiti.

La guida alle azioni e alle donazioni recita -

Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed.

Per me mandare questo in HTML è un modo di mostrarlo. Ci sono anche rischi aggiuntivi che coinvolgono codice dannoso sul client.

    
risposta data 25.10.2017 - 14:49
fonte
0

Dipende - ciò che il revisore ha detto non è corretto se si passa attraverso TLS. Ma il problema qui (correggimi se sbaglio) è che la pagina web ora contiene informazioni riservate.

Quindi, se viene rilevato un difetto aggiuntivo come XXS, queste informazioni sensibili possono essere estratte dalla struttura HTML. L'utente ha ora una copia memorizzata nella cache dei dettagli della sua carta di credito sul proprio computer, se è una macchina condivisa, può essere estratta.

Sì, dovresti risolvere il problema.

    
risposta data 24.01.2018 - 01:05
fonte

Leggi altre domande sui tag

È possibile che il malware si trovi nel BIOS o nell'hardware? Che differenza fa la vicinanza dell'attaccante al bersaglio / punto di accesso alla suscettibilità di KRACK?