Le richieste GET segrete possono essere forzate brute? [duplicare]

Stai essenzialmente chiedendo se è sicuro passare i parametri segreti in una richiesta GET. In realtà questa è classificata come vulnerabilità . Non è possibile forzare una stringa pseudocasuale sufficientemente lunga, supponendo che il server restituisca semplicemente una risposta statica 404 ogni volta che viene specificato un percorso non valido, ma in pratica vi sono numerosi altri problemi di sicurezza che rendono questa tecnica pericolosa:

• Il software di registrazione registra spesso richieste GET in testo semplice, ma non POST.

• L'utilizzo di GET rende CSRF banale ^* durante l'elaborazione del contenuto attivo.

• Le intestazioni di referer possono far filtrare valori segreti ad altri siti web.

• La cronologia del browser manterrà i segreti passati nelle richieste GET.

Il tuo secondo esempio ha /admin/ in esso. Ciò implica che la conoscenza di questo percorso da sola sarebbe sufficiente per autenticare il server in un contesto di amministratore. Questo è molto insicuro e non dovrebbe essere più fatto di /?password=hunter2 , una maggiore sicurezza web faux pas .

Invece, i segreti dovrebbero essere inviati in una richiesta POST. Se questo non è possibile o se il tuo modello di minaccia è esclusivamente per impedire la forza bruta dell'URL (ad esempio, i link di reimpostazione password che vengono prontamente invalidati dopo l'uso), allora dovrebbe essere sicuro se fatto con attenzione. Non sono a conoscenza di attacchi di canale laterale che forniscano un metodo per ottenere la stringa più veloce della forza bruta.

_{* Evitare richieste GET parametrizzate non impedisce gli attacchi CSRF, che è un malinteso comune in quanto vi sono vari modi per abusare in modo simile di POST (forme false, ecc.), ma il passaggio di segreti in GET rende CSRF più semplice.}

Questo è un approccio comune per condividere le cose pubbliche riservate a coloro che conoscono l'URL. Un esempio è Google Documenti:

Lasecondaopzione,"Chiunque abbia il link", crea un link simile al tuo. Lo stesso vale per Google Foto, Dropbox, ...

• Il vantaggio è che la diffusione del contenuto è un po ' limitata.
• Lo svantaggio è che questo un po ' dipende da chi condividi il link, dove è pubblicato, ecc.

Una cosa che dovresti considerare è la possibilità di invalidarla facilmente (cambiando / rigenerando il link ai tuoi dati)

Pessima idea. Un numero di volte in cui ho visto un URL "segreto" che ha ottenuto molto rapidamente il crawler dei motori di ricerca e quindi è stato individuato dalla ricerca web. Una volta ho persino visto qualcuno creare una copia di un sito web rispettabile in una sottocartella del suo dominio, condividerla con una persona una , e presto è stato inviato via email un avviso che lo avvisava che il suo dominio potrebbe essere stato compromesso per scopi di phishing.

Come è successo? In quest'ultimo caso, il browser Web aveva una funzione anti-phishing integrata che inviava gli URL visitati ai servizi di rilevamento delle frodi. Negli altri casi, forse il browser stava raccogliendo dati di navigazione e inviandoli a un motore di ricerca per raccogliere le abitudini degli utenti.

Se fai questo , assicurati che il tuo robots.txt (o header / meta tag) sia impostato per indicare ai motori di ricerca di non indicizzare il contenuto.

Internet è un modo meraviglioso per avvicinare il mondo, ma sfortunatamente offre a tutti l'accesso potenzialmente permanente a qualsiasi cosa tu stia sbagliando.

If the secret part of the path is quite long [...] it'll be hard to guess or brute force it?

Sì. Un utente malintenzionato dovrebbe indovinare l'intera cosa per scoprirlo. Dal momento che ci sono molte possibilità, ci vorrebbe una quantità di tempo improponibile.

What are the issues with this approach in general?

Il problema con questo è che gli URL non sono considerati segreti, quindi verranno memorizzati nel browser, nei registri e da eventuali proxy intermedi. In questo modo, il tuo URL "segreto" potrebbe essere esposto.

Using GET makes CSRF trivial when processing active content.

No. In un attacco CSRF, l'attaccante forgia una richiesta specifica. Quando si utilizza un segreto nell'URL, l'utente malintenzionato non conosce nemmeno l'URL corretto a cui creare la richiesta. Ciò significa che CSRF è impossibile finché l'URL è segreto.

Come altri hanno affermato, questa non è una buona idea. Tali link "segreti" che vengono utilizzati per annullare l'iscrizione o simili scopi una tantum sono in genere relativamente di breve durata e inutili una volta che sono stati utilizzati una sola volta.

Il mio pensiero iniziale quando ho letto questa domanda era che l'url non sarebbe rimasto segreto a lungo. Ho pensato che forse Chrome (o qualsiasi altro browser web moderno) avrebbe utilizzato i dati dalla riga di indirizzo per inizializzare una scansione. Si scopre che non lo fanno . Tuttavia, i ricercatori hanno scoperto che i plug-in potrebbero ancora attivare una scansione:

The results are pretty simple: Googlebot never came to visit either page in the test.

As it turns out, two people in the test did not actually disable their extensions, and this resulted in visits from Open Site Explorer (someone had the Mozbar installed and enabled) and Yandex (due to a different person, though I’m not clear on what extension they had installed and enabled).

Questo significa che una volta utilizzato un collegamento, potrebbe essere compromesso dalle estensioni del browser. E poi non c'è bisogno di forzare brutalmente nulla.

Qual è lo scopo alla base di questi collegamenti? Cosa stai cercando, OP, di raggiungere? Sono certo che ci sono altri modi per arrivarci ...

Sarebbe difficile indovinare / bruteforce ma altri modi per ottenere i percorsi potrebbero essere possibili

Ad esempio, l'url può essere indicizzato da servizi come google, bing, ecc. Ciò renderebbe il tuo URL "segreto" apparire quando un utente cerca la tua pagina in google. Può essere risolto configurando il file robots.txt , ma ricorda che gli indicizzatori potrebbero ignorarlo

I link nell'applicazione possono reindirizzare al percorso nascosto

Inoltre, le macchine nella stessa rete dell'utente che accede alla pagina "segreta" o al server web possono vedere l'url, anche ogni proxy intermedio e l'ISP dell'utente (o VPN se ne usa uno)

Infine, l'url può essere persistente nella cache e / o nella cronologia del browser e nei log sul server web e sui proxy

Can secret GET requests be brute forced?

Sì, possono. Tanto quanto qualsiasi tipo di richiesta senza adeguate misure di sicurezza.

If the secret part of the path is quite long, can I assume that it's safe to have such a secret page or area, and it'll be hard to guess or brute force it?

No, non è sicuro avere una pagina o un'area così segrete. Sì, sarà difficile indovinarlo o forzarlo.

What are the issues with this approach in general?

Diversamente dalle richieste POST, le richieste GET possono essere facilmente trovate nella cronologia del browser web.

Penso che sarà meglio implementare un manuale o automatico (quindi deciderete chi può accedere alla pagina) OTP One Time Password per inviare via email.

In uno scenario manuale:
 - ricevi la richiesta da [email protected]
 - concedi l'accesso a [email protected]
 - lo script crea il collegamento con l'OTP
 - il collegamento verrà inviato per [email protected]
 - quando l'utente [email protected] visiterà la pagina, l'OPT verrà contrassegnato e nessun altro potrà riutilizzare quel link

ovviamente questo sistema richiede un database in cui memorizzare l'e-mail, OPT e campo flag autorizzati