Se voglio proteggere una stringa dalla modifica, è sufficiente salarla e cancellarla?

Questa tecnica può essere implementata in modo ragionevolmente sicuro. La vedrei come una tecnica avanzata per alte prestazioni: qualcosa che dovresti fare solo se sei sicuro di sapere cosa stai facendo. Se non hai bisogno di prestazioni elevate, è più semplice avere il server che convalida che l'utente è autorizzato per ogni richiesta. Detto questo, questo schema è in realtà abbastanza diffuso, specialmente quando un sito web dinamico passa a una rete di distribuzione dei contenuti.

Dovresti utilizzare HMAC per generare il tuo hash. Puoi usare HMAC con qualsiasi hash; per questo scopo SHA-1 è abbastanza adeguato. Tra le altre cose, questo ti protegge da Length Extension Attacks .

La soluzione più semplice è che l'hash contiene un segreto fisso del server e l'URL. Il problema con questo è che una volta che un utente ha un URL con l'hash, questo è valido per sempre. Non puoi revocare l'accesso di un utente a una particolare risorsa.

Possiamo parzialmente risolvere questo problema includendo un timestamp nell'URL. Quando generi l'hash, usa il timestamp corrente. Quando si verifica un hash, verificare anche che il timestamp sia entro un periodo che consideri accettabile (forse 24 ore). Esistono altri approcci per risolvere questo problema, come l'inclusione dell'ID di sessione dell'utente nell'URL, sebbene ciò richiederebbe una ricerca nel database per verificare l'hash.

Se dovessi risolvere questo, prenderei in considerazione la creazione di una variabile di sessione temporanea o di una voce di database (che è conservata lato server) e darebbe un URL generico al client dove quell'URL generico include la chiave di ricerca per il server URL laterale. L'URL generico determinerebbe la posizione corretta e reindirizza ad esso.

Dato che si indica che il browser con l'URL vero (o semplicemente modificandolo in qualcosa di simile) sarebbe un problema, un approccio migliore potrebbe essere semplicemente utilizzare gli URL monouso che si assegnano ai client: si mantiene URL reale inaccessibile attraverso le regole del server e si crea un collegamento che ottiene il client; quel collegamento viene ripulito quando non è più necessario.

La prima regola di crittografia è che non scrivi la tua crittografia personale. Hashing è criptato.

Vuoi garantire l'integrità e l'autenticità di un messaggio. Quello di cui hai bisogno è un Message Authentication Code (MAC). Vi consiglio di usare HMAC con un algoritmo di hash appropriato. Ci dovrebbe essere già una libreria o un modulo nella tua lingua con un'implementazione testata di HMAC-SHA1 o HMAC-SHA256, per esempio.

Il tuo primo metodo non è un sale. Un sale per definizione non dovrebbe avere alcun impatto sulla sicurezza se è trapelato. È per impedire l'inversione dell'hash, non per fornire sicurezza contro la falsificazione dell'hash.

Allo stesso modo, un hash stesso non prova nulla sul file a meno che non sia firmato in modo tale che la sua autenticità possa essere verificata. Quello di cui hai bisogno è una firma per l'URL che stai passando.

Mentre fondamentalmente ci sono altri problemi che rendono questo un modo non ideale di affrontare la situazione (e probabilmente ci sono altri problemi nel modello di sicurezza di conseguenza), puoi firmare l'hash o crittografandolo con una chiave privata in modo che possa essere verificata sia dal client che dal server o da una chiave simmetrica in modo che il client non sia in grado di produrre un hash falso perché mancherebbe della verifica dell'autenticità in quanto non potevano produrre un valore crittografato per l'hash.

Non creare il tuo sistema, usa un sistema esistente per firmare un valore se hai davvero bisogno di passare il valore attraverso il client e farlo rimanere inalterato. Preferibilmente, tuttavia, è necessario scrivere il proprio sistema in modo tale che il server possa tenere traccia dei valori che devono essere restituiti e collegare tutti questi valori ad un token di sessione che si scambia in modo sicuro con il client (come l'utilizzo di una sessione HTTPS ).

The browser will need to inspect the string and later send it back unmodified (aka request the resource that the URL is pointing to). If the browser could modify the string, it would be a security risk.

Sento che ti stai avvicinando al problema da un angolo sbagliato. Perché è un rischio per la sicurezza di un browser modificare l'URL? Questo è il lavoro del browser.

Se vuoi proteggere la risorsa verso cui punta l'URL, fallo sul lato server . Richiedere una forma di autenticazione prima che il server fornisca la risorsa richiesta al browser. Questo può variare da semplice autenticazione basata su sessione a schemi più complessi come OAuth. Fai la tua scelta.

È possibile memorizzare le risorse richieste in una posizione temporanea ma casuale nel filesystem e utilizzare tale URL per recuperarlo.

Considera i siti che ti fanno compilare un sondaggio per scaricare un particolare PDF. Spesso restituiscono un URL come link

Un modo per farlo è quando l'utente compila il sondaggio, genera un numero casuale, crea una cartella temporanea con quel nome, posiziona una copia della risorsa in quella cartella (in particolare, crea un collegamento simbolico alla risorsa in quella cartella), quindi restituire l'URL al client. Ogni 24 ore spazza la cartella dei white paper ed elimina ogni directory più vecchia di un giorno.

Questo risolve i tuoi problemi di persistenza e durata: usa il file system invece di un database. La pulizia è un lavoro cron. Fintanto che il numero casuale diventa abbastanza grande (ho visto siti che utilizzano GUID per questa attività), non sono accessibili. Non richiede nemmeno alcuna conoscenza di crypto, anche se consiglio sempre di usare un generatore di numeri pseudo casuali crittograficamente sicuro.