L'uso di GUID per gli ID rende gli ID imprevedibili?

Supponiamo che si stiano utilizzando tecniche di crittografia / crittografia sufficienti per soddisfare PCI DSS.

No, stiamo osservando un problema astratto di qualcuno che può prevedere un valore. Il fattore di rischio è che se il valore può essere indovinato o segue uno schema noto, si può quindi cancellare a volontà.

Il problema del GUID è irrilevante, perché il vettore di attacco è ancora un attacco di forza bruta. Pur conoscendo il modello o gli algoritmi utilizzati per creare il tuo ID univoco può certamente aiutare a ridurre le possibilità di un attacco limitato da un dizionario, la conoscenza degli ID in anticipo non è necessaria per eliminare i record indiscriminatamente.

Affrontare il problema implementando controlli aggiuntivi. Innanzitutto, se si trova in un database, si dispone di registrazioni e transazioni sufficienti.

Sulla strada per eseguire la cancellazione, dovrebbero essere disponibili controlli aggiuntivi. Iniziamo dal lato utente: se il record è associato all'utente, solo l'utente dovrebbe avere la possibilità di cancellare i propri record. Se l'utente non è autenticato o non possiede i record, non consentire che la procedura di cancellazione continui in avanti. L'utente deve fornire un'autorizzazione speciale? Un'altra variabile è impostata nel database o in una sessione per consentire l'eliminazione (ad esempio, è necessario autorizzare prima che l'azione vada in porto?) Se c'è un rischio sufficiente, è possibile implementare una conferma fuori banda, come inviare un È accettabile un messaggio SMS o forse una conferma via email. In questo scenario, il suo rischio è probabilmente basso se un utente cancella deliberatamente i propri record di carte di credito perché possono inserirli di nuovo in seguito.

Se disponi di controlli di autenticazione, autorizzazione e transazione affidabili, limiterà la possibilità di eliminare indiscriminatamente i valori, anche se sono noti.

Come ulteriore precauzione, potresti voler implementare l'euristica e gli algoritmi di rilevamento degli attacchi. Ad esempio, limitare il numero di eliminazioni dallo stesso indirizzo IP al giorno. Rollback delle transazioni se ci sono troppe cancellazioni in un dato giorno considerando i normali pattern di cancellazione, ecc.

Sembra che dalla tua descrizione sia stato eseguito un semplice comando POST, vorrei assicurarmi che ciò avvenga solo se c'è TLS / SSL, l'utente è autenticato, c'è un token CSRF nella richiesta, ecc. Garantirei che tutto le cancellazioni sono registrate e possono essere ripristinate. Poiché la cancellazione non comporterebbe un'esposizione, puoi anche fare affidamento su una notifica post-azione per gli utenti: "Confermiamo di aver cancellato la tua carta di credito in archivio. Se non l'hai fatto, ti preghiamo di contattarci immediatamente" ecc. / p>     

Un GUID è una sequenza di 128 bit, che segue uno specifico formato e regole di generazione che mirano a garantire unicità . Questa non è la stessa cosa di imprevedibilità . Tra i 5 metodi di generazione standard (chiamati "versioni"), solo la versione 4 può affermare di essere imprevedibile, e solo nella misura in cui usa un PRNG crittograficamente sicuro ; in queste condizioni, ottieni 122 bit casuali, il che è sufficiente per la maggior parte degli scopi che richiedono imprevedibilità.

Quindi il metodo esatto che usi per produrre il tuo GUID conta molto.

Sembra che il rischio di cui parli sia comunemente noto come falsificazione di richieste cross-site ( "CSRF"). Esistono meccanismi comuni e collaudati per affrontare questa classe di vulnerabilità, e spesso anche librerie prefabbricate che puoi semplicemente includere nel tuo codice (e molti framework hanno integrato la protezione CSRF!).

Una volta aggiunta la protezione CSRF alla tua applicazione, non importa quale ID hai associato al record; potresti semplicemente numerarli in sequenza come fanno tutti noi.

Inoltre, tieni presente che, sebbene tu abbia notato la potenziale vulnerabilità su questa particolare pagina, ci sono probabilmente dozzine di altre posizioni nel tuo codice in cui si applicano gli stessi avvertimenti. È meglio trattarli tutti insieme con un'unica soluzione condivisa che cercare di pulire ogni modulo in modo indipendente.

E per rispondere alla tua domanda iniziale: no . I GUID sono solo un formato per identificatori presumibilmente univoci. Da dove proviene l'ID è fino all'implementazione. Esistono diversi meccanismi comunemente utilizzati per generare nuovi GUID, alcuni dei quali sono prevedibili e alcuni meno. Ma in genere non sono numeri casuali con crittografia corretta.

No, per favore non farlo !! Se la tua randomizzazione si basa su un fattore prevedibile come il tempo (cioè pseudo-casuale), o c'è qualche altro tipo di bug / perdita di informazioni che consente di individuarlo. Assicurati invece che l'utente autorizzato sia autenticato prima di consentire l'esecuzione di tali query.

O meglio ancora, non conservare le carte di credito da soli, affidarsi a una terza parte come PayPal per eseguire tali elaborazioni finanziarie per conto dell'utente.