Sicurezza nella creazione sito e-commerce

[nuovoUtente86]

Originariamente inviato da cionci

Io ho detto ben altra cosa. I dati memorizzati sulla sessione sono conservati sul server, quindi è chiaro che di quelli non deve preoccuparsi.
La gestione del sessionID è ben altra cosa. Il controllo del referer è d'obbligo...
Prima di tutto bisognerebbe usare il metodo GET il meno possibile e nella chiusura delle transazioni bisognerebbe memorizzare il referer che ci si aspetta o una onetime password all'interno della sessione, per poi verificarla quando arriva la richiesta effettiva che chiude la transazione.

Ho quotato il tuo messaggio solo per agganciarmi al discorso sessioni, non per l' integrità dei dati conservati sul server bensi per l' accessibilità alla stessa. Sicuramente l' utilizzo di un token univoco e non predicibile è una delle tecniche più efficaci. Anche il referer offre ampie garanzia, anche se esiste una remota possibiltà di spoofing.

[fabry78]

Io non passo niente con il metodo GET ma solo con il metodo POST. Comunque mi pare di capire che le sessioni possono comunque essere intercettate e quindi mi conviene usare un certificato ssl almeno dalla pagina dove il cliente incomincia a compilare il form dopo aver finito lo shopping. Giusto?

Purtroppo non ho capito proprio tutto il vostro discorso, ad esempio non so cosa sia il refer, ma se serve per identificare l'ordine, io ho fatto in modo che quando l'utente ha finito di compilare il form, si inserisce l'ordine nel database e mi viene inviata una email con un codice univoco per identificare il cliente e l'ordine. Dopodichè le sessioni vengono distrutte.

[nuovoUtente86]

Senza entrare troppo nel tecnico, come saprai HTTp è un protocollo stateless per cui impone il mantenimento dello stato conversazionale in maniera programmatica. Solitamente tale stato viene mantenuto attraverso dei piccoli file rimbalzati tra client e server, appunto i cookie. Una volta in tali file venivano memorizzati dati utili allo stato applicativo, oggi, per questioni di sicurezza si tende a mantenere tali dati sul server ed utilizzare i cookie come riferimento alla sessione stessa.
Tale meccanismo è utilizzato per mantenere anche lo stato di autenticazione di ogni utente, e se è vero che la fase di login è gestita su trasporto sicuro, lo stesso non è per le operazioni successive (o almeno non per tutte). Va da se che chiunque riesca a sniffare un sessionID (puooi farlo tu stesso attraverso wireshark a titolo di curiosità) oppure riesca ad indurre un utente ad utilizzare una sessione nota, può avere libero accesso, ad esempio alla gestione dell' account o degli ordini.
Ora questa è pura teoria, nella pratica vanno realisticamente ponderate le superfici di attacco, come le reti wireless ma ormai anche gli utenti medi sono ben attenti agli aspetti crittografici (e di solito si da accesso a persone fidate) mentre gli hotspot ben fatti implementano tecniche di virtual switching (al minimo anche il wpa lo fa), e se cosi non fosse in ogni caso si sarebbe esposti a rischi anche su SSL, che è vulnerabile ad attacchi MITM.
Questo per dire che, un codice server-side ben programmato offre un ottimo compromesso di sicurezza anche senza ricorrere in maniera ossessiva alla sicurezza di canale.

[cionci]

Non possono essere intercettati i dati che sono in sessione, può venire intercettato il SessionId, che è quell'identificativo che viaggia fra client e server sotto forma, solitamente, di cookie. Chiaramente se ho il SessionId posso anche recuperare i dati della sessione "travestendomi" da client.
Un modo per proteggersi dal session spoofing è quello di memorizzare l'indirizzo IP del client nella sessione. Se l'indirizzo non corrisponde non accetto la richiesta. Questa cosa è aggirabile, ma solitamente solo in un verso: cioè si possono inviare richieste spoofate (falsificando il proprio indirizzo IP), ma non si possono ricevere le risposte a tali richieste (perché vanno a finire all'indirizzo IP originale), ovviamente sempre che l'attaccante non possa leggere tutto il mio traffico. E' quindi chiaro che se una transazione si svolge in tre fasi:
1 - client request
2 - server reply
3 - client confirmation
E nel server reply includi una onetime password, diventa veramente difficile sfruttare l'ip spoofing. A meno di flaw nella generazione della onetime password.

Una onetime password è ad esempio un stringa generata a partire da:
- data e ora attuale
- username e password
- numero di richieste totali di onetime password (un semplice contatore su un database è sufficiente)
Ti crei una stringa composta da tutte queste informazioni ed applichi un hash come SHA1.
Spedisci questo SHA1 al client in un campo hidden del form di conferma della transazione e lo salvi nella sessione. Quindi il client te lo rimanda con la form e tu lo verifichi prima di chiudere la transazione.

Il referer è un campo dell'intestazione HTTP che arriva insieme alla richiesta. Indica l'url della pagina da cui è partita la richiesta corrente.
In php: $_SERVER['HTTP_REFERER']

[cionci]

Originariamente inviato da nuovoUtente86

che è vulnerabile ad attacchi MITM.
Questo per dire che, un codice server-side ben programmato offre un ottimo compromesso di sicurezza anche senza ricorrere in maniera ossessiva alla sicurezza di canale.

Per completezza: MITM = Man In The Middle, cioè l'attaccante si trova in un posizione del percorso che fanno i dati sulla rete che gli permette di leggere/monitorare e/o modificare i dati che il server ed il client si scambiano.
In ogni caso concordo anche io sull'ultima riflessione

[nuovoUtente86]

La verifica dell' Ip, però non è una tecnica realmente realizzabile per 2 questioni principali:
- la maggior parte delle connessioni consumer hanno ip dinamico, che potrebbe cambiare in maniera del tutto legittima.
- ormai molti client condividono gli ip pubblici, ed è proprio sui segmenti privati che si è più esposti al furto del sessionID, rendendo di fatto nullo tale controllo.

[cionci]

Originariamente inviato da nuovoUtente86

La verifica dell' Ip, però non è una tecnica realmente realizzabile per 2 questioni principali:
- la maggior parte delle connessioni consumer hanno ip dinamico, che potrebbe cambiare in maniera del tutto legittima.
- ormai molti client condividono gli ip pubblici, ed è proprio sui segmenti privati che si è più esposti al furto del sessionID, rendendo di fatto nullo tale controllo.

E' però un livello ulteriore di protezione. Non è certa, ma è sicuramente utile.
Se l'IP cambia legittimamente, si fa decadere comunque la sessione. Mi sembra anche giusto...

[fabry78]

Ragazzi complimenti per la conoscenza in materia, ma vorrei risolverla in un modo semplice perchè in sicurezza sono poco esperto e ho difficoltà a seguirvi. Riassumendo, per risolvere tutto ed essere sicuri che i dati non vengano intercettati posso inserire un certificato ssl almeno dalla pagina dove il cliente incomicia a compilare il form?

[nuovoUtente86]

Originariamente inviato da cionci

Non possono essere intercettati i dati che sono in sessione, può venire intercettato il SessionId, che è quell'identificativo che viaggia fra client e server sotto forma, solitamente, di cookie. Chiaramente se ho il SessionId posso anche recuperare i dati della sessione "travestendomi" da client.
Un modo per proteggersi dal session spoofing è quello di memorizzare l'indirizzo IP del client nella sessione. Se l'indirizzo non corrisponde non accetto la richiesta. Questa cosa è aggirabile, ma solitamente solo in un verso: cioè si possono inviare richieste spoofate (falsificando il proprio indirizzo IP), ma non si possono ricevere le risposte a tali richieste (perché vanno a finire all'indirizzo IP originale), ovviamente sempre che l'attaccante non possa leggere tutto il mio traffico. E' quindi chiaro che se una transazione si svolge in tre fasi:
1 - client request
2 - server reply
3 - client confirmation
E nel server reply includi una onetime password, diventa veramente difficile sfruttare l'ip spoofing. A meno di flaw nella generazione della onetime password.

Una onetime password è ad esempio un stringa generata a partire da:
- data e ora attuale
- username e password
- numero di richieste totali di onetime password (un semplice contatore su un database è sufficiente)
Ti crei una stringa composta da tutte queste informazioni ed applichi un hash come SHA1.
Spedisci questo SHA1 al client in un campo hidden del form di conferma della transazione e lo salvi nella sessione. Quindi il client te lo rimanda con la form e tu lo verifichi prima di chiudere la transazione.

Il referer è un campo dell'intestazione HTTP che arriva insieme alla richiesta. Indica l'url della pagina da cui è partita la richiesta corrente.
In php: $_SERVER['HTTP_REFERER']

Giusto per aggiungere una chicca sul discorso ip spoofing, va detto che la maggior tecnica utilizzata è il source routing, anche se oggi i provider e i sistemi operativi non lo supportano (o almeno dovrebbero, ma su Windows è attivo di default). Questo per dire che un altro aspetto fondamentale, è l' amministrazione del server.

[cionci]

Originariamente inviato da fabry78

Riassumendo, per risolvere tutto ed essere sicuri che i dati non vengano intercettati

Non potrai mai essere sicuro
Sicuramente una sessione SSL al momento del checkout è buona cosa, fino al completamento della transazione.

Tre tecniche piuttosto semplici da usare te le ho date:
- salvare l'IP nella sessione e verificarlo ad ogni richiesta
- controllare il referer (se una richiesta arriva ad una pagina di checkout ad esempio può avere come referer solo determinate pagine del tuo sito)
- onetime password nei form (ad esempio quando generi il form del carrello puoi inserire la onetime password per fare il checkout)

[fabry78]

Ok grazie, valuterò i casi, almeno ho capito cosa si può fare.

[nuovoUtente86]

Originariamente inviato da cionci

E' però un livello ulteriore di protezione. Non è certa, ma è sicuramente utile.
Se l'IP cambia legittimamente, si fa decadere comunque la sessione. Mi sembra anche giusto...

Come si diceva in qualche post precedente, dipende anche dal gusto personale dello sviluppatore (e per fortuna che il mondo è vario), però se colossi come Ebay e Paypal, che su questo vivono e straguadagnano, non lo fanno qualche motivo ci sarà. Personalmente troverei fastidiosa, lato utente, una disconnessione improvvisa perchè il provider cambia ip, ma magari per altri è una buona soluzione.

[dojolab]

Originariamente inviato da nuovoUtente86

Come si diceva in qualche post precedente, dipende anche dal gusto personale dello sviluppatore (e per fortuna che il mondo è vario), però se colossi come Ebay e Paypal, che su questo vivono e straguadagnano, non lo fanno qualche motivo ci sarà. Personalmente troverei fastidiosa, lato utente, una disconnessione improvvisa perchè il provider cambia ip, ma magari per altri è una buona soluzione.

Quoto. In ufficio abbiamo una doppia linea con doppio IP in uscita, di conseguenza, spesso, mi vedo saltare la connessione (Internet Banking, ecc) e la cosa, anche se sicura, è alquanto fastidiosa.

[nuovoUtente86]

Originariamente inviato da dojolab

Quoto. In ufficio abbiamo una doppia linea con doppio IP in uscita, di conseguenza, spesso, mi vedo saltare la connessione (Internet Banking, ecc) e la cosa, anche se sicura, è alquanto fastidiosa.

Ora rischiamo di andare OT, ma potrebbe essere anche un problema indipendente dall' implementazione applicativa, ma ad un livello più basso ovvero di bonding o load balancing non gestito correttamente.

[dojolab]

Originariamente inviato da nuovoUtente86

Ora rischiamo di andare OT, ma potrebbe essere anche un problema indipendente dall' implementazione applicativa, ma ad un livello più basso ovvero di bonding o load balancing non gestito correttamente.

Su un IB penso sia più una questione 'applicativa' che un problema da sistemisti