Il token URL casuale è sufficientemente sicuro per gli allegati di file e altri contenuti utente? [duplicare]

Anche se fornisce sicuramente un certo grado di sicurezza, ti lascia comunque un certo numero di falle nella sicurezza che possono o meno dipendere dal tipo di applicazione che stai sviluppando. Per un elenco non esaustivo:

• Il contenuto potrebbe essere limitato a un gruppo selezionato di utenti, cosa succede se uno di questi perde l'URL?

• Gli URL con i parametri GET sono memorizzati in un numero elevato di posizioni, ad esempio la cronologia web

• A volte capita di avere dei problemi principali quando google esegue la scansione di cose a cui non sono destinati, ad esempio instawallet fiasco .
• Le vulnerabilità della sicurezza in altre parti del tuo sito potrebbero esporre i link e, senza ulteriore protezione, verranno esposti.

Se fossi in te, vorrei implementare ulteriore sicurezza legando i file a specifiche persone / gruppi che potrebbero essere in grado di accedervi e confermare la loro sessione prima di pubblicare il contenuto.

L'uso di lunghi token casuali come segreti per fornire l'accesso a un file può fornire una sicurezza efficace. Consiglierei 128+ bit per renderlo veramente al di fuori della portata di ipotesi casuali. Probabilmente potresti farcela con meno bit, specialmente se consideri IP limite basandoti su ipotesi sbagliate. Ad esempio, se avessi un token a 64 bit o 80 bit e un miliardo di tali file e venissi attaccato da una botnet con un milione di indirizzi IP distinti che ognuno potrebbe tentare ogni 10 ipotesi ogni 10 minuti - ad esempio hai bandito un IP per 10 minuti dopo 10 tentativi errati, sarebbero necessari circa 12 giorni (token a 64 bit) o 2300 anni (token a 80 bit) per trovare un singolo file casuale.

Tuttavia, per fare ciò in modo sicuro, è necessario tenere presente alcuni avvertimenti:

1. Utilizza HTTPS. Gli intercettatori della rete possono vedere (o alterare segretamente) qualsiasi traffico su HTTP.
2. Se il documento ha collegamenti ad altre pagine Web e un utente fa clic sui suddetti collegamenti, il server Web all'altra estremità vedrà generalmente un'intestazione Referer HTTP nella richiesta HTTP che fornirà l'URL completo (compresi eventuali segreti; questo è anche se il segreto si trova in un parametro di query come link ) e continuerà a verificarsi se l'utente è in modalità di navigazione privata .
3. Probabilmente il token casuale può essere memorizzato nella cronologia del browser del tuo computer (a meno che non esplori in modalità privata e termini la sessione).
4. Alcuni motori di ricerca prendono il tuo token casuale e lo indicizzano.
5. Il meccanismo per informare l'utente della chiave potrebbe farlo trapelare a terzi. L'email è potenzialmente scambiata in chiaro e se si utilizza un provider di posta elettronica di terze parti la chiave segreta è accessibile agli amministratori di quel provider di posta elettronica. Molti utenti salvano anche la posta elettronica in chiaro sul proprio computer con un disco non crittografato (ad es. Il disco rigido può essere rimosso o qualcuno si avvia in un cd live per leggere il contenuto del disco) o lascia il computer connesso al proprio account di posta elettronica.

Il problema 4 può essere evitato di solito mantenendo un robots.txt e proibendo una directory.

User-Agent: *
Disallow: /private/

È possibile attenuare i problemi 2 e 3 richiedendo all'utente di richiedere il proprio documento tramite POST HTTP (su HTTPS). Quello è invece di fare clic su un collegamento come:

<a href="https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw">File</a>

Potresti fare qualcosa di simile a incorporare quanto segue in un'email HTML:

<p> Click the button below to get your file:
<form action="https://example.com/private_file/" method="post">
  <input type="hidden" name="token" value="LfliQdgOAkjs9H0Oi5ZZcw">
  <input type="submit" value="Get File">
</form>
<p>Or go to https://example.com/private_file/ and cut and paste the token <pre>LfliQdgOAkjs9H0Oi5ZZcw</pre>.

Ciò impedirebbe al segreto di apparire nella cronologia del browser o di ricevere link di referer (poiché l'URL sarebbe semplicemente https://example.com/private_file/ ).

In alternativa, puoi consentire i link del modulo https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw , ma poi reindirizzare l'utente a un altro URL quando in realtà serve il https://example.com/private/document privato. Ciò eviterebbe il problema n. 2 con le intestazioni di Referer, ma potrebbe comunque lasciare il link nella cronologia del browser.

Questi tipi di domande vengono di volta in volta.

Essenzialmente, questa è sicurezza per oscurità .

Il fatto che sia difficile indovinare affronta solo un tipo di problema. Non protegge da:

• Gli utenti condividono il link accidentalmente, aggiungendo ai segnalibri il link, ecc.
• L'utente digita accidentalmente l'url in Google o in un altro motore di ricerca, con conseguente indicizzazione.
• Monitoraggio esterno o intercettazione del traffico di rete, memorizzazione nella cache

Potresti essere interessato a questo esempio con DropBox e simili di alcuni anni fa:

The vulnerability was discovered by cloud-based file locker Intralinks in a Google AdWords campaign in which its services are advertised using keywords that identify its competitors, which in this case are Box and Dropbox. The vulnerability exists when users share files via share links, which are then subsequently inserted into the search box (as opposed to the URL bar) in their browsers; this allowed Intralinks to collect the data in the AdWords campaign management interface.

In the same fashion, users are vulnerable to a slightly different attack that involves the relay of HTTP Referrer headers, as Dropbox outlines in this example scenario:

A Dropbox user shares a link to a document that contains a hyperlink to a third-party website. The user, or an authorized recipient of the link, clicks on a hyperlink in the document. At that point, the referrer [sic] header discloses the original shared link to the third-party website. Someone with access to that header, such as the webmaster of the third-party website, could then access the link to the shared document. In the same post, Dropbox notes that the problem with the search box is "well known and we don't consider it a vulnerability." Ultimately, the only protection that the shared files have is that they are difficult to get to, requiring an exceptionally long URL to access — in effect, security through obscurity.

Mettere una foto davanti a una cassastrong non è la stessa cosa che bloccare la cassastrong ...

Sembra che tu stia cercando di evitare l'implementazione dell'autenticazione reale. Potresti voler implementare il controllo degli accessi reale (autenticazione e autorizzazione) e qualcosa come la gestione dei diritti delle informazioni.

Per lo meno si potrebbe chiedere codice, token o identificatore quando il file viene caricato come gateway prima di fornire l'accesso. Ad esempio, si invia il collegamento via e-mail e possono accedere al file effettivo solo dopo aver inserito nuovamente l'e-mail. Fornisce una certa protezione contro l'indicizzazione accidentale, ma non in altri casi.