Usa una "password" aggiuntiva in Referer per nascondere il sito privato?

Personalmentepensochetustiaandandobene.Finchéilmetododiaccessosottostanteèsicuro,aggiungituttiilivellidioscuritàdesiderati.

Holavoratoconalcuniclientichevolevanol'esattacosachestaicercandodiottenere.Hosempreusatounodiquestiduemetodi:

• Modulodiaccessotrasiti:unfile.htmllocaleconunmodulodiaccessocheinviaexample.com/private/login.php.Ilmodulodiaccessoavevauncampohiddenconuntokengeneratocasualmente.

Naturalmentechiunqueavrebbepotutodistribuirelostessofile.html,manoneraimportante,perchéilnostroprincipalemetododisicurezzaeralastessaproceduradiaccesso;ilnomeutenteelapassword.

Ognirichiestaaexample.com/privateèstatarifiutataealvisitatoreèstatamostratauna404.MaquandoèstataricevutaunarichiestadiPOSTconlecredenzialicorrette,unasessioneèstataavviata,ilsitowebhafunzionatonormalmente.

L'aspettopositivodiquestometodoèchetigarantisce negabilità plausibile . Se qualcuno riceve il file .html , può provare ad accedere e otterrebbe ancora 404 . Non ci sono prove che questo file sia correlato a un sito web funzionante.

• Password aggiuntiva nell'URL: praticamente uguale al tuo metodo, ma il token di autenticazione extra era nell'URL. Ogni richiesta a example.com/private è stata rifiutata e al visitatore è visualizzata una 404 . Ma quando viene ricevuto un% co_de corretto, viene visualizzato il modulo di accesso.

Alla maggior parte dei clienti è piaciuto questo metodo in quanto erano in grado di aggiungere un segnalibro a quell'URL. Tuttavia, il lato negativo di questo metodo è che NON ti garantisce una negabilità plausibile. Chiunque abbia l'URL può provare che esiste un modulo di accesso funzionante su quel sito Web.

Ad essere onesti, mi piace il tuo metodo e penso che potrei usarlo un giorno.

IMPORTANTE: tutto quanto sopra si applica solo dopo ti assicuri che il tuo metodo di accesso sia sicuro.

Il tuo metodo è funzionalmente equivalente a richiedere l'autenticazione con due password, il Referer è uno di loro. Una variante più comune consiste nell'utilizzare un URL segreto, ovvero per rendere la parte "stringa speciale" del percorso del sito privato. Includere la stringa segreta nell'URL può includere alcuni dettagli aggiuntivi su cui riflettere (ad esempio, gli utenti possono aggiungerlo ai segnalibri, cioè la stringa è scritta in un file non-so-hidden sulla macchina dell'utente), ma anche portare alcuni extra (ad esempio, gli utenti possono aggiungilo ai segnalibri, rendendolo compatibile con tutti i tipi di browser, non solo Firefox con estensione). Per usabilità , tendo a pensare che una stringa segreta nell'URL stesso sia un compromesso migliore, ma questa è la tua chiamata.

Spero che tu stia utilizzando HTTPS per il tuo sito completo. Infatti, se utilizzi un semplice HTTP sia per i siti pubblici che per quelli privati, l'intercettatore passivo potrebbe osservare le tue comunicazioni con il sito privato, rivelando le tue password e tutti i tuoi segreti. Questo è male.

Se usi HTTPS solo per il sito privato, allora hai un server che ascolta sulla porta 443, e gli hacker possono vederlo abbastanza chiaramente (è semplice come fare un tentativo di connessione su di esso ). Se il sito pubblico principale è solo HTTP, gli hacker comprenderanno presto che esiste un sito privato (uno non si prende la briga di acquistare e configurare un certificato server SSL solo per il gusto di farlo). Se si desidera che il proprio sito privato non venga rilevato, è necessario utilizzare HTTPS anche per il sito pubblico (alcune persone lo consigliano genericamente, per una serie di ragioni, non tutte tecniche).

Non conosco il comportamento esatto dell'estensione RefControl, ma dovrai assicurarti che invii la tua speciale stringa Referer solo alla versione HTTPS del tuo sito, non il HTTP (se esiste). Anche in questo caso, mi sento personalmente più sicuro con una stringa segreta nell'URL, perché almeno so quando verrà inviato e quando non lo sarà.

Se non vuoi che qualcuno sappia che c'è un server web a example.com a meno che non venga richiesto un URL speciale, devi implementarlo come regola a livello di firewall IP . Deve cercare i pacchetti SYN che arrivano per la porta 80 e guardare il payload per vedere che si tratta di una richiesta HTTP valida per l'URL consentito. In caso contrario, basta rilasciare il pacchetto.

Altrimenti, se la richiesta dell'URL sbagliato arriva al server, il server annuncia la sua presenza stabilendo la connessione TCP (e rispondendo con un 404).

Se sei su Linux, puoi usare il modulo di stringa iptables per fare questo genere di cose.

Dai un'occhiata qui: link

Sì, va bene. Finché il livello della password è sicuro, l'aggiunta di ulteriori livelli di oscurità aiuterà.

Alcuni altri trucchi (mescolare e abbinare):

• Rendi la pagina di accesso accessibile solo tramite una richiesta POST AJAX (per accedere crea una richiesta POST nella console JS)
• Funziona solo se hai effettuato l'accesso a example.com/trigger?pwd=abcd (che è anche una pagina 404) nell'ultimo minuto.
• Rendi l'URL una funzione della data e dell'ora. Qualcosa di facile da calcolare in una console JS ma difficile da indovinare

Supponendo che tu abbia progettato il sito, la cosa migliore è sempre aggiungere una clausola all'inizio della pagina "/ private /" ti rimanda. La clausola dovrebbe essere qualcosa di simile  se user.authenticated = true       Quindi "carica la pagina"   Altro        "Errore 404"

Ricorda che la mia etichettatura è molto generica

L'istruzione user.authenticated potrebbe cambiare con le lingue della pagina, ma sarebbe sufficiente verificare se Alice avesse già effettuato l'accesso, se non l'avesse fatto otterrebbe l'errore 404, il che significa che avrebbe dovuto andare manualmente a example.com/home.php o login.aspx o come viene chiamata la pagina di accesso.

Una soluzione: disattivare l'indicizzazione delle directory e inserire il contenuto in 'example.com/9b2389Bqa0-ub712-bauUU-UZsi12jkna10712'. Aggiungi questo URL speciale ai segnalibri. Un utente malintenzionato che tenta un attacco di enumerazione della forza bruta otterrà il vero errore HTTP 404 per la maggior parte del tempo. Nella soluzione, gli aggressori possono eseguire analisi di temporizzazione e notare che 404 da "/ private" sono più lenti di quelli di "/ nosuchpage". Nella soluzione che propongo c'è solo un tipo di risposta 404.

Svantaggio: URL brutti. Ci sono altri svantaggi che posso pensare, ma quelli sono anche presenti nel tuo schema.

Se l'utente malintenzionato riceveva risposte "non autorizzate da HTTP 401" indipendentemente da cosa avessero tentato di accedere, sarebbe considerato come l'autore dell'attacco che scopre che c'è "qualcosa" in quel sito? L'utente malintenzionato sa già che quel dominio è registrato e che c'è un server web in esecuzione su quel nome host.

Se questa soluzione ti soddisfa, utilizza link

Svantaggio: non puoi reclamare "il sito è vuoto, controlla te stesso". Se ne hai bisogno, sei in un affare interessante. : -)

Puoi usare questo semplice codice PHP (crea un file index.php):

<?php
 if (isset($_GET['passkey']) && $_GET['passkey'] == '9b2389Bqa0-ub712/bauUU-UZsi12jkna10712') {
   ?>
   ... your html page ...
   <?php
 } else {
   header("HTTP/1.0 404 Not Found");
 }
?>

se desideri accedere al tuo sito, apri l'url "www.example.com/?passkey=9b2389Bqa0-ub712/bauUU-UZsi12jkna10712"

Preferirei che solo le richieste di Autenticazione di base vengano elaborate da un server Web su quell'URL in questo caso. Quindi, se Alice tentasse di indovinare, otterrebbe un 404 su example.com/private Ma dal momento che conosci l'URL che potresti direttamente inviare l'intestazione auth (i.e):

Autorizzazione: base QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

insieme alla tua richiesta su example.com/private e che saranno accettati e processati