Domanda:
Un sito web pubblicato in una directory oscura è relativamente sicuro per essere posizionato dietro un login?
CodeMoose
2015-05-13 01:14:09 UTC
view on stackexchange narkive permalink

Supponiamo che crei un microsito per un cliente che contiene informazioni aziendali riservate. Dobbiamo posizionarlo in una posizione a cui il cliente può accedere, in modo che possa approvare il lancio.

Se posizioniamo questo microsito dietro un accesso, abbiamo la garanzia che nessuno può semplicemente imbattersi nel contenuto e comprometterlo. Ma cosa succede se lo pubblichiamo in una directory segreta e non indicizzata con un nome della stessa "forza" della suddetta password? Per amor di discussione, "non divulgato e non indicizzato" significa che non verrà collegato manualmente o automaticamente a / da qualsiasi luogo o indicizzato da qualsiasi ricerca sul sito web sullo stesso dominio. Inoltre, non verrà inserito nel proprio sottodominio, quindi la scansione DNS non è un problema.

Il mio istinto iniziale dice che si tratta semplicemente di sicurezza per oscurità ed è molto meno sicuro a causa del possibilità che qualcuno ci inciampi. Ma, dopo averci pensato, non ne sono così sicuro. Ecco la mia comprensione:

  • Anche usando una stringa di due parole debole nel dizionario sia per la password che per l'URL, ci sono ancora miliardi di opzioni indovinabili. Inserendolo nell'URL non si riduce magicamente tale elenco.
  • Le pagine di accesso possono avere una protezione dalla forza bruta, quindi un utente malintenzionato otterrebbe ottimisticamente 20 tentativi di indovinare. L'individuazione dell'URL dovrebbe essere rilevata dal DoS del server o dalla protezione antispam e potrebbe consentire 200 ipotesi che producono 404 se si prevede un attacco, ancora non statisticamente significativo per miliardi di opzioni.
  • La pagina di accesso è collegato da un sito Web: è un muro visibile su cui un utente malintenzionato può battere. È la prova che esiste qualcosa per cui vale la pena attaccare. Indovinare l'URL, tuttavia, è cieco. Richiede di trovarsi nel dominio (e sottodominio) corretto e di operare nella certezza che, anche dopo decine di migliaia di ipotesi errate, si troverà comunque qualcosa.
  • L'URL ha un'ulteriore suscettibilità di essere indicizzato / sottoposto a spider esternamente. Tuttavia, la maggior parte degli spider rispettabili non "indovina" nei siti, seguono solo i collegamenti. Un ragno maligno "indovinare" verrebbe catturato dalla stessa protezione DoS / spam del punto 2.

Da quello che posso dire, l'unica differenza significativa tra i due è la tranquillità immaginaria. La possibilità che l'URL possa essere inciampato rende le persone nervose e il login rende le cose sicure, nonostante sembrino comparabili in base ai punti sopra. Tuttavia, l'opzione URL sembra ancora dovrebbe essere molto meno sicura. Cosa non riesco a considerare?


MODIFICA: spuntano molti validi problemi di errore umano. Questa domanda è stata ispirata da un client che implementa un grado di sicurezza a prova di uomo: accesso VPN tramite telecomando, dimmer dello schermo, timeout di sospensione di 5 minuti, blackout dei social media, ecc. come guardare le spalle o "oops! Ho postato il link su Twitter!". Sto cercando una risposta più sistematica, o almeno una più soddisfacente di "gli umani fanno un casino".


MODIFICA 2: Grazie per aver sottolineato possibile duplicato. IMHO, penso che ognuno abbia un valore come domanda individuale. Questa domanda si rivolge in modo specifico alla sicurezza delle immagini e approfondisce metodi alternativi per proteggere e codificare i dati (ad esempio, la codifica base64). Questa domanda affronta più specificamente il concetto di segretezza e oscurità e lo applica al motivo per cui un accesso è migliore di un URI indipendentemente dal tipo di dati in questione. Inoltre, non credo che la risposta accettata qui spieghi la mia particolare domanda in modo così profondo o completo come l'ottima risposta di @ SteveDL di seguito.

Questa non è una risposta esaustiva, quindi la inserirò come commento: quando l'URL è il segreto, spesso le persone non lo tratteranno con la stessa attenzione con cui farebbero altre informazioni come un utente / passaggio. Certo, un URL sufficientemente complesso viene utilizzato tutto il tempo per proteggere i dati riservati (i siti di condivisione di file cloud fanno tutto.il.tempo) ma questo non lo rende uguale a un utente / passaggio che le persone generalmente (ma non sempre) riguardo con un po 'più di riverenza. Se la scala temporale è breve (cioè è attiva solo per pochi giorni e poi viene cancellata), allora non stai davvero aumentando il rischio in questo modo.
@JeffMeden Per i siti Web di condivisione cloud, le cose che in realtà devono essere protette non sono accessibili solo con un URL; devi anche essere loggato.
I segreti come le password vengono mantenuti segreti * in base alla progettazione *. Vengono utilizzati, trasferiti e archiviati quando necessario, quindi rilasciati. Gli URL non sono considerati segreti e come tali non vengono gestiti con lo scopo di minimizzarne la durata da tutti gli attori dell'ecosistema Internet. È quello che ti stai perdendo.
@SteveDL Penso che tu abbia ragione - anche ignorando le esposizioni accidentali / accidentali, è la percezione del collegamento rispetto alla password che causa il problema. Se lo pubblichi come risposta, lo accetto!
Idem @JeffMeden
Fatto. Nota che tutte le risposte sono ugualmente valide a questo punto. Inoltre, non dare per scontato che le persone che ragionano esclusivamente in termini di sicurezza abbiano coperto l'aspetto "errore umano". Ciò richiede l'assunzione di designer di interazione, etnografi e simili :-)
L'aggiunta di una password può essere molto semplice quando si utilizza solo un semplice login HTTP invece di un elaborato modulo HTML. Su Apache, ad esempio, puoi farlo inserendo un file .htaccess con il nome utente e la password nella stessa directory sul tuo server web: è brutto ma veloce da fare e fa il lavoro.
Tieni presente che pubblicare l'URL a qualcuno in una chat Facebook * privata * (e alcuni altri servizi) attiverà un accesso a quell'URL.
Non ho visto nessun altro menzionarlo, ma potresti mitigare il problema di esporre l'URI durante la trasmissione posizionando la "password" dietro un tratteggio incrociato (#) e facendo in modo che un po 'di javascript lo sposti nel corpo di una richiesta XHR. I browser non invieranno l '"Hash URI" (da non confondere con un hash crittografico). Tuttavia, non è destinato a mantenere segreti, quindi tutti gli altri problemi di registrazione della cronologia del browser e simili si applicano ancora.
@ZevChonoles mentre entrambe le domande sollevano preoccupazioni simili sulla sicurezza degli URI, IMHO penso che ognuna abbia un valore come domanda individuale. Questa domanda affronta in modo specifico la sicurezza delle immagini e approfondisce metodi alternativi per proteggere e codificare i dati (ad esempio codifica base64). Questa domanda affronta più specificamente il concetto di segretezza e oscurità e lo applica al motivo per cui un accesso è migliore di un URI indipendentemente dal tipo di dati in questione.
Guarda anche questa domanda e le sue risposte (pensa in particolare al tuo cliente che prova il sito con Google Chrome (autsch!): Http://security.stackexchange.com/questions/63124/how-can-outsiders-discover-the-pages -che-sono-ospitato-sul-mio-server / 63167 # 63167
Sei risposte:
Steve Dodier-Lazaro
2015-05-13 04:03:58 UTC
view on stackexchange narkive permalink

Mi dilungherò su un punto a un livello leggermente più astratto sul perché gli spazi pubblici autenticati sono preferibili agli spazi nascosti non protetti. Le altre risposte sono tutte perfettamente valide ed elencano più attacchi che dovresti sapere meglio per evitare.

Chiunque abbia una formazione formale dovrebbe aver sentito a un certo punto il principio di sicurezza di Open Design. Afferma che i sistemi non devono fare affidamento sui dettagli della loro progettazione e implementazione che sono segreti per il loro funzionamento. Che cosa ci dice su password segrete e URL segreti?

Le password sono segreti di autenticazione. Sono conosciuti da un'entità sfidata che li fornisce a un'entità stimolante per l'autenticazione. Entrambe le parti necessitano di una forma di archiviazione e di un canale di comunicazione. Rubare la password richiede di compromettere uno dei tre. Tipicamente:

  1. L'utente deve essere intrappolato o costretto a rivelare la password
  2. Il server deve essere violato in modo che riveli una versione con hash della password
  3. La riservatezza del canale tra l'utente e il server deve essere compromessa

Tieni presente che ci sono molti modi per rafforzare l'autenticazione, iniziando aggiungendo un ulteriore fattore di autenticazione con differenti requisiti di archiviazione e canali di trasmissione, e quindi con diversi canali di attacco (principio della separazione dei privilegi).

Possiamo già concludere che URL oscuri non possono essere migliori delle password perché in tutti i vettori di attacco alle password, l'URL è noto (2 e 3) o ottenibile (1).

Gli URL oscuri d'altra parte vengono manipolati molto più comunemente. Ciò è in gran parte dovuto al fatto che più entità automatizzate e manuali nell'ecosistema Internet elaborano regolarmente gli URL. La segretezza dell'URL si basa sul fatto che sia nascosto in bella vista , il che significa che deve essere elaborato da tutte queste terze parti proprio come se fosse un bene pubblico, già noto, esponendolo agli occhi di tutti. Ciò porta a molteplici problemi:

  • I vettori attraverso i quali questi oscuri URL possono essere memorizzati, trasmessi e copiati sono molto più numerosi
  • I canali di trasmissione non devono essere riservati- protetto
  • Gli spazi di archiviazione non devono essere protetti dalla riservatezza o dall'integrità, o monitorati per la fuga di dati
  • La durata degli URL copiati è in gran parte fuori dal controllo del client originale e server principal

In breve, tutte le possibilità di controllo vengono immediatamente perse quando è necessario che un segreto venga trattato apertamente. Dovresti nascondere qualcosa in bella vista solo se è impossibile che terze parti diano un senso a quella cosa. Nel caso degli URL, l'URL può funzionare solo nell'intero ecosistema di Internet (compreso il tuo browser del client, una varietà di server DNS e il tuo server Web) se può essere comprensibile, quindi deve essere mantenuto in un formato in cui i tuoi avversari possano usarlo per indirizzare il tuo server.

In conclusione, rispetta il principio del design aperto.

Vorrei poter fare +2 questo - esattamente quello che stavo cercando. Stavo esaminando il problema troppo da vicino al microscopio e non sono riuscito a considerare le implicazioni nell'ecosistema in generale. Grazie per la magnifica risposta!
k1DBLITZ
2015-05-13 02:43:00 UTC
view on stackexchange narkive permalink

Dato che stiamo parlando in teoria, ecco diversi motivi per cui un URL casuale da solo non è sufficiente per proteggere i dati riservati:

  • Gli URL possono essere aggiunti ai segnalibri.
  • Gli URL vengono registrati nella cronologia del browser (chiosco pubblico).
  • Gli URL vengono visualizzati nella barra degli indirizzi (surfisti spalla).
  • Gli URL vengono registrati (si pensi a proxy di terze parti).
  • Gli URL possono essere trapelati tramite le intestazioni dei referrer

Non sono chiaro su alcuni dei tuoi punti elenco.

Stai dicendo che questo potenziale server web / sito web / platform effettivamente ha una protezione dal fuzzing delle directory, o è ipotetico?

Anche così, non protegge dagli elementi che ho menzionato sopra.

e per favore, ultimo ma non meno importante: gli URL vengono raccolti dal tuo governo per il tuo bene, o qualcosa del genere.
Inoltre, se un laptop aveva la pagina aperta, è molto più facile tentare accidentalmente di ricaricare l'URL su una rete non sicura piuttosto che POST accidentalmente la password su una rete non sicura.
+1 per essere conciso e informativo - grazie per la risposta!
@Steve DL Non solo il governo. Se navighi dalla rete del tuo datore di lavoro, da un Wi-Fi Starbuck gratuito, dal DSL dell'ISP o dalla connessione dati del tuo telefono cellulare, hanno accesso alla cronologia di navigazione. Il tuo datore di lavoro potrebbe essere interessato a vedere se sei entrato in Facebook. Almeno se non usi TOR o un software simile
@SteveDL ... e anche da organizzazioni che stanno al di sopra dei governi. Ad esempio, un Internet Explorer configurato in modo incoerente potrebbe chiedere a Microsoft se sarebbe sicuro visitare quell'URL, che testano visitando quell'URL. In altre parole, noterai * davvero * accessi a sorpresa involontari agli URL oscuri nei tuoi log.
Gilles 'SO- stop being evil'
2015-05-13 03:00:40 UTC
view on stackexchange narkive permalink

Indovinare l'URL, tuttavia, è cieco. Richiede di trovarsi nel dominio (e sottodominio) corretto

Tuttavia, gli spider più rispettabili non "indovinano" i siti, seguono semplicemente i link "

Considerando i principali I motori di ricerca non essere rispettabili è una posizione difendibile, ma non cambia il fatto che fanno di più che seguire i link. In particolare, i motori di ricerca possono enumerare le voci DNS, quindi la semplice esistenza di un sottodominio è un rischio.

Molte cose finiscono su Google anche se le persone giurano di non essersi mai collegate ad esso da nessuna parte e Google non restituisce alcuna pagina che rimandi al sito.

Questo in aggiunta al problema che le persone generalmente non trattano gli URL come riservati e che gli URL vengono visualizzati in tutti i tipi di luoghi come server, registri del browser e del proxy. Gli URL sono inoltre visibili e utilizzati da molte più estensioni del browser rispetto alle password. Se il sito "nascosto" ha collegamenti in uscita, è probabile che l'URL venga visualizzato nelle intestazioni Referer: .

Esiste anche il rischio che, a causa di una configurazione errata, un collegamento al sito nascosto appare in un luogo non nascosto, ad esempio se il sito nascosto è ospitato su un sito che offre una funzione di ricerca locale.

La pagina di accesso è collegata da un sito web: è un muro visibile per un attaccante su cui battere. È la prova che esiste qualcosa per cui vale la pena attaccare.

Non ha senso. Usa un software decente e una password generata in modo casuale e non c'è superficie di attacco che valga la pena perseguire. Al contrario, una directory nascosta non sembra nemmeno qualcosa che valga la pena attaccare, sembra qualcosa che è aperto al pubblico.

Un URL segreto è particolarmente soggetto a rischi perché se l'URL è trapelato accidentalmente e un motore di ricerca lo scopre, l'intero contenuto del sito verrà esposto attraverso quel motore di ricerca. Una password non fallisce in modo catastrofico: se la password è trapelata, ci vuole ancora qualche azione volontaria perché qualcuno inizi a scaricare i dati, non avvia automaticamente un macchinario che la pubblicherà affinché tutti possano vederla.

Anche se sollevi punti positivi, non credo tu abbia affrontato lo spirito della domanda. Sono d'accordo sulla vulnerabilità DNS: ecco perché questa domanda riguarda le sottodirectory, non i sottodomini. L'indicizzazione accidentale è discutibile, poiché uno dei presupposti della domanda è che la sottodirectory sia stabilita come non rivelata e non indicizzata. Infine, sono rispettosamente in disaccordo sul fatto che il punto della pagina di accesso "non abbia alcun senso". Che valore ha un utente malintenzionato che sceglie un dominio casuale e cerca contenuti eventualmente nascosti? Non avrà quasi mai successo. Una pagina di accesso, anche bloccata, fornisce feedback.
Sebbene comprenda i punti che stai cercando di fare, potrebbe essere utile fare un po 'più di sforzo per comprendere la domanda effettiva in modo da poter rispondere con precisione. Cercherò anche di apportare modifiche per rendere più chiaro ciò che sto chiedendo.
@CodeMoose Il feedback che dice semplicemente "password errata" non è un feedback utile. L'indicizzazione accidentale non è un punto controverso, è un rischio piuttosto comune. Sono ragionevolmente fiducioso di aver capito la domanda e ho affrontato direttamente alcuni dei tuoi punti.
Eppure, quello che sto leggendo sembra dire "ecco perché questa non è una domanda realistica da porre", non "dati questi punti, ecco il fattore x che non hai considerato". Ancora una volta, apprezzo l'input, sai molto chiaramente di cosa stai parlando :) Sto solo cercando una risposta in una strada diversa e stavo cercando di fornire un feedback in tal senso.
@CodeMoose Faccio davvero fatica a capire il tuo commento. La mia risposta è praticamente solo "ecco i fattori x, y, z che non hai considerato", e non dico da nessuna parte qualcosa come "questa non è una domanda realistica". È una domanda realistica e ragionevole e la risposta è un forte no.
@CodeMoose Penso che ti aspettavi un commento di alto livello sulla progettazione del tuo requisito di sicurezza, ma hai posto la domanda in termini di implementazione, quindi hai attirato risposte a livello di implementazione. È corretto?
@SteveDL Potrebbe essere corretto: pensavo di avere una solida comprensione della domanda, ma sembra che sia più sfumata di quanto pensassi. Grazie per la pazienza!
@Gilles ringrazia anche per l'ottima risposta, ha imparato molte cose inaspettate in questo processo.
Ma cosa succede se la password viene effettivamente trapelata in un modo compatibile con i motori di ricerca, come un collegamento a http: // nomeutente: password@example.com/secretpage.html?
@HagenvonEitzen Le persone usano ancora l'autenticazione HTTP di base in questi giorni?
David Mulder
2015-05-14 03:10:21 UTC
view on stackexchange narkive permalink

Sono d'accordo con le altre risposte che è una cattiva idea, semplicemente perché le persone (=> sviluppatori => applicazioni che registrano informazioni) non considerano gli URL privati ​​e quindi ci sono molti modi diversi in cui chiave potrebbe essere trapelata. Ciò che tuttavia hai correttamente riconosciuto è che le password sono essenzialmente una forma di sicurezza attraverso l'oscurità. E che concettualmente non c'è niente di sbagliato nello schema che proponi. L'unico problema è dovuto al fatto che lo schema che stai proponendo utilizza in modo improprio i sistemi in modi per cui non erano destinati.

Anche usando una stringa di due parole debole nel dizionario sia per la password che per l'URL, ci sono ancora miliardi di opzioni indovinabili. Inserendolo nell'URL non si riduce magicamente l'elenco.

Vero, ma non lo rende neanche più sicuro.

Le pagine di accesso possono avere protezione dalla forza bruta, quindi un utente malintenzionato otterrebbe ottimisticamente 20 tentativi di indovinare. L'individuazione dell'URL dovrebbe essere rilevata dal DoS del server o dalla protezione antispam e potrebbe consentire 200 ipotesi che producono 404 se si prevede un attacco, ancora non statisticamente significativo per miliardi di opzioni.

Se prevedi un attacco, probabilmente lo limiterai allo stesso modo alle migliori pratiche per la protezione dalla forza bruta per il tuo tipo di applicazione. Quindi, in effetti, non è peggio se fatto bene , ma sicuramente non è migliore e probabilmente sarà peggio in quanto dovrai fare molto più lavoro personalizzato.

La pagina di accesso è collegata da un sito Web: è un muro visibile su cui un utente malintenzionato può battere. È la prova che esiste qualcosa per cui vale la pena attaccare. Indovinare l'URL, tuttavia, è cieco. Richiede di trovarsi nel dominio (e sottodominio) corretto e di operare nella certezza che, anche dopo decine di migliaia di ipotesi errate, si troverà comunque qualcosa.

Assolutamente vero, e per questo motivo ho visto alcune aziende nascondere le loro pagine di accesso intranet su URL leggermente imprevedibili. È qualcosa su cui fare affidamento? Assolutamente no. È qualcosa che potrebbe fermare alcuni aggressori di basso profilo? Sicuramente.

Ad ogni modo, questo tuttavia fornisce solo un vantaggio limitato di per sé rispetto a un grande compromesso come descritto nel primo paragrafo.

L'URL ha una suscettibilità extra essere indice / ragno esternamente. Tuttavia, la maggior parte dei ragni rispettabili non "indovina" nei siti, seguono solo i collegamenti. Uno spider dannoso "indovinare" verrebbe catturato dalla stessa protezione DoS / spam del punto 2.

L'unico problema con gli spider è che potrebbero trovare una cache casuale da qualche parte in cui l'URL è stato collegato e indicizzarlo in un modo più facile da trovare per gli altri. L'ipotesi casuale non è davvero un problema.

Atsby
2015-05-13 06:11:03 UTC
view on stackexchange narkive permalink

Ho utilizzato personalmente HTTPS con URL non indovinabile come protocollo per la consegna sicura dei file. Con la cronologia del browser disattivata sul lato ricevente e se l'URL viene comunicato in modo sicuro come sarebbe una password, questo è praticamente sicuro come una pagina di accesso HTTPS. Che è molto meno sicuro di, ad esempio, GnuPG.

Tuttavia, l'URL stesso non è crittografato. Qualsiasi nodo nel percorso può vedere l'URL e quindi recuperare quel file.
@schroeder L'uso di HTTP ** S ** lo impedisce (sì, gli URL vengono inviati tramite SSL / TLS in HTTP ** S **). Ovviamente, per evitare attacchi MITM è necessario un certificato reale, al contrario di quello autofirmato.
Vero, ma con notevoli eccezioni: proxy lato client, registri di accesso del server e bilanciatori del carico / SSL offloader sul lato server.
@schroeder Beh, tecnicamente una password POST passa anche attraverso tutte quelle in quegli scenari. L'unica cosa diversa sarebbe la registrazione.
702cs
2015-05-13 03:52:44 UTC
view on stackexchange narkive permalink

Come altri hanno già detto, se prevedi di lasciare questa directory e questo sito Web per un giorno o due con informazioni e dati riservati e sei in una situazione seria, allora questo sarebbe ok ma non "best practice". In altre parole, non è consigliabile, ma se ritieni di dover correre il rischio.

Il problema principale con questo concetto è cosa succede se il client ha un rootkit o un key logger sulla sua macchina? Cosa succede se un'altra parte ottiene il collegamento? Quello che sto dicendo è che chiunque ottenga questo collegamento potrà accedere a questi dati riservati. Vorrei inserire un accesso rapido nella pagina per consentire l'accesso solo ai client per i quali sono destinati i dati.

Se il dispositivo di un client è compromesso, sono necessari fattori di autenticazione che * non * richiedono di considerare attendibile la macchina client per mantenere l'input del client per sé. Una password sarebbe ugualmente catturata da un keylogger.
702cs, come già commentato da @SteveDL, la tua soluzione non protegge dai logger. Anche questo tipo di comportamento a rischio dovrebbe essere evitato non approvato in quanto è ad alto rischio e non è possibile prevedere il risultato. Resta al passo e continua a rispondere (tutti noi riceviamo risposte "negative" prima di sapere cosa sono le risposte buone;))


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...