Sicurezza nella creazione sito e-commerce

[fabry78]

Ciao a tutti, avrei bisogno di un consiglio visto che è la prima volta che realizzo in php un sito di e-commerce senza seguire una guida specifica e soprattutto senza usare cms.

Per la realizzazzione del carrello ho usato le sessioni.

Ora io non so se in termini di sicurezza ho omesso qualcosa e vorrei a tal proposito capire se ci sono da fare dei cambiamenti per evitare sorprese. L'unica cosa che ho fatto è un controllo sulla pagina che mi invia l'ordine nel database, in pratica se nella stessa sessione mi è già arrivato l'ordine nel database ma il cliente deve ancora pagare con la carta , non permetto di aggiornare la pagina (perchè il carrello a questo punto sarebbe vuoto) ,e nè di farne inviare un altro da un'altra finestra del browser, costringo il cliente a finire tutto il procedimento nella stessa finestra e se vuole creare un nuovo carrello, deve prima concludere quello precedente o almeno azzerare il carrello attuale.

Non ho usato nessun sistema di crittografia e non so neache se sia il caso, perchè dovrebbe essere nel mio caso Paypal a usare sistemi di sicurezza penso.

Il sito sembra funziona bene, ma come faccio a sapere se ho realizzato un sistema sicuro prima ancora che si passi il totale della somma del carrello a paypal?

Se qualcuno vuol vedere online la bozza del progetto posso anche fornire l'url.

Grazie.

[dojolab]

Originariamente inviato da fabry78

Ciao a tutti, avrei bisogno di un consiglio visto che è la prima volta che realizzo in php un sito di e-commerce senza seguire una guida specifica e soprattutto senza usare cms.

Per la realizzazzione del carrello ho usato le sessioni.

Ora io non so se in termini di sicurezza ho omesso qualcosa e vorrei a tal proposito capire se ci sono da fare dei cambiamenti per evitare sorprese. L'unica cosa che ho fatto è un controllo sulla pagina che mi invia l'ordine nel database, in pratica se nella stessa sessione mi è già arrivato l'ordine nel database ma il cliente deve ancora pagare con la carta , non permetto di aggiornare la pagina (perchè il carrello a questo punto sarebbe vuoto) ,e nè di farne inviare un altro da un'altra finestra del browser, costringo il cliente a finire tutto il procedimento nella stessa finestra e se vuole creare un nuovo carrello, deve prima concludere quello precedente o almeno azzerare il carrello attuale.

Non ho usato nessun sistema di crittografia e non so neache se sia il caso, perchè dovrebbe essere nel mio caso Paypal a usare sistemi di sicurezza penso.

Il sito sembra funziona bene, ma come faccio a sapere se ho realizzato un sistema sicuro prima ancora che si passi il totale della somma del carrello a paypal?

Se qualcuno vuol vedere online la bozza del progetto posso anche fornire l'url.

Grazie.

Allora premesso il fatto che QUALSIASI sistema online che PERMETTA lo scambio di DATI SENSIBILI tra CLIENT e SERVER (anche il più semplice modulo contatti) sarebbe l'ideale realizzarlo attraverso una connessione crittografata SSL.

Ma questo è un mio personalissimo punto di vista che puoi prenderlo come spunto tu per aumentare il livello di sicurezza; rispondendo alla tua domanda realizzerei TUTTO il carrello e il CHECKOUT sotto crittografia SSL (https).

Per quanto riguarda le sessioni nel carrello è l'unica soluzione fruibile sinceramente, che ti occupa poco tempo e sono abbastanza affidabili; creare delle tabelle temporanee sarebbe troppo esoso in termini di memoria (usi MySQL sicuramente...) e quindi le lascerei da parte.

Spiega bene il procedimento che hai adoperato nella realizzazione del carrello, dall'inserimento del prodotto al checkout. Quando e come controlli la disponibilità del prodotto?

Per PayPAL puoi andare tranquillo poi.

[fabry78]

In pratica ho creato un' array sessione dove ogni volta che un utente clicca sul pulsante "Aggiungi al carrello", tramite il metodo post incremento l'array sessione e la somma da pagare. Il totale lo inserisco poi in un'altra sessione. Quando l'utente ha terminato lo shopping, entra nella pagina carrello, complila un form per i suoi dati e clicca sul pulsante acquista. Sempre con il metodo post mi arriva l'ordine nel database e a questo punto svuoto la sessione carrello, tuttavia se il pagamento è con carta di credito nella pagina successiva appare il pulsante di paypal. I valori passati a quest' ultimo sono i due array sessione, e cioè gli articoli e l' importo totale. Quando Paypal mi avvisa che il pagamento è avvenuto, aggiorno un campo nel database che mi serve per identificare un ordine ormai pagato.

Per quanto riguarda la disponibilità del prodotto, non ho per ora l'esigenza di prenderlo in considerazione.

Io non ho usato nessun https per creare il carrello, e sinceramente non l' ho mai fatto e non so come fare.

E' rischioso in questa maniera? Cosa potrebbe succedere?

[dojolab]

Originariamente inviato da fabry78

In pratica ho creato un' array sessione dove ogni volta che un utente clicca sul pulsante "Aggiungi al carrello", tramite il metodo post incremento l'array sessione e la somma da pagare. Il totale lo inserisco poi in un'altra sessione. Quando l'utente ha terminato lo shopping, entra nella pagina carrello, complila un form per i suoi dati e clicca sul pulsante acquista. Sempre con il metodo post mi arriva l'ordine nel database e a questo punto svuoto la sessione carrello, tuttavia se il pagamento è con carta di credito nella pagina successiva appare il pulsante di paypal. I valori passati a quest' ultimo sono i due array sessione, e cioè gli articoli e l' importo totale. Quando Paypal mi avvisa che il pagamento è avvenuto, aggiorno un campo nel database che mi serve per identificare un ordine ormai pagato.

Per quanto riguarda la disponibilità del prodotto, non ho per ora l'esigenza di prenderlo in considerazione.

Io non ho usato nessun https per creare il carrello, e sinceramente non l' ho mai fatto e non so come fare.

E' rischioso in questa maniera? Cosa potrebbe succedere?

Beh se hai usato un sistema saggio e corretto per filtrare tutti i dati in transazione su POST e SESSION sei a posto così a rigor di logica è un procedimento corretto.

Quando andrai ad analizzare la disponibilità dei prodotti (cosa che dovresti tenere in considerazione fin da subito, se due utenti acquistano contemporaneamente, cosa succede?) dovrai lavorarci con molta attenzione.

Per HTTPS basta che attivi un certificato SSL su Apache; a questo punto per 20 dollari conviene comprarne uno certificato... (per modo di dire... )

[fabry78]

Ma poi quale sarebbe il rischio? Infondo il pagamento avviene su paypal in https. In dati passati a pay pal con il metodo post sono gli articoli, la somma totale e i dati del cliente. Possono essere manipolati in qualche modo prima di arrivare a paypal?

[dojolab]

Originariamente inviato da fabry78

Ma poi quale sarebbe il rischio? Infondo il pagamento avviene su paypal in https. In dati passati a pay pal con il metodo post sono gli articoli, la somma totale e i dati del cliente. Possono essere manipolati in qualche modo prima di arrivare a paypal?

Ogni dato può essere manipolato in una richiesta HTTP.
Il problema non è la loro manipolazione, ma peggio, una perdita dei dati sensibili... ovvero violazione dei dati personali da parte di qualche utente malintenzionato.

Poi oddio, io ti sto allarmando per niente, non ti accadrà mai, ma prevenire è meglio che curare... e poi hai chiesto tu tecniche aggiuntive per 'mettere in maggiore sicurezza il tutto'.

[fabry78]

ah si certo, e ti ringrazio. Mi hai dato 2 input. Il primo riguarda la possibilità che due persone ordino contemporaneamente lo stesso prodottoe quindi sarebbe un problema, e l'altro la possibilità di inserire un certificato ssl se non ho capito male.

Per il primo problema che mi consigli? Si mette in attesa una richiesta sql?

Poi mi piacerebbe capire come implementare questo sistema di sicurezza ssl, sai indicarmi una guida?

[pabloski]

paypal offre gli script necessari se non sbaglio e quelli sfruttano ssl

[fabry78]

Paypal si, ma durante la gestione del carrello e l'invio dei dati del cliente sul mio database, non c'è paypal, io alla fine passo a paypal la somma totale e alcuni dati dell' utente,(come il nome , il cognome e il suo indirizzo email). La mia preoccupazione quindi è prima che si apra la pagina di paypal, non vorrei che i dati inviati via post o le sessioni vengano fossero manipolate in qualche modo.

[cionci]

https lo dovresti usare anche tu nelle pagine di checkout...
Le sessioni non te le può toccare nessuno, sono sul server.

[dojolab]

Originariamente inviato da fabry78

ah si certo, e ti ringrazio. Mi hai dato 2 input. Il primo riguarda la possibilità che due persone ordino contemporaneamente lo stesso prodottoe quindi sarebbe un problema, e l'altro la possibilità di inserire un certificato ssl se non ho capito male.

Per il primo problema che mi consigli? Si mette in attesa una richiesta sql?

Poi mi piacerebbe capire come implementare questo sistema di sicurezza ssl, sai indicarmi una guida?

Beh per il secondo niente di meglio SSLEngine su Apache2.
Basta che googli, trovi il mondo. Ricordati che i certificati ssl puoi generarli tu stesso con ssl-cert sul server, peccato che non essendo 'trust' quindi riconosciuti alcuni Browser (Firefox e Safari) 'avvisano' l'utente e quindi è sgradevole. I certificati SSL 'certificati e riconosciuti' (perdona il gioco di parole) costano dai 20 $ ai 1000 $ annuali; dipende sempre l'uso che devi farne.

Per il primo punto... o fai un lock sulle tabelle (il che ti obbliga di avere i permessi sul database, con l'utente, cosa non ideale) oppure ti crei una tabella temporanea dove metti ID prodotto, quantità virtuale. Punto. Quando la quantità virtuale (e la devi controllare ad ogni pagina dal checkout al pre-pagamento) è superiore alla disponibilità, procedi, altrimenti no.

Successivamente a pagamento completato aggiorni la quantità reale.

PS. Cionci l'SSL andrebbe usato ovunque, anche sul normalissimo modulo contatti

[nuovoUtente86]

Cionci l'SSL andrebbe usato ovunque, anche sul normalissimo modulo contatti

non vedo l' utilità di appesantire la computazione e l' overhead di rete, in sezioni non necessarie ovvero dove non passano dati sensibili.

[dojolab]

Originariamente inviato da nuovoUtente86

non vedo l' utilità di appesantire la computazione e l' overhead di rete, in sezioni non necessarie ovvero dove non passano dati sensibili.

Un modulo contatti non contiene dati sensibili?
Nome, Cognome, E-mail, TELEFONO, P.IVA e CF, sesso, indirizzo o altri dati non sono ritenuti dati sensibili o personai?
Forse bisogna rivedere il 'rango' dei dati riconosciuti come 'sensibili' e 'personali'.

Per me e per la legge Italiana lo sono.
Per te non lo so.

Che poi l'SSL appesantisca le connessioni, le renda più lente, ecc. è un altro conto; preferisco metterci 2 secondi in più a caricare una pagina che rischiare che i miei dati vengano passati in chiaro. Ma IMHO, questione di gusti e priorità.

[dojolab]

EDIT: lascerei però questo discorso a chi è ferrato in materia di Privacy.
SSL tutta la vita.

[!k-0t1c!]

A parte l'SSL che ti è già stato consigliato ti raccomando un modo per verificare che la sessione non sia manipolata. Nella fattispecie un modo molto sicuro di fare tutto sarebbe salvare nella sessione esclusivamente dei codici identificativi di prodotto. Al momento del checkout avresti così l'occasione non solo di verificare la disponibilità (pensa a due clienti che scelgono lo stesso prodotto, con disponibilità 1: solo il primo a fare il checkout dovrebbe avere l'occasione di arrivare al pagamento), ma anche di fare la somma effettiva dei prezzi senza temere manipolazioni da parte dell'utente; il tutto, naturalmente, essendo eseguito sul server, non comporterebbe particolari rischi.
In alternativa potresti sempre usare una forma di hashing (HMAC?) dei dati di sessione e verificare l'hash alla fine della procedura, anche se la soluzione è certamente meno sicura ed efficace.
Userei poi, fossi in te, uno strettissimo controllo su classici quali SQL injection e XSS, poiché un'SQL injection - ad esempio - consentirebbe ad un cliente malintenzionato di garantirsi uno sconto, mentre un'XSS potrebbe compromettere la sicurezza dei dati personali di un cliente legittimo e portare ad acquisti non autorizzati con tutte le conseguenze del caso.

[nuovoUtente86]

Le sessioni non te le può toccare nessuno, sono sul server.

teoricamente esiste la vulnerabilità dovuta al sessionid sniffing, ma neanche ciò giustifica un uso spasmodico di https.
Occorre invece garantire, lato server, che non possano verificarsi attacchi di tipo session riding

[nuovoUtente86]

Cionci l'SSL andrebbe usato ovunque

senza fare polemica, in italiano la parola ovunque ha un significato preciso.

Originariamente inviato da dojolab

Un modulo contatti non contiene dati sensibili?
Nome, Cognome, E-mail, TELEFONO, P.IVA e CF, sesso, indirizzo o altri dati non sono ritenuti dati sensibili o personai?
Forse bisogna rivedere il 'rango' dei dati riconosciuti come 'sensibili' e 'personali'.

Per me e per la legge Italiana lo sono.
Per te non lo so.

Che poi l'SSL appesantisca le connessioni, le renda più lente, ecc. è un altro conto; preferisco metterci 2 secondi in più a caricare una pagina che rischiare che i miei dati vengano passati in chiaro. Ma IMHO, questione di gusti e priorità.

Solitamente i moduli di contatto non hanno tale livello di dettaglio, implementato nei moduli di registrazione, che di norma viaggiano, questi si, su SSL

[dojolab]

Originariamente inviato da nuovoUtente86

senza fare polemica, in italiano la parola ovunque ha un significato preciso.

Solitamente i moduli di contatto non hanno tale livello di dettaglio, implementato nei moduli di registrazione, che di norma viaggiano, questi si, su SSL

Probabilmente non hai letto il topic sopra: la parole ovunque in Italiano, ha un significato ben preciso come sostieni tu, ma se ti fossi soffermato un solo secondo sul mio intervento avresti letto e capito che il mio ovunque si riferiva 'ovunque vi sia una comunicazione client - server in presenza di dati sensibili/personali' .

Per i moduli di contatto, dipende sempre dai casi.

Giusta cosa sulle sessioni.

[nuovoUtente86]

Coerentemente sarebbe opportuno far viaggire il sessionID (e di conseguenza tutti i messaggi HTTP) su un canale criptato, in quanto intercettando si ha pieno accesso alla sessione, con le conseguenze del caso, ma per motivi di performance nessuna web-application (anche delle note multinazionali dell' e-commerce) viaggia completamente su TLS

[cionci]

Originariamente inviato da nuovoUtente86

teoricamente esiste la vulnerabilità dovuta al sessionid sniffing, ma neanche ciò giustifica un uso spasmodico di https.
Occorre invece garantire, lato server, che non possano verificarsi attacchi di tipo session riding

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.