Ich persönlich denke, es geht Ihnen gut. Solange Ihre zugrunde liegende Anmeldemethode sicher ist, fügen Sie so viele Dunkelheitsebenen hinzu, wie Sie möchten.

Ich habe mit einigen Clients zusammengearbeitet, die genau das wollten, was Sie erreichen möchten. Ich habe immer eine dieser beiden Methoden verwendet:

• Cross-Site-Anmeldeformular: Eine lokale .html -Datei mit einem Login Formular, das an example.com/private/login.php gesendet wird. Das Anmeldeformular hatte ein verstecktes -Feld mit einem zufällig generierten Token.

Natürlich hätte jeder dieselbe .html -Datei verteilen können , aber das war nicht wichtig, da unsere Hauptsicherheitsmethode der Anmeldevorgang selbst war. den Benutzernamen und das Passwort.

Jede Anfrage an example.com/private wurde abgelehnt und dem Besucher wurde ein 404 angezeigt. Wenn jedoch eine POST -Anforderung mit den richtigen Anmeldeinformationen empfangen wurde, wird eine Sitzung gestartet, auf der die Website normal funktioniert.

Der Vorteil dieser Methode besteht darin, dass Sie eine plausible Verleugnung erhalten. Wenn jemand die Datei .html erhält, kann er versuchen, sich anzumelden, und er erhält trotzdem 404 . Es gibt keinen Beweis dafür, dass diese Datei mit einer tatsächlich funktionierenden Website zusammenhängt.

• Zusätzliches Kennwort in der URL: Entspricht weitgehend Ihrer Methode, jedoch dem zusätzlichen Authentifizierungstoken war in der URL. Jede Anfrage an example.com/private wurde abgelehnt und dem Besucher wird ein 404 angezeigt. Wenn jedoch ein ordnungsgemäßes example.com/private/login.php?token=Zz37vQQCnLTpe527xeFfFEG9 empfangen wird, wird das Anmeldeformular angezeigt.

Die meisten Kunden mochten diese Methode so, wie sie es wollten konnten diese URL mit einem Lesezeichen versehen. Der Nachteil dieser Methode ist jedoch, dass sie Ihnen KEINE plausible Verleugnung gewährt. Jeder mit der URL kann nachweisen, dass auf dieser Website ein funktionierendes Anmeldeformular vorhanden ist.

Um ehrlich zu sein, ich mag Ihre Methode und denke, ich könnte sie eines Tages verwenden.

WICHTIG: Alle oben genannten Punkte gelten nur , nachdem Sie sichergestellt haben, dass Ihre Anmeldemethode sicher ist.

Ihre Methode entspricht funktional der Anforderung einer Authentifizierung mit zwei Kennwörtern, wobei der Referer eines davon ist. Eine häufigere Variante besteht darin, eine geheime URL zu verwenden, d. H. Die "spezielle Zeichenfolge" Teil des Pfades zur privaten Site zu machen. Das Einfügen der geheimen Zeichenfolge in die URL kann einige zusätzliche Details enthalten, über die nachgedacht werden muss (z. B. Benutzer können sie mit einem Lesezeichen versehen, was bedeutet, dass die Zeichenfolge in einer nicht so versteckten Datei auf dem Computer des Benutzers geschrieben ist), aber auch einige Extras mitbringen (z. B. Benutzer können dies Setzen Sie ein Lesezeichen, damit es mit allen Arten von Browsern kompatibel ist (nicht nur mit Firefox (mit einer Erweiterung)). Aus Gründen der Benutzerfreundlichkeit denke ich, dass eine geheime Zeichenfolge in der URL selbst ein besserer Kompromiss ist, aber das ist Ihr Aufruf.

Ich hoffe, Sie verwenden HTTPS für Ihre gesamte Site. Wenn Sie sowohl für die öffentliche als auch für die private Site einfaches HTTP verwenden, kann der passive Lauscher Ihre Kommunikation mit der privaten Site beobachten und Ihre Passwörter und alle Ihre Geheimnisse preisgeben. Dies ist schlecht.

Wenn Sie HTTPS nur für die private Site verwenden, haben Sie einen Server, der Port 443 überwacht, und Angreifer können ihn ganz klar sehen (es ist wie) einfach wie ein Verbindungsversuch darauf). Wenn die öffentliche Hauptseite nur HTTP ist, werden Angreifer bald verstehen, dass es eine private Seite gibt (man macht sich nicht die Mühe, ein SSL-Serverzertifikat nur zum Spaß zu kaufen und einzurichten). Wenn Sie möchten, dass Ihre private Site unentdeckt bleibt, müssen Sie HTTPS auch für die öffentliche Site verwenden (einige Leute empfehlen es aus verschiedenen Gründen generisch, nicht alle aus technischen Gründen).

Ich weiß nicht genau, wie sich die RefControl-Erweiterung verhält, aber Sie sollten sicherstellen, dass Ihre spezielle Referer -String nur an HTTPS gesendet wird Version Ihrer Site, nicht das HTTP (falls vorhanden). Auch hier würde ich mich mit einer geheimen Zeichenfolge in der URL persönlich sicherer fühlen, da ich zumindest weiß, wann sie gesendet wird und wann nicht.

Wenn Sie nicht möchten, dass jemand weiß, dass es unter example.com einen Webserver gibt, sofern keine spezielle URL angefordert wird, müssen Sie dies als Regel direkt an der IP-Adresse implementieren Firewall-Ebene . Es muss nach SYN-Paketen suchen, die für Port 80 ankommen, und anhand der Nutzdaten feststellen, ob es sich um eine gültige HTTP-Anforderung für die zulässige URL handelt. Wenn nicht, verwerfen Sie einfach das Paket.

Wenn andernfalls die Anforderung der falschen URL an den Server weitergeleitet wird, meldet der Server seine Anwesenheit, indem er die TCP-Verbindung herstellt (und mit einem 404 antwortet).

Wenn Sie unter Linux arbeiten, können Sie das String-Modul iptables verwenden, um dies zu tun.

Schauen Sie hier: https : //stackoverflow.com/questions/4628157/allow-connections-to-only-a-specific-url-via-https-with-iptables-m-recent-pot

Ja, es ist in Ordnung. Solange die Kennwortebene sicher ist, hilft das Hinzufügen weiterer Dunkelheitsebenen.

Einige andere Tricks (Mix and Match):

• Machen Sie die Anmeldeseite nur zugänglich über eine AJAX-POST-Anforderung (um sich anzumelden, erstellen Sie eine POST-Anforderung in der JS-Konsole)
• Damit funktioniert dies nur, wenn Sie auf example.com/trigger?pwd=abcd (das ist auch eine 404-Seite) innerhalb der letzten Minute.
• Machen Sie die URL zu einer Funktion von Datum und Uhrzeit. Etwas, das in einer JS-Konsole leicht zu berechnen ist, aber schwer zu erraten ist

Angenommen, Sie haben die Site entworfen, fügen Sie am besten immer eine Klausel am Anfang der Seite hinzu, auf die "/ private /" verweist. Die Klausel sollte ungefähr so ​​lauten, wenn user.authenticated = true. Dann "Seite laden". Andernfalls "Fehler 404".

Beachten Sie, dass meine Beschriftung sehr allgemein ist.

Die Anweisung user.authenticated könnte sich mit Ihren Seitensprachen ändern, würde aber einfach überprüfen, ob Alice sich bereits angemeldet hat, wenn sie es nicht getan hätte, würde sie den Fehler 404 erhalten, was bedeutet, dass sie manuell zu example.com/home.php oder login.aspx oder was auch immer der Login gehen müsste Seite heißt.

Eine Lösung: Deaktivieren Sie die Verzeichnisindizierung und stellen Sie Ihre Inhalte unter 'example.com/9b2389Bqa0-ub712-bauUU-UZsi12jkna10712'. Setzen Sie ein Lesezeichen für diese spezielle URL. Ein Angreifer, der einen Brute-Force-Aufzählungsangriff versucht, erhält die meiste Zeit einen echten HTTP 404-Fehler. In Ihrer Lösung führen die Angreifer möglicherweise eine Timing-Analyse durch und stellen fest, dass 404s von '/ private' langsamer sind als die für '/ nosuchpage'. In der von mir vorgeschlagenen Lösung gibt es nur eine Art von 404-Antwort.

Nachteil: Hässliche URLs. Ich kann mir noch andere Nachteile vorstellen, aber diese sind auch in Ihrem Schema vorhanden.

Wenn der Angreifer "HTTP 401 Unauthorized" -Antworten erhalten würde, unabhängig davon, auf was er zugreifen wollte, würde dies als der Angreifer gelten, der herausfindet, dass sich an dieser Site "etwas" befindet? Der Angreifer weiß bereits, dass diese Domain registriert ist und auf diesem Hostnamen ein Webserver ausgeführt wird.

Wenn diese Lösung zu Ihnen passt, verwenden Sie http://httpd.apache.org/docs /2.4/howto/auth.html

Nachteil: Sie können nicht behaupten, "die Site ist leer, überprüfen Sie selbst". Wenn Sie das brauchen, sind Sie in einem interessanten Geschäft. :-)

Sie können diesen einfachen PHP-Code verwenden (eine index.php-Datei erstellen):

  <? php if (isset ($ _ GET ['passkey']) && $ _GET ['passkey '] ==' 9b2389Bqa0-ub712 / bauUU-UZsi12jkna10712 ') {? > ... Ihre HTML-Seite ... <? Php} else {header ("HTTP / 1.0 404 Not Found"); }? >  

Wenn Sie auf Ihre Website zugreifen möchten, öffnen Sie einfach die URL 'www.example.com/?passkey=9b2389Bqa0-ub712/bauUU-UZsi12jkna10712'

In diesem Fall würde ich lieber zulassen, dass nur Basic-Auth-Anforderungen von einem Webserver unter dieser URL verarbeitet werden. Wenn Alice also versuchen würde zu raten, würde sie eine 404 unter example.com/private erhalten. Da Sie jedoch die URL kennen, können Sie direkt einen Auth-Header senden (dh):

Autorisierung: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

zusammen mit Ihrer Anfrage unter example.com/private, die akzeptiert und bearbeitet wird