Sicherheitsaspekte von Web Dynpro für
Java
Während des Entwicklungsprozesses sowie des laufenden Betriebs von Web-Dynpro-Programmen ist es grundsätzlich wichtig, wie bei der Programmierung jeder Web-Applikation, die zur Verfügung stehenden Sicherheitsfunktionen zu integrieren. Bezüglich der Sicherheits-relevanten Aspekte einer Web-Dynpro-Anwendung lässt sich die folgende Kategorisierung vornehmen:
● Authentifizierung
● Sicherheit beim Model-Import
● Sicherheit von View-Context-Daten
● Frontend-Sicherheit
● Modifizierbare Benutzungsoberflächen-Elemente
● Überprüfen der generierten URLs durch den URL Generierungsservice
● Sicherheit von URL-Parametern
● Stack-Trace
● Web Dynpro Console
● Paßwort-Sicherheit
● Sicherheit von Web-Dynpro-Anwendungen im SAP NetWeaver (NW) Portal
Authentifizierung
Für die Web-Dynpro-Einheit Application, die für den Start der gesamten Anwendung zuständig ist, können Sie optional einstellen, ob Sie eine Authentifizierung vornehmen möchten, oder nicht. Die Einstellung der Authentifizierung ist Teil der Anwendungs-Konfiguration. Sie setzen das entsprechende Kennzeichen beim Anlegen einer Anwendungs-Einheit Application in der Web-Dynpro-Perspektive des SAP NetWeaver Developer Studio. Mit dem User Management Service prüfen Sie die Berechtigungen entsprechend ab, es stehen Ihnen hierfür verschiedene Schnittstellen und Methoden zur Verfügung.
Sicherheit beim Model-Import
Für die Bereitstellung der Daten für eine Web-Dynpro-Anwendung gibt es verschiedene Backend-Szenarien:
● SAP Business API (BAPI) (Adaptive RFC Model)
● Web Service (Web Service Model)
● XMI-Model (Web Dynpro Model from UML definition (XMI format))
BAPI-Backend
Beim Import eines Adaptive-RFC-Model greifen zunächst alle Sicherheitseinstellungen, die generell für die über RFC aufrufbaren BAPIs gelten. Beachten Sie außerdem die nachfolgenden Sicherheitsaspekte hinsichtlich eines RFC-Aufrufs: Das Einrichten eines lokalen oder zentralen SAP System Landscape Directory (SLD) ist Teil der Standard-Administration eines SAP-Systems. Wenn Sie Web-Dynpro-Anwendungen entwickeln, die sich mit einem statischen Benutzer gegen ein Backend verbinden, lassen sich durch den Einsatz des SLD zum Beispiel Paßwörter als Bestandteil des Web-Dynpro-Anwendungs-Codings vermeiden, da das SLD einen sicheren Secure-Storage für das Paßwort nutzt. Sie konfigurieren das SLD für die Web-Dynpro-Anwendungen mit Hilfe des Visual Administrator. Die Angaben zur logischen Destination nehmen Sie beim Importieren eines Adaptive-RFC-Modelim Anlege-Assistenten vor, spezielle Angaben zur Destination pflegen Sie im Web Dynpro Content Administrator. Die Verbindung an die Destination selbst erfolgt im Quellcode des Custom-Controller.
Web-Service-Backend
Informationen zu den Web Services und den Sicherheitsaspekten bei der Programmierung und Verwendung von Web Services sind Teil der Dokumentation zu den Web Services.
XMI-Model-Import
Beim Import eines externen UML-Models werden keine Sicherheits-relevanten Informationen verarbeitet, importiert oder gespeichert. Der Import erfordert lediglich eine .xmi-Datei, welche die Objektmodell-Schnittstelle beschreibt. Die Java-basierte Implementierung, die anhand bestimmter Namenskonventionen der Beschreibung in der XMI-Datei entsprechen muss, sowie die Metadaten enthalten keine Sicherheits-relevanten Daten.
Beachten Sie jedoch, dass es zur Laufzeit notwendig sein kann, eine Umgebung vorzubereiten, die zum Beispiel Verbindungen zu einem Backend zur Verfügung stellt, oder den aktuellen Benutzer kennen muss. Dadurch könnten zur Laufzeit Sicherheitslücken entstehen, die aber nicht durch den Model-Import nach Web Dynpro entstehen, sondern eine inherente Eigenschaft der jeweiligen Model-Implementierung darstellen.
Sicherheit von View-Context-Daten
Zentraler Bestandteil jeder Web-Dynpro-Anwendung sind die Daten, die im View-Context gehalten und verarbeitet werden. Die Benutzungsoberflächenelemente, die über den View Designer für die entsprechende View definiert worden sind, werden in der Regel vom Web-Dynpro-Anwendungsentwickler an die einzelnen View-Context-Elemente gebunden, damit ein Datenfluss zwischen Client und Server stattfinden kann. Es ist jedoch praktisch auch möglich, dass View-Context-Daten ungebunden im View-Context stehen. Dies kann zum Beispiel der Fall sein, wenn Daten aus bestehenden SAP Backend-Systemen verwendet werden, zum Zeitpunkt der Datenbindung jedoch noch nicht eindeutig ist, welche Attribute definitiv für die Web-Dynpro-Anwendung benötigt werden. Pro Backend-Business-API wird mehr als ein Java-Proxy, welches einer herkömmlichen Java-Klasse entspricht, generiert; jedoch werden manchmal nicht alle generierten Proxies beziehungsweise Model-Klassenfür die Anwendung benötigt. Der Web-Dynpro-Entwickler möchte jedoch meistens einen Controller-Context definieren, der auch optionale Elemente in die Context-zu-Model-Bindung mit einbezieht. In einem nachfolgenden Schritt werden diese optionalen Elemente dann in das Context-Mapping (z.B. zwischen View- und Custom-Context) mit einbezogen, um alle optionalen Daten kurzfristig zur Verfügung zu haben. Werden dann nicht alle Elemente dieser an das Model gebundenen Context-Struktur bei der Datenbindung verwendet, so wird empfohlen, die unbenutzten Context-Attribute so sicher zu machen, dass sie nicht unbeabsichtigt vom Client an den Server geschickt werden können.
Um diese Sicherheit zu erreichen, setzen Sie entweder in der Ansicht Properties die Attribut-Eigenschaft manuell auf readOnly = true, oder löschen Sie diese Attribute. Ansonsten kann ein unbefugter Zugriff über den Client auf den View-Context-Inhalt erfolgen. Die allgemeine Empfehlung lautet, dass nur diejenigen Daten, deren Änderung unkritisch ist, im View-Context stehen dürfen.
Frontend-Sicherheit
Das Web Dynpro Rendering Framework enthält auch JavaScript am Client einschließlich zahlreicher, Web-Dynpro-spezifischer Erweiterungen, die zu einer erhöhten Sicherheit der gesamten Web-Dynpro-Anwendung beitragen. Bezüglich des Kommunikationsprotokolls sowie der Integration von Dateien von Drittanbietern für die Datenausgabe beachten Sie Folgendes:
● HTTPS
Damit die Web-Dynpro-Anwendungen im Browser sicher laufen, empfehlen wir Ihnen, das Kommunikationsprotokoll Secure HTTP (HTTPS) zu verwenden. Für eine Verwendung von HTTPS für Web Dynpro setzen Sie im Visual Administrator das entsprechende Kennzeichen. Die Web-Dynpro-Anwendung kann dann auf demjenigen Port, der für die HTTPS-Verbindung eingetragen wurde, laufen.
● Office-Integration und Verwendung von Adobe-Formularen
Für den Fall, dass Sie Microsoft Office-Dokumente oder Adobe-Formulare für die Ausgabe verwenden, empfehlen wir Ihnen, aus Sicherheitsgründen nur Dokumente mit Signatur zu verwenden. Informationen zu den Signatur-Technologien können Sie der Homepage des jeweiligen Herstellers entnehmen. Sicherheitsrelevante Einstellungen hinsichtlich User Management und SSL-Verbindungen sind im Interactive Forms Security Guide hinterlegt. Der Configuration Guide Adobe Document Services liefert eine Beschreibung der Konfigurationschritte zum Einrichten der erforderlichen Benutzer und verschiedenen Kommunikationsverbindungen, zur Installation und Konfiguration der Zertifikate für SSL-Verbindungen, Signaturen und Zertifizierung (SAP Service Marketplace, http://service.sap.com/instguides).
Modifizierbare Benutzungsoberflächen-Elemente
Wenn die Web-Dynpro-Anwendung die Modifikation der Angabe von Höhen und Breiten der width- und height-Attribute von Controls durch den Endanwender zulässt, dann ist zu beachten, dass die eingegebenen Werte zur Laufzeit nicht per Default validiert werden. Ansonsten könnten zur Laufzeit dynamisch Werte gesetzt werden, die ungewollte JavaScript-Befehle enthalten. Diese Befehle würden ausgeführt werden, wenn das Oberflächen-Element im Browser ausgegeben wird. Der Endanwender sollte daher möglichst weder Höhe noch Breite eines Benutzungsoberflächen-Elements modifizieren dürfen. Es könnte sonst sein, dass über ein ungeprüftes Eingabefeld die dynamisch gesetzten Werte eingespielt und dann auch von einem anderen Endbenutzer verwendet werden. Das JavaScript-Coding könnte dann in der Sitzung des zweiten Nutzers ausgeführt werden. Wir empfehlen Ihnen, auf jeden Fall alle Werte zu validieren, wenn zur Laufzeit width- oder height-Attribute gesetzt werden. Diese Maßnahme ist vor allen Dingen auch dann wichtig, wenn diese width- oder height-Attribute gegen den Context gebunden sind, da keinesfalls ungeprüfte Daten in den Context gelangen dürfen.
Überprüfen der generierten URLs durch den URL Generierungs-Service
Während des Generierungsprozesses überprüft der Generierungsservice die URL hinsichtlich unzulässiger JavaScript-Tags beziehungsweise unbekannter, nicht vordefinierter Protokolle. Der Administrator hat die Möglichkeit, die Liste der zulässigen Protokolle vorab zu konfigurieren, und zwar über den Parameter sap.url.protocols derdefault.properties-Datei. Per Default unterstützt der Generierungs-Service die Protokolle HTTP, HTTPS sowie FTP.
Sicherheit von URL-Parametern
Eine Web-Dynpro-Anwendung kann nach zwei verschiedenen Modellierungs-Ansätzen konzipiert werden: Zum Einen kann der Anwendungsentwickler eine komplexe Anwendung in mehrere kleine Anwendungen aufteilen, die sich gegenseitig rufen können. Oder die Anwendung mit verschieden gelagerter Logik kann nach ablaufrelevanten Aspekten in Web-Dynpro-Komponenten gegliedert und entsprechend programmiert werden. Im erstgenannten Fall muss darauf geachtet werden, dass die Navigation hin zu einer Anwendung über eine zweite aufrufende Anwendung immer mit korrekten, validen und nicht sicherheitsrelevanten, also sichtbaren, Parametern erfolgt.
Theoretisch wäre es auch möglich, die Anwendung frei nach Belieben zu adressieren, das heißt, man kann dem URL-Parameter einen ungültigen Wert mitgeben. Um ein solches unerlaubtes Übergeben von URL-Parametern an die Web-Dynpro-Anwendung zu verhindern, ist es erforderlich, dass Sie die Gültigkeit der Parameter überprüfen und für die laufende Anwendung festlegen. Wir empfehlen Ihnen, grundsätzlich die Verwendung sicherheitsrelevanter Parameter in der URL zu vermeiden. Das bedeutet, dass der Web-Dynpro-Anwendungsentwickler grundsätzlich die verwendeten Parameter selbst definiert und diese gültigen Werte der Anwendung zuordnen muss. Sie sollten daher die Anwendungslogik im Ereignisbehandler zum Startup-Plug des über eine URL addressierten Interface-Views so programmieren, dass dieser missbräuchliche Requests abfängt, zum Beispiel den Wert nicht im Context abspeichert und auf Validität prüft.
Da Parameter über die spezifizierte URL der Web-Dynpro-Anwendung gesetzt werden können, bedeutet die Integration einer Web-Dynpro-Anwendung in ein SAP NW Portal eine Erhöhung der Sicherheit der gesamten Anwendung, da innerhalb des Portals kein direkter Zugang zur URL der Web-Dynpro-Anwendung gegeben ist.
Stack-Trace
Für eine ausführliche Fehleranalyse in der Web-Dynpro-Anwendung gibt es neben der Möglichkeit, einen Log in eine Log-Datei wegzuschreiben, außerdem die Option, sich einen Java Stack-Trace ausgeben zu lassen. Für die Ausgabe des Stack-Trace einer Java Web-Dynpro-Anwendung setzen Sie den Anwendungs-Konfigurationsparameter Development Mode auf True.
Da mit dem Parameterwert DevelopmentMode = true auch die Versionsinformationen vieler Komponenten, einschließlich des Betriebssystems, zum Client übertragen werden, wären gezielte Angriffe auf einen Rechner unter Ausnutzung dieses Sicherheitslochs möglich. Setzen Sie daher den Parameter Development Mode auf False, wenn Sie Sicherheits-relevante Daten haben und diese schützen müssen.
Außerdem bildet der Java Stack-Trace während der Ausgabe auch den relativen Pfad zu den Kontextdaten ab („Cannot find file …“). Wir empfehlen Ihnen daher, für den Parameter Development Mode auch dann den Wert False zu setzen, wenn Sie vermeiden möchten, dass der Pfad während der Fehlersuche gelesen werden darf. Für die Ausgabe der Fehlerseite wird dann kein Stack-Trace mehr gerendert, sondern die allgemeine generische Meldung „Error occured. Please contact your system administrator.“ für den Benutzer sichtbar.
Web Dynpro Console
Wenn der Web-Dynpro-Konfigurationsparameter Development Mode auf False gesetzt ist, wie in Abschnitt „Stack Trace“ beschrieben, bleiben dennoch alle Versions-Informationen, wie zum Beispiel zu Web-Dynpro-Laufzeit, Java Development Kit (JDK) oder Client, dem Administrator über Web-Dynpro-Console-Befehle zugänglich. Der Administrator kann nun mit Hilfe dieser Console-Befehle die Versions-Informationen wie das Server-Betriebssystem oder die Java-Version, die bei jedem Request in die HTML-Ausgabe geschrieben werden, anderen Benutzern zugänglich machen. Diese Benutzer können dann die Informationen ebenfalls über die Web-Dynpro-Console abgreifen.
Paßwort-Sicherheit
Im Falle einer Paßwort-Abfrage für den Zugang zum Server wird die Information, die an den View-Context gebunden ist, zum SAP NetWeaver Application Server transportiert und wieder zum Browser zurück, wenn dieselbe View nochmals angezeigt wird. Das Paßwort-Eingabefeld, das an ein Context-Attribut vom Typ String gebunden ist, wird nur in nicht-lesbarer Form angezeigt. Jedoch erfolgt die Übergabe beim Datenaustausch an den NetWeaver Application Server in lesbarer Form.
Um eine unerlaubte Paßwort-Identifikation zu verhindern, sollte der Web-Dynpro-Anwendungs-Programmierer das Paßwort an ein zweites Context-Attribut, das nicht am Datenfluss zwischen View und Server beteiligt ist, übergeben. Eine zweite Möglichkeit, die Paßwort-Abfrage zu verhindern, besteht darin, das Feld unlesbar zu machen, indem es auf (****) gesetzt wird.
Beachten Sie auch, dass das Paßwort beim Tracing ebenfalls lesbar angezeigt werden könnte, dies ist von den jeweiligen Tracing-Einstellungen abhängig. Die Paßwort-Abfrage ist dann zwar ausschließlich durch denjenigen Entwickler möglich, der sich über das Paßwort authentifiziert hat; dennoch möchten wir auf diese Möglichkeit hinweisen.
Sicherheit von Web-Dynpro-Anwendungen im SAP NetWeaver Portal
Die SAP NetWeaver Technologie-Plattform ermöglicht standardisierten Zugriff auf Benutzer-Informationen. Rollen und Berechtigungen, die für das SAP NW Portal 6.0 eingesetzt werden, stehen automatisch für eine als iView eingebettete Web-Dynpro-Anwendung zur Verfügung. Die Web-Dynpro-Applikation und SAP NW Portal 6.0 können dabei den selben User Store verwenden. Für den Zugriff auf die Benutzerdaten kann sich die Java API der User Management Engine (UME) gegen ein LDAP-Verzeichnis, eine externe Datenbank oder die SAP Benutzerverwaltung konnektieren. Für die ins NetWeaver Portal integrierten Web-Dynpro-Anwendungen steht die Anmeldemethode Single Sign-On zur Verfügung. Für den Fall, dass die ins Portal integrierte Web-Dynpro-Anwendung auf mehrere Backends zugreift, also die multiple Backend-Unterstützung nutzt, berücksichtigen Sie die Aspekte der Sicherheit von logischen Systemen.