Generazione di URL una tantum che possono essere revocati

Sembra che tu abbia una buona idea di quello che stai facendo.

Il pattern di link monouso è piuttosto comune per cose come la verifica della posta elettronica. In genere, si memorizza la data di scadenza in un database e / o si utilizza una stringa firmata nell'URL che include la scadenza nella stringa da firmare. Queste sono solo precauzioni per evitare di fidarsi dell'input dell'utente.

Se vuoi essere veramente accurato, puoi inviare loro l'ID casuale o l'URL del token e quindi memorizzare un hash nel database per evitare che qualcuno usi il token se hai una violazione dei dati.

Sei piuttosto vago sul contesto dei parametri crittografati AES proposti. Di solito includo informazioni sensibili che non sono richieste per il routing URL nel corpo di un messaggio, invece dell'URL. In questo modo, non appare nei registri del server web o del proxy. I dati crittografati con AES potrebbero anche spingerti oltre il limite di lunghezza dell'URL abbastanza velocemente, a seconda di quanto è grande il contenuto in testo in chiaro.

Modifica: per completezza, Azure I token SAS di archiviazione sono un ottimo esempio di un metodo crittografico che non richiede record di database ed è revocabile. La revoca avviene modificando la chiave API del servizio ... che revoca i token tutti emessi dalla stessa chiave.

Dato che non ho molte informazioni sul sistema in uso, Consiglierei la ricerca del database più semplice, su qualsiasi soluzione che richieda misure sofisticate crittograficamente.

Inoltre, affinché i metodi di crittografia funzionino come un collegamento singolo, alcuni parametri noti al servizio e inclusi nell'URL devono essere modificati quando viene utilizzato il collegamento. Questo parametro non deve necessariamente essere una ricerca nel database, ma è necessario apportare una modifica permanente. Ad esempio, se il link è un URL di caricamento singolo, la presenza di un file nella directory di caricamento potrebbe invalidare l'URL.

Infine, il valore memorizzato nel database è più semplice in quanto esiste una sola fonte per verificare la validità. Con la soluzione senza database, è necessario controllare il segreto (ad esempio la chiave di crittografia) e anche qualsiasi fattore invalida il collegamento dopo il primo utilizzo.

Utilizzare la crypto simmetrica per un parametro URL ti darebbe un vantaggio: elimina la necessità di eseguire una ricerca nel database. Il rovescio della medaglia è che si introduce un segreto (la chiave di crittografia) che è necessario proteggere e mantenere. Poiché dovrai comunque eseguire la ricerca del database per verificare lo stato della revoca, non avrai alcun vantaggio. Quindi vorrei andare per l'approccio n. 1.

Assicurati di utilizzare ID sufficientemente lunghi: s e generali con un CSPRNG. E come dice nbering , assicurati di cancellarli (senza sale) per proteggerti in caso di violazione.

I giganti del software come Google utilizzano un metodo di URL firmati

La premessa è semplice, si invia una richiesta con una stringa crittografata che corrisponde al lato non criptato della query. Quindi tutto ciò che devi fare è decodificarlo sul server.

Ad esempio

example.com?file=file.ext&time={unixtimecode}&{encryptedstringthatmatchesfileandtimestamp}

L'uso della chiave di crittografia serve a garantire che il server / qualcuno con accesso alla chiave abbia fatto la richiesta che un utente può seguire per un certo periodo di tempo e che la richiesta non sia stata manomessa. Revocare la stringa potrebbe essere semplice come cancellare una chiave di crittografia temporanea, il che significa che il server non sarebbe in grado di decifrare la richiesta, anche se è stata memorizzata nella cache.