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.