Un sito web pubblicato in una directory oscura è relativamente sicuro per essere inserito dietro un login? [duplicare]

Mi concentrerò su un punto a un livello leggermente più astratto sul motivo per cui gli spazi autenticati pubblici sono preferibili a spazi nascosti non protetti. Le altre risposte sono tutte perfettamente valide e elencano più attacchi che si dovrebbero conoscere meglio per evitare.

Chiunque abbia una formazione formale dovrebbe aver ascoltato 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 sulla loro implementazione segreta per il loro funzionamento. Cosa ci dice sulle password segrete e sugli 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 hanno bisogno 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 forzato nel rivelare la password
2. Il server deve essere hackerato in modo da rivelare una versione hash della password
3. La riservatezza del canale tra l'utente e il server deve essere compromessa

Si noti che vi sono molti modi per rafforzare l'autenticazione, iniziando aggiungendo un fattore di autenticazione aggiuntivo con requisiti di archiviazione e canali di trasmissione diversi, e quindi con diversi canali di attacco (principio di separazione dei privilegi).

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

URL oscuri d'altra parte vengono manipolati molto più comunemente. Ciò è dovuto in gran parte al fatto che più entità automatizzate e manuali nell'ecosistema Internet elaborano gli URL di routine. La segretezza dell'URL si basa sul fatto che è 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. Questo porta a più 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 protetti dalla riservatezza
• Non è necessario che gli spazi di archiviazione siano riservati o protetti da integrità o monitorati per perdite di dati
• La durata degli URL copiati è in gran parte fuori dal controllo dei principal client e server originali

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

In conclusione, rispetta il principio del design aperto.

Dato che stiamo parlando in teoria, qui ci sono 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 sono registrati nella cronologia del browser (chiosco pubblico).
• Gli URL vengono visualizzati nella barra degli indirizzi (navigatori sulla spalla).
• Gli URL vengono registrati (si pensi al proxy di terze parti).
• Gli URL possono essere divulgati tramite le intestazioni dei referrer

Non sono chiaro alcuni dei tuoi punti elenco.

Stai dicendo che questo potenziale server web / sito web / piattaforma anzi ha una protezione per le fuzzing delle directory, o è ipotetico?

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

Guessing the URL, however, is blind. It requires being on the right domain (and subdomain)

However, most respectable spiders don't "guess" at sites, they just follow links’

Considerare i principali motori di ricerca che non devono 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 averle mai collegate da nessuna parte e Google non restituisce alcuna pagina che rimandi al sito.

Questo è in aggiunta al problema che le persone in genere non considerano gli URL come riservati e che gli URL appaiono in tutti i tipi di luoghi come i registri di server, browser e proxy. Gli URL sono anche visibili e utilizzati da molte più estensioni del browser rispetto alle password. Se il sito "nascosto" ha link in uscita, è probabile che l'URL appaia in Referer: di intestazioni.

C'è anche il rischio che attraverso una configurazione errata, un link al sito nascosto venga visualizzato in un luogo non nascosto, ad esempio se il sito nascosto è ospitato su un sito che offre una funzione di ricerca locale.

The login page is linked from a website - it's a visible wall for an attacker to beat on. It's evidence that something exists worth attacking for.

Questo non ha senso. Usa un software decente e una password generata a caso, e non c'è una superficie di attacco che valga la pena perseguire. Al contrario, una directory nascosta non sembra nemmeno qualcosa che valga la pena di essere attaccata, sembra qualcosa che è aperta al pubblico.

Un URL segreto è particolarmente incline al rischio perché se l'URL viene trapelato accidentalmente e un motore di ricerca lo rileva, l'intero contenuto del sito verrà esposto attraverso quel motore di ricerca. Una password non fallisce in modo catastrofico: se la password è trapelata, è ancora necessario un intervento volontario per consentire a qualcuno di iniziare a scaricare i dati, ma non avvia automaticamente un macchinario che lo pubblicherà affinché tutti possano vederlo.

Sono d'accordo con le altre risposte che è una cattiva idea, semplicemente perché le persone (= > developers = > applicazioni che registrano le informazioni) non considerano gli URL come privati e quindi ci sono molti modi diversi in cui < em> tasto potrebbe essere trapelato. Ciò che tuttavia avete riconosciuto correttamente è che le password sono essenzialmente una forma di sicurezza attraverso l'oscurità. E questo concettualmente non c'è niente di sbagliato nello schema che stai proponendo. L'unico problema è dovuto al fatto che lo schema che stai proponendo sta utilizzando male i sistemi in modi per i quali non sono stati concepiti.

Even using a dictionary-weak, two-word string for both the password and the URL, there are still billions of guessable options. Placing it in the URL doesn't magically reduce that list.

È vero, ma non lo rende più sicuro.

Login pages can have brute-force protection, so an attacker would get optimistically 20 attempts to guess. URL guessing would have to be caught by the server's DoS or spam protection, and may allow 200 404-producing guesses if you're anticipating an attack - still not statistically significant to billions of options.

Se stai anticipando un attacco, probabilmente lo limiterai ugualmente alle best practice per la protezione brute-force per il tuo tipo di applicazione. In effetti, non è peggio se fatto bene , ma sicuramente non è migliore e probabilmente andrà peggio dato che dovrai fare molto più lavoro personalizzato.

The login page is linked from a website - it's a visible wall for an attacker to beat on. It's evidence that something exists worth attacking for. Guessing the URL, however, is blind. It requires being on the right domain (and subdomain), and operating on faith that, even after tens of thousands of incorrect guesses, you're still going to turn something up.

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

In ogni caso, questo fornisce solo un vantaggio limitato rispetto ad un ampio trade off come descritto nel primo paragrafo.

The URL has an extra susceptibility to being index/spidered externally. However, most respectable spiders don't "guess" at sites, they just follow links. A malicious "guessing" spider would be caught by the same DoS/spam protection as point 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 che è più facile da trovare per gli altri. Indovinare a caso non è davvero un problema.

Ho utilizzato personalmente HTTPS-with-unguessable-URL 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 una password, questo è praticamente sicuro come una pagina di accesso HTTPS. Il che è molto meno sicuro di, ad esempio, GnuPG.

Come altri hanno già detto, se hai intenzione di lasciare questa directory e il sito web per un giorno o due con informazioni e dati riservati e sei in una situazione di grave crisi, allora sarebbe ok ma non "best practice". In altre parole è sconsigliato, ma se senti di doverlo cogliere.

Il problema principale di questo concetto è che cosa succede se il client ha un rootkit o un keylogger sulla sua macchina? Cosa succede se un'altra parte ottiene il collegamento? Quello che sto dicendo è che chiunque ottenga questo link sarà in grado di accedere a questi dati riservati. Inserirò un accesso rapido sulla pagina per consentire solo l'accesso ai client per i quali i dati sono destinati.