Gli URL casuali sono un modo sicuro per proteggere le foto del profilo?

71

Mi piacerebbe passare da ID utente sequenziali a casuali, in modo da poter pubblicare le foto del profilo pubblicamente, ovvero example.com/profilepics/asdf-1234-zxcv-7890.jpg .

Per quanto tempo gli ID utente devono impedire a chiunque di trovare le foto degli utenti per cui non hanno ricevuto il link?

16 lettere minuscole e da zero a nove forniscono una ragionevole complessità? Lo sto basando su 36 16 = 8x10 24 , una stima conservativa di 10 miliardi di account utente riduce lo spazio a 8x10 14 . A 1000 ipotesi / secondo, ci vorrebbero 25.000 anni per trovare un account. A meno che non trascuri qualcosa.

    
posta owenfi 18.05.2014 - 22:24
fonte

7 risposte

72

Dipende interamente da cosa intendi per "sicuro".

Se la tua unica preoccupazione è un URL di attacco degli hacker, allora 16 alfanumerici forniscono circa 8.000.000.000.000.000.000.000.000 di possibili indirizzi, il che è sufficiente per fermare l'ipotesi casuale, in modo che un utente malintenzionato abbia il 50% di possibilità di trovare una sola foto in un sito con un migliaio di utenti in un anno, avrebbero bisogno di fare 100 trilioni di tentativi al secondo, abbastanza traffico da far cadere anche qualcosa come Amazon o Google.

Ma ci sono altri modi per la perdita di URL: persone che inseriscono messaggi di posta elettronica o post di blog, web crawler che trovano pagine che non sono state protette adeguatamente e così via. Se hai davvero bisogno di proteggere qualcosa, devi metterlo dietro lo stesso tipo di sicurezza del resto del tuo sito web.

Personalmente, per creare URL difficili da indovinare, userei GUID / UUID. Lo spazio di ricerca è enormemente assurdo, non è necessario coordinare la generazione tra più server e la maggior parte delle lingue ha routine standard per gestirli.

    
risposta data 18.05.2014 - 23:33
fonte
24

Forse non è la risposta alla tua domanda, ma se vuoi "nascondere" la posizione delle immagini del tuo profilo su un sito web, puoi semplicemente incorporare l'immagine come URI dei dati. Puoi basare64 codificare l'immagine sul tuo server e incorporare la stringa sul tuo sito web, invece di esporre qualsiasi traccia immagine.

vedi link e link per una descrizione e una demo.

    
risposta data 19.05.2014 - 03:02
fonte
23

Dato che hai già selezionato Dropbox, penso che possiamo dare almeno una ragione per cui farlo è una cattiva idea:

Dropbox disabilita i vecchi link condivisi dopo le dichiarazioni dei redditi vengono pubblicati su Google

The flaw, which is reportedly also present on Box, impacts shared files that contain hyperlinks. "Dropbox users can share links to any file or folder in their Dropbox," the company noted yesterday while confirming the vulnerability:

Files shared via links are only accessible to people who have the link. However, shared links to documents can be inadvertently disclosed to unintended recipients in the following 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 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.

Fondamentalmente è troppo facile che gli URL perdano inavvertitamente, considerando il numero di utenti che li utilizzano. Se i tuoi utenti sono istruiti su questo ed evitano questi problemi, immagino che sia ragionevolmente sicuro, ma questa è una grande supposizione.

    
risposta data 19.05.2014 - 16:56
fonte
11

Le altre risposte sono generalmente buone, ma un'altra considerazione è il trasporto. Se stai usando un semplice http o qualsiasi altro protocollo non crittografato (o inviando gli url via email), tutti i dati che trasmetti e ricevi, compresi questi URL, dovrebbero essere considerati completamente pubblici dal punto di vista della sicurezza. Una grande porzione (chiunque abbia statistiche?) Degli utenti sono su punti di accesso Wi-Fi pubblici senza crittografia e l'url / scraping di tali reti è attivo.

    
risposta data 19.05.2014 - 14:43
fonte
7

Come già detto da altri, un URI per un'immagine specifica prima o poi si estinguerà, non importa quanto sia lungo o contorto. Se desideri limitare la visualizzazione agli utenti che hanno effettuato l'accesso, puoi utilizzare, ad esempio, .../image/profile.php?u=12345 per visualizzare l'immagine dell'utente 12345 senza un URI diretto alla foto disponibile per passare al pubblico in generale . Si presume che le persone a caso (non registrate) non ottengano nulla da profile.php. Nota che nulla impedisce ad un utente che ha effettuato l'accesso di salvare quell'immagine (specialmente se è memorizzata nella cache) e di passarla in giro. Ci sono cose che potrebbero essere fatte con le intestazioni di controllo della cache, ecc., O mettere l'immagine in Flash, o qualsiasi altra cosa, ma se un'immagine è visibile sul browser di qualcuno, con abbastanza lavoro sarà possibile afferrarla e salvarla.

    
risposta data 19.05.2014 - 19:27
fonte
5

Il problema con il tuo schema è che i numerosi utenti dei tuoi URL probabilmente non tutti suppongono che questi contengano informazioni sensibili. E parte di questo problema è che probabilmente non hai idea di quanto sia grande la base di utenti; per questi URL, gli utenti includono

  1. Le persone a cui pensi come utenti.

  2. I loro plug-in / addon / estensioni del browser.

  3. Quasi tutti i contenuti di terze parti sul tuo sito (annunci, analisi, plug-in sociali, ...) probabilmente, in un modo o nell'altro, informeranno terze parti degli URL in questione.

  4. Siti web apparentemente casuali che vedono l'URL come URL di riferimento (sai davvero quali curiosi collegamenti extra i tuoi utenti evocano nel tuo sito web tramite i componenti aggiuntivi del browser?)

Le prove empiriche indicano che gli URL https pubblicizzati come equivalenti a una password vengono indicizzati da Google, più volte, ad es. nel caso del portafoglio online Bitcoin privo di password Instawallet (nota che sono andati così in bancarotta da questo che non si sono nemmeno concessi un certificato SSL valido più.

    
risposta data 20.05.2014 - 17:11
fonte
2

Aggiungendo un paio di punti importanti come quelli che hanno risposto in precedenza sembrano essersi persi alcuni di loro.

  1. La probabilità di esporre inavvertitamente un URL è maggiore dell'esposizione di una password poiché le persone sono consapevoli che la password è sensibile.
  2. I siti Web di Facebook utilizzano URL CDN così complessi che nessuno può indovinare, ma da un punto di vista della sicurezza sembrano essere rischiosi poiché la revoca dell'accesso è impossibile quando l'utente modifica le impostazioni sulla privacy. Alcuni siti Web, compresi quelli con spazio di archiviazione del servizio Web Amazon nel back-end, utilizzano un URL firmato con un timestamp che verrà convalidato periodicamente.
  3. Cache di Google! È probabile che i motori di ricerca strisciano attraverso le immagini presumibilmente private. Fai una ricerca con i dork che riporterebbero solo i risultati dei CDN di Facebook e rimarrai sorpreso.
risposta data 16.10.2016 - 16:13
fonte

Leggi altre domande sui tag