Frage:
Wie sicher ist die Weiterleitung zu einer anderen Site?
alex067
2018-04-12 08:17:46 UTC
view on stackexchange narkive permalink

Nehmen wir an, ich habe eine Website unter https://example.com/test . Wenn jemand auf diese Site zugreift, möchte ich ihn einfach zu https://example.com/Test umleiten.

Gibt es hier mögliche Schwachstellen? Oder ist diese Methode sicher, da ich nur von einer gesicherten Site zu einer anderen umleiten werde?

Handelt es sich nur um eine Weiterleitung von einer Site zu einer anderen, oder deuten Sie auf eine Regel hin, wie Sie je nach Groß- und Kleinschreibung umleiten?
Sie fragen nach "einer anderen Site", aber diese sieht im Allgemeinen wie dieselbe Site aus.
Sie fragen "eine andere Site", geben aber Beispiele für dieselbe Site an.Können Sie klarstellen, was Sie meinen?
Um die Kommentare von @chrylis und EthanKaminski zu erläutern, wird der Begriff "Site" im Allgemeinen für eine Domain verwendet, während sich "Seite" auf eine bestimmte Adresse bezieht."Https: // example.com / test" und "https: // example.com / Test" sind also verschiedene Webseiten auf der Website "https: // example.com".
Diese Methode könnte Sie interessieren: [`history.replaceState (null, document.title, 'Test');`] (https://developer.mozilla.org/en-US/docs/Web/API/History_API#The_replaceState () _ Methode)
@Acccumulation: Obwohl dies nicht besonders aussagekräftig sein mag, habe ich das Gefühl, dass es einer Klärung bedarf: `https: // example.com` ist keine [Domain] (https://en.wikipedia.org/wiki/Domain_name), sondern ein [URL] (https://en.wikipedia.org/wiki/URL) (oder allgemeiner eine URI, die eine Obermenge von URLs und URNs ist).Und ich bin mir nicht sicher, ob man sagen kann, dass "(Web-) Site" verwendet wird, um auf die Startseite a.k.a. [Homepage] (https://en.wikipedia.org/wiki/Home_page) zu verweisen.Darüber hinaus können sich ganze Websites (und beliebig viele davon) auf einer beliebigen URL befinden, nicht nur auf der URL, die nach dem Schrägstrich hinter der Domain nichts mehr enthält.
@phresnel-URLs werden zur Identifizierung von Domänen verwendet.Ich habe nicht gesagt, dass "Site" auf die Homepage verweist;"https://example.com/test und https://example.com/Test sind unterschiedliche Webseiten auf der Website https://example.com."bedeutet eindeutig, dass die Site nicht nur die Homepage ist, sondern auch andere Seiten.
@Accumulation: `URLs werden zur Identifizierung von Domains verwendet`: Dies ist nicht sinnvoller als" Autos identifizieren Nummernschilder "oder" Fahrräder sind an Bremsen montiert ".Eine Domain ist nur ein möglicher Teil einer URL.In stark vereinfachter Form lautet eine URL wie folgt: `[Schema]: // [Domäne] / [Pfad]` (Vollständige Definitionen finden Sie unter den zuvor angegebenen URLs).
Fünf antworten:
CaffeineAddiction
2018-04-12 11:16:52 UTC
view on stackexchange narkive permalink

/ test und / Test werden beide auf example.com gehostet. Es handelt sich also nur um eine Seitenumleitung, nicht um eine Domainumleitung. Dies ist kein Problem.

Die Leute leiten die ganze Zeit so um, zum Beispiel ist die Umleitung von HTTP zu HTTPS zu diesem Zeitpunkt so ziemlich Industriestandard.

Die Ausnahme wäre, wenn eine Domain unterteilt wurde.Z.B.Benutzer1 hat die Kontrolle über "example.com / user1" und Subdomains, Benutzer2 hat die Kontrolle über "example.com / user2" und Subdomains usw. Und theoretisch, wenn die Zeichenfolge "https://example.com/test" dynamisch generiert wird, das könnte eine Sicherheitsanfälligkeit für Injektionen eröffnen.
könnte sein?Aber eine Weiterleitung gewährt Ihnen nicht automatisch die Erlaubnis ... wenn ich von /index.html nach /superTopsecretKittys.html umgeleitet werde ... werde ich immer noch eine "401 Unauthorized" erhalten
Ja, aber es wirft Phishing-Probleme auf.Wenn ich einen Injektionsangriff ausführen kann, bei dem eine Website Benutzer auf meine Website umleitet, lautet die Meldung "Hoppla, es liegt ein Fehler vor, Sie müssen Ihre Anmeldeinformationen erneut eingeben".
Das ist ein ganz anderes Problem ... wenn Sie jemandem etwas in die Website einfügen ... haben sie größere Probleme als eine einfache Weiterleitung.
Ich würde HTTP zu HTTPS hier nicht erwähnen.Dabei gibt es einige Schwachstellen, die für die Beschreibung des OP nicht relevant sind.
Abgesehen davon hat die Umleitung von HTTP zu HTTPS viel mehr Überlegungen als eine "Standard" -Umleitung.Sie sind möglicherweise sehr anfällig für SSL-Stripes. Wenn Sie eine solche Umleitung durchführen, möchten Sie mit ziemlicher Sicherheit die HSTS-Vorlast und die Schwächen dieser Methode untersuchen.Wohlgemerkt, selbst mit HSTS sind Sie potenziell anfällig für SSL-Stripes mit einer ähnlichen Domain ...: /
tim
2018-04-12 11:55:28 UTC
view on stackexchange narkive permalink

Richtig implementiert, gibt es keine Probleme damit.

Es gibt zwei Dinge, auf die Sie achten sollten (ich gehe davon aus, dass test hier nicht statisch ist, sondern vom Benutzer bereitgestellt wird. Sie möchten also beispielsweise jeden Pfad in Großbuchstaben schreiben.)

  • Open Redirect: Wenn Ihre Weiterleitung falsch implementiert ist, kann ein Angreifer möglicherweise außerhalb Ihrer Domain umleiten, was verwendet werden könnte bei Phishing-Angriffen
  • CSRF: Wenn Ihr CSRF-Schutz nur eine einfache Referer-Prüfung ist (was nicht empfohlen wird) und wenn Sie Status ändernde GET-Anforderungen haben (was auch nicht empfohlen wird), kann dies sein Abhängig von Ihrer Implementierung des Umleitungsmechanismus
möglich
Suraj
2018-04-12 11:55:10 UTC
view on stackexchange narkive permalink

Das Umleiten von Benutzern auf eine andere Seite oder Domain ist eine normale Praxis, die von vielen Entwicklern befolgt wird (sogar MNCs, einschließlich FB, fb.com leitet auf facebook.com um). Es schadet nicht, wenn Sie versuchen, Anforderungen auf sichere Weise umzuleiten.

Möglicherweise möchten Sie das OWASP-Spickzettel auf nicht validierte Weiterleitungen und Weiterleitungen überprüfen (auch als offene Umleitung bezeichnet). Dieses Dokument bietet sichere Möglichkeiten zum Umleiten von URLs in mehreren Programmiersprachen.

apoorv kapil
2018-04-12 14:48:48 UTC
view on stackexchange narkive permalink

Soweit Hostname gleich bleibt und Ihr Benutzer ihm vertraut. Dies sollte kein Problem sein.

Diese Art der Umleitung ist im Internet üblich und trägt zu einer besseren Benutzererfahrung bei.

Zum Beispiel:

Sie haben eine Ressource unter https://testwebsite.com/Test , die jedoch aufgrund eines Tippfehlers oder eines Entwicklerfehlers als https://testwebsite.com/test geschrieben wurde . Die Umleitung hilft dem Benutzer, eine geeignete Datei anzuzeigen, anstatt einen 404-Datei nicht gefunden -Fehler oder einen internen Serverfehler zu sehen.

suhas.gaikwad
2018-04-12 15:07:10 UTC
view on stackexchange narkive permalink

    Weiterleitung innerhalb derselben Domain - kein Risiko. (weil Ihre Domain vertrauenswürdig ist)

    Beispiel: https://domain.com/login Weiterleiten an https://domain.com/dashboard

  1. Die Weiterleitung auf Websites von Drittanbietern birgt ein mittleres Risiko, wenn vertrauliche Daten wie access_token und geheime Schlüssel auf Websites von Drittanbietern verloren gehen.

    Beispiel: https://domain.com/redirect_to_fb leitet den Benutzer zu https://fb.com

    li
  2. Angreifergesteuerte Weiterleitungsleitungen weiter zu:

    a. Phishing https://domain.com/login?redirect_to=http://evil.com

    b. XSS-Problem (Cross Site Scripting): https://domain.com/login?redirect_to=javascript:alert(document.cookie)

    c. Undichte Token Beispiel: https://domain.com/login?redirect_to=https://attackerdomain.com Beispiel: https://r0rshark.github.io/2015/09/15 / microsoft /

    d. Umgehen der Inhaltssicherheitsrichtlinie

    e. Bypass für Referrer-Prüfung

    f. URL-Whitelist-Bypass

    g. Angular ng-include-Bypass

    ol>

    Wenn ein Angreifer die Umleitung steuern kann, ist dies ein ernstes Problem.

Leider verbessert die Bearbeitung die Antwort nicht.


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