Frage:
Verwenden Sie ein zusätzliches "Passwort" in Referer, um eine private Site auszublenden?
unor
2013-04-08 16:12:28 UTC
view on stackexchange narkive permalink

Ich habe eine private Site (= ich bin der einzige Benutzer) unter example.com/private/ . Auf diesem Host wird nichts anderes veröffentlicht (es ist meine Domain).

Ich möchte nicht, dass jemand weiß, dass es unter example.com etwas gibt, insbesondere nicht auf meiner privaten Website.

Nehmen wir nun an, Alice "errät" die URL und besucht example.com/private/ . Natürlich habe ich die Site durch ein Login geschützt, aber ich möchte nicht, dass Alice weiß, dass es überhaupt eine solche Site gibt, und ich möchte nicht, dass sie das Login usw. ausprobiert.

Ich frage mich, ob die folgende Methode mir hier helfen könnte:

Mit dem Firefox-Add-On RefControl kann ich einen benutzerdefinierten Referer -Header auf setzen Nur für Anfragen an einen bestimmten Host verwenden.

Ich setze den Referer auf (z. B.) 9b2389Bqa0-ub712 / bauUU-UZsi12jkna10712 für jede Anfrage an example.com .

Jetzt überprüfe ich mit .htaccess ( weiß nicht, wie es genau möglich ist, aber ich habe gehört, es sollte s> sein, siehe Frage zu Code Review SE) für den Referer des Besuchers:

  • Wenn es sich um 9b2389Bqa0-ub712 / bauUU-UZsi12jkna10712 handelt, tun Sie nichts Besonderes (= Zugriff auf die Site ist möglich)
  • Wenn es sich um etwas anderes handelt, senden Sie den HTTP-Fehler 404

Ich denke, anstelle von 404 könnte eine gefälschte Site angezeigt werden, aber für meine Fall Ich möchte, dass niemand einen Unterschied zwischen / priv sieht aß (was existiert) und / foobar (was existiert nicht → 404).

Würde das funktionieren? Ist es mit .htaccess möglich? Hat diese Methode irgendwelche Mängel? Was soll ich ändern? Ähnliche Methoden?

Aktualisierungen der &-Erläuterungen

  • Der gesamte Host verwendet HTTPS.
  • Ich muss die Tatsache nicht verbergen, dass es ist ein Server, ich möchte nur verbergen, dass Inhalte bereitgestellt werden.
  • Vielen Dank an @ Adnan, dass Sie den Begriff "plausible Verleugnung" ins Spiel gebracht haben → Ich möchte dies (clientseitig)!

  • Einige schlugen vor, eine schwer zu erratende URL zu verwenden (z. B. die an die URL angehängte geheime Zeichenfolge): Obwohl dies sicherlich funktionieren könnte, hat die Verwendung der Referer-Methode den Vorteil, dass Sie nicht können em> enthüllen versehentlich das Geheimnis (leicht). URLs sind sichtbarer als HTTP-Header: jemand, der auf Ihren Bildschirm schaut, versehentlich eine Lesezeichenliste veröffentlicht (ohne sich daran zu erinnern, dass die geheime URL enthalten ist), Browserverlauf, Screenshot Ihres Desktops mit Browser-Adressleiste im Hintergrund,…. Und so haben Sie wieder das anfängliche Problem: Wie Sie verbergen können, dass es eine Site gibt, wenn Alice die URL "errät" (oder was auch immer).

  • Einige schlugen vor, eine externe (noch bessere, lokale) Anmeldeseite zu verwenden. Ich mag diese Idee. Im Vergleich zur Referer-Methode (wenn sie durch .htaccess implementiert werden kann, was ich für möglich halte) hat sie den Nachteil, dass Sie möglicherweise den Code / CMS der Site anpassen müssen. P. >

  • Weitere Informationen zum .htaccess finden Sie in der -Frage zu Code Review SE

  • Wie @ НЛО hervorhebt, wäre ein benutzerdefinierter Header besser. Ja glaube ich auch. Aber ich habe noch kein Firefox-Add-On dafür gefunden (siehe Frage zu Super User).

Diese Methode wird seit Jahren an einer Reihe von "unterirdischen" Standorten angewendet. legitim aussehende Site, aber mit einem bestimmten Verweis auf einer bestimmten Seite erhalten Sie Zugriff auf die reale Site.
Erwägen Sie auch die Verwendung eines benutzerdefinierten HTTP-Headers anstelle von Referer. Der Referer soll standardmäßig protokolliert werden, sodass Alice (sollte sie Protokolle erhalten) vollständige Informationen über das verwendete Obscurity-Schema bereitstellt.
@ НЛО: Ja, ich habe auch darüber nachgedacht, aber kein Firefox-Add-On gefunden, das dies erreichen würde. Ich habe gerade eine [Frage bei Super User] geöffnet (http://superuser.com/q/584918/151741).
@unor [ModifyHeaders] (https://addons.mozilla.org/en-us/firefox/addon/modify-headers/) erlaubt jede Magie von HTTP-Headern :)
@ НЛО: In [ModifyHeaders] (https://addons.mozilla.org/en-us/firefox/addon/modify-headers/) werden alle benutzerdefinierten Header global gesendet. Ich habe keine Möglichkeit gefunden, dies einzuschränken, sodass nur der benutzerdefinierte Header für Anforderungen an meinen Host gesendet wird.
Neun antworten:
Adi
2013-04-08 17:17:03 UTC
view on stackexchange narkive permalink

obscurity

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.

Thomas Pornin
2013-04-08 20:40:28 UTC
view on stackexchange narkive permalink

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.

_ "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." _ ** Gold **
Kaz
2013-04-09 06:54:12 UTC
view on stackexchange narkive permalink

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

Danke für die Info :) Für meinen Fall reicht es jedoch aus, dass kein Inhalt / keine Seite sichtbar ist.
Wenn Sie einen 404 erhalten, ist die Site sichtbar. Wenn Sie möchten, dass die Site sichtbar ist, aber nur autorisierten Benutzern Inhalte zur Verfügung stellt, warum schützen Sie sie dann nicht einfach mit einem Passwort?
Ich dachte an die Standard-Server-404-Seite, die auch beim Besuch einer nicht vorhandenen Ressource wie "/ foobar" angezeigt wird.
Eine Möglichkeit ist eine Art Webklopfen. Der Benutzer besucht eine andere URL auf dem Server oder ein Muster bestimmter URLs. Die URLs ergeben alle 404, aber der Server notiert sich das Muster und zeigt diesem Client dann die Site der obersten Ebene an.
@unor Ihre Annahme ist richtig. Standardmäßig gibt der Webserver "404" aus, wenn keine Ressource vorhanden ist. Wenn ich mich umgesehen habe, um zu überprüfen, ob Sie etwas auf Ihrer Website haben und ich überall 404 bekomme, denke ich entweder, dass Sie etwas verstecken, oder ich komme einfach zu dem Schluss, dass Sie nichts haben. Aber in beiden Fällen werde ich keinen Beweis dafür haben, dass Sie tatsächlich etwas haben.
"Es muss nach SYN-Paketen suchen, die für Port 80 ankommen, und anhand der Nutzdaten feststellen, dass es sich um eine gültige HTTP-Anforderung für die zulässige URL handelt." Das ist nicht möglich. Die SYN-Anforderung * hat keine Nutzlast *. Sie müssen die Verbindung tatsächlich akzeptieren (antworten Sie mit SYN | ACK), bevor die Nutzdaten kommen.
@derobert Ups, du hast recht. Es ist ein paar Jahre her, seit ich mir TCP angesehen habe! Ich denke nicht, dass dies machbar ist: das heißt, vollständige "Funkstille" aufrechtzuerhalten, während basierend auf dem Inhalt entschieden wird, ob die Anfrage angenommen werden soll. Schade.
Manishearth
2013-04-09 12:44:11 UTC
view on stackexchange narkive permalink

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=abcdzugegriffen haben > (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
@Adnan: Ich habe diese Idee im Grunde genommen von diesen Whatchamacallit-Schlüsselanhänger-für-Bank-Konten :)
chrisc
2013-04-08 16:52:01 UTC
view on stackexchange narkive permalink

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.

Dies würde Alice jedoch immer noch den Anmeldebildschirm anzeigen, oder?
Wenn Sie die Lösung von Adnan übernehmen, bei der sich der Anmeldebildschirm auf einer anderen öffentlichen Website befindet, ist dies kein Problem.
Einverstanden, nur nicht so zu klagen Cross-Site-Scripting ist in der Tat die Antwort, da Sie dann eine verdammt starke Encyption-Schicht benötigen, um Mitm-Angriffe zu vermeiden.
Thomas Herlea
2013-04-08 19:00:22 UTC
view on stackexchange narkive permalink

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.

Es muss nicht annähernd so hässlich sein. Der Name Ihres Haustieres aus Kindertagen reicht aus. Heck, es kann ein Zeichen lang sein. Lassen Sie Ihren Server nur auf "example.com / x /" antworten. Wenn es einen Angreifer gibt, muss dieser Angreifer bereits über "example.com" Bescheid wissen und das Ziel war es, zu verhindern, dass dies überhaupt passiert!
Würde eine Timing-Analyse überhaupt funktionieren, wenn ich * jede * URL überprüfe? Die Site wird erst geladen, wenn der Referer der spezielle ist. Daher sollte der Ladevorgang für alle URLs gleich sein (für Benutzer ohne diesen Referer), oder irre ich mich?
Thomas Herlea
2013-04-08 19:08:10 UTC
view on stackexchange narkive permalink

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. :-)

Nicola Pesavento
2013-04-09 03:19:35 UTC
view on stackexchange narkive permalink

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'

gPlusHub.com
2013-04-09 14:50:09 UTC
view on stackexchange narkive permalink

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



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...