Protezione dell'URL accessibile anonimo con un segmento GUID?

Question

Protezione dell'URL accessibile anonimo con un segmento GUID?

#1 da (2 voti)
#2 da (0 voti)

4

Nel mio problema esiste un sistema esistente che funziona come un servizio di avviso o di ritaglio che esegue ricerche definite dall'utente e genera elenchi di risultati. Questi sono impostati dagli utenti autenticati e questo sistema interno utilizza un GUID come identificativo per recuperare i risultati, che sono memorizzati in un database.

È necessario esporre questi risultati tramite RSS. Tuttavia, a parte l'incorporamento di username:password@ nell'URL, non sono a conoscenza di alcuna tecnica che funzioni sui lettori RSS. L'idea ingenua è di rendere gli URL qualcosa come /alert/{guid}/rss che ha alcuni problemi. Dal momento che i GUID sono destinati all'unicità e non alla casualità, sono preoccupato di indovinare gli attacchi poiché ogni tentativo di indovinare potrebbe delegare la richiesta dal sistema Web al sistema interno e accedere al database. Sto cercando un modo per aggiungere un po 'di unicità all'URL e prevenire l'accesso al database non necessario, preservando la chiave basata su GUID.

Le mie idee sono di espandere l'URL /feed/{guid}/rss a qualcosa come /feed/v1/{hash}/{guid}/rss che contiene un segmento hash aggiuntivo. Questo segmento verrebbe generato combinando il guid esistente e un'applicazione fornita segretamente tramite concatenazione o XORing o qualcosa del genere? Questo sarebbe l'URL che verrebbe fornito ai lettori RSS dall'interno dell'applicazione. Quindi, quando un URL arriva nel sistema, il segmento hash può essere ricalcolato in memoria, confrontato e rifiutato senza un intervento al servizio interno e al database. Il principale segmento /feed/ dell'URL è univoco nel sistema per consentire il futuro routing / bilanciamento degli URL alla cache del feed. Il segmento /v1/ è attivo se il segreto deve cambiare per gli URL dei feed futuri.

Poiché non voglio essere un'altra prova per "Legge di Schneier" , quali sono i problemi con questo modello? Penso che sia d'aiuto con il denial-of-service per gli attacchi di forza bruta (ma non se è noto almeno un URL valido). Penso anche che crei URL "casuali" per la sensibilità dei dati. Sono aperto a critiche o altre idee, ma sono bloccato con le chiavi basate su GUID.

rest brute-force denial-of-service

posta Kevin Hakanson 21.11.2012 - 19:56

fonte

2 risposte

Leggi altre domande sui tag rest brute-force denial-of-service

Guida alla comprensione di PCI-DSS quando si utilizza la crittografia basata su password da chiavi generate automaticamente Hai bisogno di aiuto per comprendere il codice offuscato nell'exploit CVE-2012-4969

score 2 · Answer 1

La soluzione di base è codificare una password semi-pubblica con un unico scopo nell'URL. In genere la soluzione ha un aspetto simile al seguente:

http://<base>/<content_identifier>/<auth_identifier>/<random_password>

Quindi <base> e <content_identifier> sono quelli che vuoi; fanno in modo che l'URL punti a qualcosa per il tuo sito. < auth_identifier> punta a un token di autenticazione corrispondente nel tuo database che indica chi ha autorizzato questo URL, ecc. Il bit <random_password> è lì per garantire che l'URL non possa essere indovinato. È semplicemente casuale. Il token di autenticazione nel DB memorizza la password casuale corretta. Dovresti poter revocare o scadere vecchi URL aggiornando (o eliminando) il token di autenticazione nel tuo database. Dovresti anche essere in grado di emettere un URL univoco aggiuntivo dopo che una precedente è stata revocata (o forse allo stesso tempo di un'altra). È difficile farlo se il tuo segreto è un hash, dal momento che esiste una sola risposta corretta e quindi un URL corretto.

Se sei preoccupato per i segreti, puoi crittografare i dati prima di pubblicarli in un URL e decrittografarli prima di elaborarli. In genere questo è eccessivo, ma tutto dipende dai dati che stai esponendo.

Nota che la tua idea di codificare informazioni sufficienti nell'URL per renderlo verificabile senza il database significa che il contenuto del database non può influire sulla validità dell'URL. In particolare, non puoi revocarlo. Spesso questa restrizione si rivela problematica lungo la strada.

score 0 · Answer 2

La mia prima idea è semplicemente generare un valore casuale di 16 byte usando un PRNG sicuro e utilizzarlo al posto di un GUID generato dal sistema. Questo dovrebbe essere un calo nella sostituzione di un GUID (nessun cambio di protocollo :) e dovrebbe essere sicuro fino a quando l'url non perde.

Anche il tuo dovrebbe essere sicuro, se usi un MAC come HMAC-SHA-2 (essenzialmente un hash con chiave). Non utilizzare uno schema di combinazione ad hoc, utilizzare HMAC che è standard e sicuro.