Sicherheitsrisiko-Liste 
In einigen Situationen kann es vorkommen, dass ein Framework oder eine Anwendung auf dem ABAP-Server Informationen von außen erhalten hat, die das Framework bzw. die Anwendung dann möglicherweise in den weiteren Verfahrensschritten bei der Interaktion mit dem Browser verwendet. Das Problem ist, dass diese extern empfangenen Informationen unter Umständen auch auf eine nicht vertrauenswürdige Website verweisen könnten. Als Beispiel kann die folgende Startup-URL dienen:
/myApplication?use-css-file=http://our.company.portal.com/ourTheme.css
In der Regel verwendet die Anwendung myApplication nun den für use-css spezifizierten String und rendert ihn innerhalb der HTML-Seite heraus, die an den Browser gesendet wurde, um dieses spezifische Style-Sheet zu laden. Im HTML wird daher die folgende oder eine ähnliche Sequenz angezeigt:
<html>
<header>
<css src=” http://our.company.portal.com/ourTheme.css”>
Dadurch lädt der Browser diese alternative CSS-Datei aus dem Unternehmensportal.
CSS-Dateien können jedoch auch JavaScript-Dateien enthalten und ausführen. Angenommen, eine solche Startup-URL ist im Internet verfügbar oder wird per E-Mail verschickt, und zwar in folgendem Format:
/myApplication?use-css-file=http://some.unknown.site.com/full.of.JavaScript.css
Wenn die Anwendung myApplication nun diesen für use-css spezifizierten String nimmt und ihn in HTML zum Browser heraus rendert. wird, sobald ein Benutzer auf diesen Link klickt, eine CSS-Datei geladen, die unter Umständen unbekannten JavaScript-Code ausführen kann.
Wie merkt die Anwendung myApplication, dass der für use-css spezifizierte Wert in einem gültigen Wertebereich liegt (also auf einen vertrauenswürdigen Server oder auf einen Server in einer vertrauenswürdigen Domäne verweist)? In diesem Fall ermöglicht die White-List-Infrastruktur der Anwendung, zu verifizieren, dass der Wert für use-css in einem vertrauenswürdigen Wertebereich liegt.
Tabelle HTTP_WHITELIST
Die Sicherheitsrisiko-Liste oder White-List ermöglicht es, URL-ähnliche Parameter vom Portal in den AS-ABAP zu integrieren. Dazu steht die Methode CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST zur Verfügung.
Die White-List an sich ist nur eine passive Infrastruktur und führt selbst keine sicherheitsrelevanten Aufgaben aus. Es handelt sich lediglich um einen Speicher, in dem Anwendungen oder Frameworks abgleichen können, ob die empfangenen Daten einer Reihe von konfigurierten Daten in einem gültigen Wertebereich zugeordnet werden können. Jede Anwendung und jedes Framework muss jedoch die Parameter prüfen, die extern gesetzt werden und dazu verwendet werden können, ein Rendering zum Browser durchzuführen. Mit Hilfe des API-Aufrufs verifiziert die Anwendung, ob die empfangenen Daten gültig sind.
Ein ähnliches Beispiel wäre eine Exit-URL, auf die die Anwendung nach einer erfolgreich abgeschlossenen Aufgabe navigiert:
/myApplication?exit-target=http://competitor.com/we.are.better.html
Wenn eine solche URL erstellt und im Internet hinterlegt wird, wird die Anwendung dazu veranlasst, zu nicht bekannten Ziel-URLs zu navigieren.
In all diesen Szenarios muss die Anwendung bzw. das Framework dafür sorgen, dass alle eingegangenen Daten und Informationen vor der Verwendung validiert werden. Bei Funktionen, die das zentrale Framework bereit stellt, muss das Framework selbst diese spezifischen URL-Parameter gegen die Whitelist abgleichen und so ermitteln, ob sie in einem gültigen Wertebereich liegen. Bei Business Server Pages (BSP) als Framework werden diese extern einstellbaren Parameter (sap-exiturl, sap-themeRoot) vor der Verwendung validiert. Wenn eine BSP-Anwendung selbst über zusätzliche Parameter mit ähnlichem Verhalten verfügt, muss die Anwendung selbst diese Parameter validieren.
In der White-List werden also Muster konfiguriert, mit denen URLs aus externen Quellen abgeglichen werden. Damit wird verifiziert, dass diese URLs akzeptabel sind. Die White-List ist in der Tabelle HTTP_WHITELIST gespeichert, die über Transaktion SE16 geändert werden kann.
Jeder Tabellensatz hat die folgende Struktur:
entry_type
URL-Typ, der mit diesem Eintrag abgeglichen werden soll.
Beispiel: CSS Off-box Referenz
Es gibt die folgenden Arten von entry_type:
entry_type White-List-Eintrag
Kurzbeschreibung
01
für Portal CSS Theme-URL
02
für sap-exiturl
03
für NetWeaver Business Client (NWBC)
10
für Web Dynpro Resume-URL
host
Hostname, der mit dem eingehenden Host verglichen wird. Dieses Feld ist leer, wenn der Hostname nicht für einen spezifischen Eintrag überprüft wird. Der Platzhalter (*) kann verwendet werden.
protocol
Zu überprüfendes Protokoll. In der Regel HTTP oder HTTPS. Dieses Feld kann leer sein, wenn keine Prüfung durchgeführt wird.
port
Zu überprüfende Portnummer. Darf nur aus Ziffern bestehen, leer lassen oder 0 für keine Prüfung (entspricht dem Asterisk *).
url
URL für die Prüfung gegen die eingehende URL. Der Platzhalter (*) kann verwendet werden. Die url entspricht dem absoluten Pfad.
Wenn keine Einträge in der Tabelle HTTP_WHITELIST vorliegen, werden keine Prüfungen durchgeführt.
Sobald die URL mit ihren einzelnen Bestandteilen vorhanden ist, wird sie gegen die Tabelle mit der White-List abgeglichen. Diese Tabelle enthält auch die einzelnen Bestandteile der URL, die eins nach dem anderen abgeglichen werden.
Mit dem entry-type können verschiedene Arten von White-Lists konfiguriert werden. Üblicherweise wird in einer White-List definiert, von welchem Server CSS-Themes geladen werden dürfen. Diese CSS-Themen werden geladen, indem ein mitgelieferter URL-Pointer im HTML generiert wird, der zurück auf den Portal-Server zeigt.
Wenn Parameter nicht spezifiziert sind, werden sie nicht abgeprüft. Es wird davon ausgegangen, dass sie übereinstimmen.
Wenn ein Maskierungszeichen (*) spezifiziert ist, wird es mit dem empfangenen String abgeglichen.
URL |
Standard-Port/Standard-Root |
|---|---|
http://myHost.myDomain.myExt:1080/myUrl |
|
http://myHost.myDomain.myExt/myUrl |
Standard-Port 80 |
https://myHost.myDomain.myExt/myUrl |
Standard-Port 443 |
http://myHost.myDomain.myExt:1080 |
Standard-Root url |
http://myHost.myDomain.myExt |
Standard-Root url |
/myUrl |
Keine Host-Daten angegeben |
Beispiel
whitelist-protocol = (empty string)
Hier wird implizit angegeben, dass das Protokoll nicht geprüft wird. Alle URLs in der Form http[s]://... oder /... werden durchgelassen, da nicht abgeprüft wird, ob ein Protokoll gesetzt wurde.
Beispiel
whitelist-protocol = *
Hier wird geprüft, ob das Protokoll mit irgendeinen Wert definiert wurde. Alle URLs in der Form http[s]://... werden durchgelassen. URLs in der Form /... werden jedoch nicht akzeptiert, da nach dieser Regel kein Protokoll verfügbar ist.
Beispiel
whitelist-protocol = https
Mit dieser Regel werden nur URLs in der Form https://... durchgelassen.
Im einfachsten Fall verwenden Sie einfach eine White-List mit leeren Feldern und führen gar keine Checks durch. Der Zweck der White-List-Tabelle ist es jedoch, einen vom Kunden benötigten Sicherheitsstandard zu bieten.
Beispielsweise können Sie einen Portal-Server haben, der URLs bereitstellt, die auf die Portal-Themes zeigen (CSS-Dateien). Auf einer ersten Sicherheitsebene könnten Sie einen White-List-Filter in der folgenden Form verwenden:
Syntax
protocol=*, host=*.myDomain.myExt, port=*, url=
Damit würden effektiv alle Referenzen auf anderen Maschinen in der gleichen Domäne akzeptiert.
Es ist auch ein Szenario möglich, nach dem die Last auf diesen einen Portal-Server eingeschränkt werden soll. Das sieht dann folgendermaßen aus:
Syntax
protocol=*, host=myPortal.myDomain.myExt, port=*, url=
Hier bestehen jedoch noch diverse Sicherheitslücken. Zum Beispiel kann auf dem gleichen Portal-Server auch noch ein Web-Server installiert sein. Der Portal-Server ist sicher, aber der Web-Server nicht unbedingt. Die URLs würden weiterhin die White-List passieren. Sie benötigen aber einen Standard-Eintrag, mit dem nur die URLs von dem Portal-Server akzeptiert werden. Daher sollten Sie immer sowohl das Protokoll als auch die Port-Angaben spezifizieren:
Syntax
protocol=http, host=myPortal.myDomain.myExt, port=1080, url=/*
protocol=https, host=myPortal.myDomain.myExt, port=1443, url=/*
Achtung
Standardmäßig ist die White-List-Tabelle leer und es werden keine Prüfungen durchgeführt. Es wird strengstens empfohlen, Regeln zu erstellen, da die Verwendung dieser Funktionalität ansonsten leicht durch böswillige URLs anfällig ist.
Achtung
Bitte beachten Sie, dass die neueste Version der Methode CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST die Regeln etwas anders als die vorherige Version verarbeitet. Daher kann es zu Problemen bei Anwendungen kommen, die mit vorherigen Versionen dieser Methode implementiert wurden.
Weitere Informationen finden Sie im Hinweis 1594641.
Hinweis
Version 7.31: Die Änderungen an der Methode CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST sind standardmäßig aktiv
vorherige Versionen: Die Änderungen an der Methode CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST sind standardmäßig deaktiviert und können durch einen Profilparameter aktiviert bzw. wieder deaktiviert werden.
Methode CHECK_HTTP_WHITELIST
Diese Methode prüft, ob eine empfangene URL mit einer White-List übereinstimmt, die in einer lokalen Datenbank abgelegt ist. Dabei ist die URL, die als Eingabeparameter dient, entweder eine absolute URL oder eine Server-spezifische absolute URL.