Riepilogo: Gli URL di capacità sono molto più sicuri di quelli a cui danno credito.
Questi tipi di URL sono comunemente noti come capacità / URL segreti.
Non ha senso parlare di sicurezza senza specificare un modello di minaccia. Ecco una coppia che ti viene in mente:
Per quanto riguarda gli attacchi di rete (1 e 2), gli URL segreti sono perfettamente sicuri , a condizione che tu stia utilizzando HTTPS (è il 2016, non dovresti più utilizzare HTTP!).
Mentre il nome host di un server viene inviato in chiaro sulla rete, l'URL effettivo viene crittografato prima di essere inviato al server, poiché fa parte della richiesta GET, che si verifica solo dopo il TLS stretta di mano.
Per quanto riguarda il shoulder-surfing (3), un URL segreto con abbastanza entropia è ragionevolmente sicuro contro un attacco casuale · Ad esempio, fornirò un URL di google doc:
https://docs.google.com/document/d/5BPuCpxGkVOxkjTG0QrS-JoaImEE-kNAi0Ma9DP1gy
Buona fortuna a ricordarlo mentre passi dallo schermo di un collega!
Ovviamente, se l'attaccante ha una fotocamera e può scattare una foto senza essere notato, è una questione completamente diversa - non dovresti utilizzare un URL segreto in quella situazione.
Per quanto riguarda un utente malintenzionato con privilegi elevati sul tuo computer (4), un URL segreto non è meno sicuro di una lunga password o persino un certificato TLS sul lato client - poiché tutti questi sono in realtà completamente insicuro, e non c'è molto che tu possa fare al riguardo.
Un utente malintenzionato con privilegi regolari (5), d'altra parte, non dovrebbe essere in grado di apprendere l'URL segreto, purché si seguano buone pratiche di sicurezza per il proprio sistema operativo . I tuoi file (in particolare la cronologia del browser) non dovrebbero essere letti da altri utenti.
Per proteggere le chiavi API (6, che era il punto di questa domanda), anche un URL segreto non è meno sicuro di un altro meccanismo (come un POST AJAX) . Chiunque abbia un utilizzo per una chiave API saprà come utilizzare la modalità di debug del browser per ottenere la chiave.
Non è ragionevole inviare a qualcuno un segreto e aspettarsi che non lo guardino!
Alcune persone hanno chiesto informazioni sui rischi sul lato server.
Non è ragionevole trattare i rischi lato server con la modellazione delle minacce; dal punto di vista dell'utente, devi davvero trattare il server come terze parti attendibili , come se il tuo avversario avesse accesso alla rete interna sul lato server, non c'è davvero nulla che tu possa fare (molto simile ad un aggressore privilegiato sul computer del client, ad esempio il modello di minaccia 4 sopra).
Invece di modellare gli attacchi, descriverò rischi comuni di esposizione segreta non intenzionale .
Il problema più comune relativo all'utilizzo di URL segreti sul lato server è che sia server HTTP che proxy inversi conservano i log e l'URL è molto spesso incluso .
Un'altra possibilità è che gli URL segreti possano essere generati in modo prevedibile - a causa di un'implementazione imperfetta, di un
Ci sono anche molte avvertenze che devono essere prese in considerazione quando si progetta un sito che utilizza URL segreti. Questa pagina di W3C TAG copre molti di questi.
In pratica, per i siti con contenuto dinamico, è abbastanza difficile ottenere tutto in modo sicuro, sia Google e Dropbox l'ha reso obsoleto in passato, come indicato su questa risposta
Infine, gli URL segreti hanno un paio di vantaggi rispetto ad altri metodi di autenticazione :
Dipende da come deve essere usata quell'API e dal tipo di dati che sta accedendo. Qualcosa che accede a google maps (per esempio) è molto più a rischio di qualcosa che accede ai dati bancari.
Ovviamente una chiamata come quella nel codice lato client non è sicura, l'utente può facilmente imparare la tua chiave API.
Se la chiamata API viene effettuata da server a server, allora è meno di un problema.
L'utilizzo di HTTP lascerebbe aperta la connessione alle intercettazioni, HTTPS rimuove il problema.
Un altro problema con le chiavi nell'URL è che l'URL completo finisce nei file di registro. Questo espande la superficie di attacco per l'app, poiché ora ci sono più posti dove cercare la chiave.
Per rispondere alla tua domanda, non è che le chiavi di passaggio nell'URL siano intrinsecamente insicure, piuttosto che siano meno sicure delle alternative e non delle migliori pratiche. Supponendo che l'API non stia accedendo a qualcosa di sensibile, la connessione sia su HTTPS e la chiamata sia effettuata da server a server, dovrebbe essere "abbastanza buono" per i servizi a basso rischio.
Non è una buona idea passare segreti come parametri GET in generale. Ho compilato un elenco sul mio blog un po ' fa sui potenziali problemi di sicurezza:
I segreti possono trapelare ad altre parti come segue:
Dal tuo computer / smartphone
sul lato server
A terze parti
Referer Alcuni di questi non sono applicabili alle richieste Ajax, ma ymmv
Mi chiedo perché nessuno menzioni esplicitamente il rischio di fissazione della sessione e vulnerabilità CSRF. Naturalmente puoi mitigarli aggiungendo i token CSRF e implementando la gestione sicura delle sessioni, ma ciò implica che hai effettivamente il controllo sul codice pertinente.
Poiché questa domanda ha il titolo A secret in a URL alcune persone potrebbero giungere alla conclusione che è sufficiente se implementano alcune misure di attenuazione attorno invece di vederlo come possibile vettore di attacco che può essere evitato.