This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Germany/Projekte/Top 10 fuer Entwickler-2013/A10-Ungeprüfte Um- und Weiterleitungen

From OWASP
Revision as of 16:31, 27 February 2016 by T.Gigler (talk | contribs) (letzten Headertab 'für weitere Programmiersprachen' auskommentiert, unbenutzte Boxen bei JAVA gelöscht)

Jump to: navigation, search
← A9-Nutzung von Komponenten mit bekannten Schwachstellen
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Nächste Schritte für Software-Entwickler →
A10 Ungeprüfte Um- und Weiterleitungen


Bedrohungsquellen
Angriffsvektoren
Schwachstellen
Technische Auswirkung
Auswirkung auf das Unternehmen
Anwendungs-
spezifisch
Ausnutzbarkeit
DURCHSCHNITTLICH
Verbreitung
SELTEN
Auffindbarkeit
EINFACH
Auswirkung
MITTEL
Anwendungs-/
Geschäftsspezifisch
Angreifer, der einen Nutzer über eine beliebige Website oder HTML-Seite dazu verleitet, eine Anfrage an Ihre Website zu starten. Das können beliebige Webseiten oder HTML-Feeds sein. Nutzer klicken auf scheinbar seriöse Links von einem Angreifer, die auf bösartige Sites umleiten (Redirects). Durch unsichere Weiterleitungen kann ein Angreifer Sicherheits-prüfungen umgehen (Forwards). Anwendungen nutzen regelmäßig Weiter- oder Umleitungen, um Nutzer auf andere Seiten umzulenken. Manchmal verwendet die angegriffene Seite ungeprüfte Parameter für Umleitungen, so dass Angreifer die Zielseiten selbst festlegen können. Ungeprüfte Umleitungen zu entdecken ist einfach: Suchen Sie nach Redirects, die die Angabe von URLs erlauben. Ungeprüfte Weiterleitungen zu finden ist schwieriger, da sie auf interne Seiten verweisen. Umleitungen können Schadsoftware installieren und Nutzer verleiten, Passwörter oder sensible Daten offenzulegen. Unsichere interne Weiterleitungen ermöglichen es, Zugangskontrollen zu umgehen. Was bedeutet Ihnen das Vertrauen Ihrer Kunden? Was ist, wenn deren PCs wg. Schadsoftware infiziert werden? Was passiert, wenn Angreifer auf nicht-öffentliche Funktionen zugreifen können?
Mögliche Angriffsszenarien

Szenario 1: Die Anwendung enthält eine Seite namens "redirect.jsp", die einen einzigen Parameter "url" verwendet. Der Angreifer setzt eine URL als Parameterwert ein, die den Nutzer auf eine Website führt, die Schadcode installiert oder Phishing ermöglicht:

http://www.example.com/redirect.jsp?url=evil.com

Szenario 2: Die Anwendung verwendet interne Umleitungen, um Anfragen auf unterschiedliche Bereiche der Website weiterzureichen. Um dies zu erleichtern, können Parameter verwendet werden, um festzulegen, auf welchen Bereich der Nutzer im Erfolgsfall umgeleitet wird. In diesem Fall schleust der Angreifer eine URL als Parameter ein, die die Zugangskontrollen der Anwendung umgeht und anschließend den Angreifer auf einen administrativen Bereich leitet, auf den er normalerweise keinen Zugriff hätte.

http://www.example.com/boring.jsp?fwd=admin.jsp
Wie kann ich 'Ungeprüfte Um- und Weiterleitungen' verhindern?

Ein sicherer Einsatz von Weiter- und Umleitungen kann auf unterschiedliche Weise realisiert werden:

  1. Weiter- und Umleitungen schlichtweg vermeiden.
  2. Falls eingesetzt, verwenden Sie keine Nutzerparameter um die Ziel-URL zu berechnen. Das ist i.d.R möglich.
  3. Falls Zielparameter nicht vermeidbar sind, stellen Sie sicher, dass die Parameter gültig und die Nutzer dafür autorisiert sind. Es wird empfohlen, dass Sie jegliche Ziel-URL-Parameter mittels Zuordnungslisten erstellen, statt die echte URL oder einen Teil davon zu verwenden. Serverseitig wird der Parameter dann mit Hilfe dieser Liste der korrekten Zieladresse zugeordnet. Setzen Sie ESAPI ein, um die sendRedirect()-Methode zu überschreiben und so alle Umleitungen abzusichern.

Es ist extrem wichtig, diese Mängel zu vermeiden, da es sich um beliebte Ausgangspunkte für Phishing-Angriffe handelt.

Verteidigungs-Option 1 gegen 'Ungeprüfte Um- und Weiterleitungen':

Referer prüfen

Bevor eine Um- oder Weiterleitung sattfindet sollte geprüft werden, von welcher Seite die aktuelle Anfrage gestellt wurde. Dies erfolgt durch Auswertung des Referers im HTTP Header.

String referer = request.getHeader("referer");
if request.getRequestURL().toString().startsWith(referer)

// Umleitung durchführen;


Verteidigungs-Option 2 gegen 'Ungeprüfte Um- und Weiterleitungen':

Whitelisting

Soweit möglich sollten keine beliebigen Um- oder Weiterleitungen über eine Webseite möglich sein. Insbesondere externe URLs sollten möglichst ausgeschlossen werden.

Sofern auch externe Weiterleitungen erfolgen sollen empfiehlt es sich, die legitimen Domänen in einer Whitelist explizit zu benennen und alle anderen zu blockieren.

tbd

tbd
tbd
Verteidigungs-Option 3 gegen 'Ungeprüfte Um- und Weiterleitungen':

Verschleierung mittels Token

Bei einer Weiterleitung mit expliziter Angabe des Ziels ist direkt ersichtlich, dass durch einen manipulierten Link vermutlich eine Schwachstelle ausgenutzt werden kann.

http://www.example.com/redirect.jsp?url=evil.com

Statt das Ziel explizit anzugeben ist es besser, dieses über geeignete Token zu verschleiern. Eine URL mit Weiterleitung würde also entgegen dem vorigen Beispiel so aussehen:

http://www.example.com/redirect.jsp?url=JW3JF82MQ29CEH2N

Innerhalb der Webanwendung wird das Token dann in die eigentliche URL transformiert. Dies erfolgt beispielsweise durch Verwendung einer Tabelle.

Referenzen

OWASP

Andere

« JAVA    
Verteidigungs-Option 1 gegen 'Ungeprüfte Um- und Weiterleitungen':

Referer prüfen

Bevor eine Um- oder Weiterleitung sattfindet sollte geprüft werden, von welcher Seite die aktuelle Anfrage gestellt wurde. Dies erfolgt durch Auswertung des Referers im HTTP Header.

$referer = $_SERVER['HTTP_REFERER'];
$serverName = $_SERVER['SERVER_NAME'];
$lengthServerName = strlen($serverName);
if (substr($referer, 0, $lengthServerName) == $serverName) {

// Umleitung durchführen;


Verteidigungs-Option 2 gegen 'Ungeprüfte Um- und Weiterleitungen':

Whitelisting

Soweit möglich sollten keine beliebigen Um- oder Weiterleitungen über eine Webseite möglich sein. Insbesondere externe URLs sollten möglichst ausgeschlossen werden.

Sofern auch externe Weiterleitungen erfolgen sollen empfiehlt es sich, die legitimen Domänen in einer Whitelist explizit zu benennen und alle anderen zu blockieren.

tbd

tbd
tbd
Verteidigungs-Option 3 gegen 'Ungeprüfte Um- und Weiterleitungen':

Verschleierung mittels Token

Bei einer Weiterleitung mit expliziter Angabe des Ziels ist direkt ersichtlich, dass durch einen manipulierten Link vermutlich eine Schwachstelle ausgenutzt werden kann.

http://www.example.com/redirect.jsp?url=evil.com

Statt das Ziel explizit anzugeben ist es besser, dieses über geeignete Token zu verschleiern. Eine URL mit Weiterleitung würde also entgegen dem vorigen Beispiel so aussehen:

http://www.example.com/redirect.jsp?url=JW3JF82MQ29CEH2N

Innerhalb der Webanwendung wird das Token dann in die eigentliche URL transformiert. Dies erfolgt beispielsweise durch Verwendung einer Tabelle.

Referenzen

OWASP

Andere

« PHP    
Verteidigungs-Option 1 gegen 'Ungeprüfte Um- und Weiterleitungen':

(Beispiel bisher unbearbeitet)

var id = Request.QueryString["Id"]; Guid idGuid; if (!Guid.TryParse(id, out idGuid))
{

// Gracefully exit with a warning message

}

var db = new MyTrustedSiteEntities();
var allowableUrl = db.AllowableUrls.SingleOrDefault(u => u.Id == idGuid);
if (allowableUrl == null)
{

// Gracefully exit with a warning message

}

LogRedirect(allowableUrl.Url);
Response.Redirect(allowableUrl.Url);

Quelle: OWASP Top 10 for .NET developers part 10: Unvalidated Redirects and Forwards

Verteidigungs-Option 2 gegen 'Ungeprüfte Um- und Weiterleitungen':

Tbd

tbd

tbd
tbd
Verteidigungs-Option 3 gegen 'Ungeprüfte Um- und Weiterleitungen':

Tbd

tbd

tbd
tbd
Referenzen

OWASP

Andere

« .NET    
Verteidigungs-Option 1 gegen 'Ungeprüfte Um- und Weiterleitungen':

Unabhängig von der verwendeten Programmiersprache sollte die Wahrscheinlichkeit verringert werden, dass ein Angreifer eine Webseite für die Um- bzw. Weiterleitung finden kann. Hierzu sollte insbesondere vermieden werden, dass die jeweilige Seite über Suchmaschinen gefunden werden kann. Dies kann durch die robots.txt konfiguriert werden.

User-Agent: *
Disallow: /util/redirect.jsp

Referenzen
← A9-Nutzung von Komponenten mit bekannten Schwachstellen
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Nächste Schritte für Software-Entwickler →

© 2002-2017 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png