Top 20 Sicherheitsrisiken in ABAP Anwendungen

Top 20 Sicherheitsrisiken in ABAP
Anwendungen
Detail-Level Ausarbeitung
Version 0.5
Oktober 2014
Version 1.0 | Juli 2014
Einführung
Dieses Dokument liefert detaillierte Informationen über die häufigsten und gefährlichsten Sicherheitsrisiken,
die in ABAP Programmen anzutreffen sind.
Es soll ABAP Entwicklern und Sicherheitstestern relevante technische Risiken aufzeigen, die sich durch
ABAP Eigenentwicklungen ergeben. Insbesondere liefert es Anleitungen, die Risiken zu mitigieren.
Die Einstufung der Risiken basiert auf den Ergebnissen jahrelanger Sicherheitsforschung im SAP/ABAP
Umfeld, dem BIZEC APP/11 Standard* und einer statistischen Auswertung der Schwachstellen aus über 170
SAP Installationen** in deutschen Unternehmen. Im Dokument verwendete Zahlen und Informationen, die
dieser statistischen Auswertung entspringen, sind mit <STAT> markiert.
Die in diesem Dokument behandelten Sicherheitsfehler stellen aus Sicht des Autors den aktuellen Stand der
Forschung der relevantesten Sicherheitsrisiken im ABAP Umfeld dar.
Die meisten dieser Risiken können sich negativ auf die Generellen IT Kontrollen (IT General Controls /
ITGC) auswirken, da sie das Change Management betreffen. Das kann in Audits unangenehme
Konsequenzen haben, da praktisch alle Compliance Standards auf den ITGC basieren.
Entsprechende Kenntnisse in ABAP und im Umgang mit ABAP Entwicklungswerkzeugen sind
Voraussetzung für das Verständnis dieses Dokuments.
*
http://www.bizec.org/wiki/BIZEC_APP11
** https://www.virtualforge.com/de/labs/benchmark.html
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
-2-
ABAP Sicherheit
Generelle Hinweise
Nur etwa 0,3%<STAT> aller ABAP Anwendungen in Kundenimplementierungen sind Webanwendungen.
Entsprechend sind Web-spezifische Schwachstellen (fast) nicht im Fokus dieses Dokuments. Die bedeutet
auch, dass Web-spezifische Sicherheitslösungen wie z.B. Web Application Firewalls die speziellen
Sicherheitsrisiken von ABAP Anwendungen fast ausnahmslos nicht mitigieren können.
Die Sicherheit Ihrer ABAP Anwendungen beginnt in den Köpfen Ihrer Entwickler und Tester. Es sind daher
regelmäßige Schulungen für Entwickler und Tester notwendig, um diese zu sensibilisieren. Schulungen sind
eine Grundvoraussetzung, um dauerhaft die TOP Sicherheitsrisiken in ABAP Code zu verhindern. Fordern
Sie gegebenenfalls auch entsprechende Nachweise von Zulieferern ein.
Bei der großen Menge an Eigenentwicklungen - im Schnitt 2,2 Millionen Zeilen <STAT> Code pro System - und
dem steten Wandel in dem sie sich befinden, ist es in der Praxis nicht möglich/rentabel den Code vollständig
manuell auf Schwachstellen zu untersuchen. Es empfiehlt sich daher zusätzlich Tools einzusetzen, die den
Quellcode automatisiert regelmäßig auf Schwachstellen prüfen. Tools finden nicht alle Fehler. Aber sie sind
ein effizientes Mittel, zumindest bestimmte Arten von Fehlern effizient aufzuspüren.
Alle in diesem Dokument dargestellten Risiken können durch ein gutes statisches Codeanalyse-Werkzeug
erkannt werden.
Es ist elementar wichtig zu verstehen, dass bereits ein Sicherheitsfehler im ABAP Code ausreichen
kann, um die Sicherheit sämtlicher Geschäftsdaten eines ganzen SAP Systems vollständig zu
kompromittieren. Jedes SAP System enthält 9<STAT> solcher hochkritischen Fehler.
Sicherheitsbereiche
Die Sicherheitsrisiken sind verschiedenen, logisch zusammengehörigen Bereichen zugeordnet.
Bereich
Kürze Beschreibung
l
Berechtigunge AUTH Alle Geschäftsprozesse müssen ausreichend durch formal korrekte
n
Berechtigungsprüfungen abgesichert sein.
Testbarkeit
TEST
Sämtliche Programme müssen testbar und sämtlicher Quellcode für
Audits einsehbar sein.
Datenschutz
DAT
ABAP Code darf kritische Daten ohne Berechtigungsprüfung weder
anzeigen noch aus dem Schutzbereich des SAP Systems verschieben.
Injection
INJ
Schwachstelle
n
Sämtliche Eingaben müssen hinreichend von Schadcode befreit werden,
bevor sie in potentiell gefährlichen ABAP Befehlen verwendet werden.
Standard-Schu MECH Vorhandene SAP Sicherheitsmechanismen dürfen durch ABAP Code nicht
tz
umgangen werden.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
-3-
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
-4-
Sicherheitsrisiken
1. Berechtigungen
Berechtigungen sind ein zentraler Faktor in SAP Sicherheitsprojekten. Unternehmen investieren viel Geld in
die Entwicklung von Rollen- und Berechtigungskonzepten.
SAP verwendet ein explizites Berechtigungsmodell. Das bedeutet, dass eine Berechtigungsprüfung nur
erfolgt, wenn ein Programm die Prüfung selbst explizit ausführt.
Anders ausgedrückt: ohne eine explizite Berechtigungsprüfung im Code wird nicht geprüft, ob ein Benutzer
auch wirklich berechtigt ist.
In selbst entwickeltem Code werden (wichtige) Berechtigungsprüfungen sehr häufig vergessen. Somit
kommt das Berechtigungskonzept nicht zum tragen.
Dadurch entstehen Compliance-Verstöße, die insbesondere bei Wirtschaftsprüfungen schwerwiegende
Folgen haben können.
Es ist daher essentiell wichtig, dass in Eigenentwicklungen Berechtigungsprüfungen überall wo sie
erforderlich sind programmatisch geprüft werden und dass sämtliche Berechtigungsprüfungen auch formal
korrekt programmiert sind.
Berechtigungsfehler sind die häufigsten Sicherheitsfehler in ABAP Eigenentwicklungen
<STAT>
.
Grundsätzliche Anforderungen
1. Alle Berechtigungsprüfungen in ABAP müssen mit SAP Standardmechanismen durchgeführt werden.
Das bedeutet, dass entweder der Befehl AUTHORITY-CHECK OBJECT verwendet werden muss oder ein
Modul, dass speziell für die Prüfung einer bestimmten Berechtigung entwickelt wurde (wie beispielsweise
der SAP Funktionsbaustein 'AUTHORITY_CHECK_DATASET').
Spezielle Sicherheitsrisiken und Anforderungen
Im Folgenden werden spezielle Risiken behandelt, die im Kontext von Berechtigungen auftreten. Dabei wird
immer eine Empfehlungen für die Mitigation (Abschwächung) des beschriebenen Risikos abgegeben.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
-5-
AUTH-01
Fehlender AUTHORITY-CHECK in Reports
I. Hintergrund und Risiko
Es gibt eine Vielzahl von Möglichkeiten Reports mit SAP Standardmitteln oder selbst geschriebenen
Programmen zu starten. Es ist entsprechend schwierig alle diese "Report Starter" zu identifizieren und
mittels restriktiver Vergabe von Berechtigungen abzusichern.
Daher ist es wichtig, dass alle selbst entwickelten Reports durch explizite Berechtigungsprüfungen
sicherstellen, dass nur autorisierte Benutzer mit ihnen arbeiten können. Denn wenn ein Report selbst prüft,
ob der Aufrufer berechtigt ist, dann spielt es keine Rolle wie der Report gestartet wurde. Er wird nicht laufen,
wenn der Benutzer nicht berechtigt ist.
Hat ein Report keine Berechtigungsprüfung, besteht das Risiko dass ein Benutzer einen nicht abgesicherten
Weg findet den Report zu starten und dann die darin enthaltene Geschäftslogik unberechtigt ausführt.
II. Technische Beschreibung des Risikos
Das Starten eines Reports erfolgt technisch immer durch den ABAP Befehl SUBMIT. Alle SAP
Standardtransaktionen und Bausteine die Reports starten basieren auf diesem Befehl.
Beim Aufruf eines SUBMIT Befehls führt der SAP Kernel automatisch eine Berechtigungsprüfung auf
S_PROGRAM durch, sofern in den Programmeigenschaften des Reports eine Berechtigungsgruppe gepflegt
ist.
Ist keine Berechtigungsgruppe gepflegt, dann wird der Report ohne Berechtigungsprüfung gestartet. Wenn
der Report Geschäftsdaten verarbeitet oder anzeigt, kann das je nach Kontext ein Compliance- und/oder ein
Sicherheitsrisiko sein.
III. Technische Beschreibung der Mitigation
Es gibt zwei Möglichkeiten das Risiko zu mitigieren.
1. Explizite Verwendung des Befehls AUTHORITY-CHECK OBJECT im Report. Dadurch können Sie eine
genau für diesen Report relevante Berechtigungsprüfung durchführen.
2. Zuweisung einer Berechtigungsgruppe in den Programmeigenschaften. Dadurch wird bereits der Start des
Reports verhindert.
Unter bestimmten Umständen führt der SAP Standard die S_PROGRAM Prüfung nicht aus, auch
wenn eine Berechtigungsgruppe gepflegt ist. Wir empfehlen daher Mitigation 1.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
-6-
AUTH-02
Fehlender AUTHORITY-CHECK vor CALL TRANSACTION
I. Hintergrund und Risiko
Der ABAP Befehl CALL TRANSACTION startet eine beliebige SAP Transaktion. Allerdings führt dieser Befehl
nicht zwingend eine Startberechtigungsprüfung (S_TCODE) durch. Dadurch kann es sein, dass Benutzer
Transaktionen unberechtigt starten können.
II. Technische Beschreibung des Risikos
Das Starten einer Transaktion erfolgt technisch immer durch die ABAP Befehle CALL TRANSACTION und
LEAVE TO TRANSACTION. Alle SAP Standardtransaktionen und Bausteine die Transaktionen starten
basieren auf diesen Befehlen.
Während LEAVE TO TRANSACTION eine implizite Startberechtigungsprüfung durchführt, tut CALL
TRANSACTION dies nicht.
Im SAP Standard gibt es verschiedene Möglichkeiten diesem Sicherheitsmangel per Konfiguration
beizukommen. Diese Konfigurationsmöglichkeiten sind komplex und lassen leider Raum für Fehler.
Daher sollten Entwickler immer eine explizite Startberechtigungsprüfung durchführen wenn sie den Befehl
CALL TRANSACTION verwenden. Ohne eine explizite (programmatische) Prüfung könnten unberechtigte
Benutzer an kritische Daten gelangen.
III. Technische Beschreibung der Mitigation
Bevor der Befehl CALL TRANSACTION ausgeführt wird, sollte eine Berechtigungsprüfung stattfinden, um
sicherzustellen, dass der aktuelle Benutzer auch berechtigt ist die Transaktion zu starten.
Eine hinreichende Berechtigungsprüfung ist auf zwei Arten möglich.
1. Explizite Verwendung des Funktionsbausteins 'AUTHORITY_CHECK_TCODE', dessen umfassende
Prüfung gleichzeitig verschiedene Konfigurationsvarianten berücksichtigt.
2. Seit SAP Basis Release 7.40 verfügt der Befehl CALL TRANSACTION über die Optionen WITH
AUTHORITY-CHECK und WITHOUT AUTHORITY-CHECK. Entsprechend sollten Sie die Option WITH
AUTHORITY-CHECK verwenden, die funktional dem Funktionsbaustein 'AUTHORITY_CHECK_TCODE'
gleichwertig ist.
Beispiel
TRY.
CALL TRANSACTION 'SM30' WITH AUTHORITY-CHECK.
CATCH cx_sy_authorization_error.
EXIT.
ENDTRY.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
-7-
AUTH-03
Fehlender AUTHORITY-CHECK in RFC-fähigen Funktionsbausteinen
I. Hintergrund und Risiko
Funktionsbausteine sind ein spezieller Typ ABAP Module, weil sie als "remote-fähig" konfiguriert werden
können. Remote-fähige Funktionsbausteine können über das RFC Protokoll von jedem Rechner aufgerufen
werden, der eine Netzwerkverbindung zum SAP System hat.
*
Da in den meisten Unternehmen wegen der komplexen Rechtevergabe (zu) viele Benutzer S_RFC
("Stern") Berechtigung haben können sie potentiell jeden Funktionsbaustein ausführen, der keine gesonderte
Berechtigungsprüfung für die tatsächlich ausgeführte Businesslogik durchführt.
Wenn beispielsweise ein Funktionsbaustein Finanzdaten verarbeitet, könnte er via RFC ausgeführt werden,
obwohl die Rolle des Benutzers nicht die notwendigen relevanten (Finanz-)Berechtigungsobjekte enthält.
II. Technische Beschreibung des Risikos
Remote-fähige Funktionsbausteine können von externen Servern und Clients über das RFC Protokoll
ausgeführt werden. Dafür müssen folgende Bedingungen erfüllt sein:
 Das aufrufende System benötigt Netzwerkzugriff auf den SAP Server, auf dem der
Funktionsbaustein aktiv ist
 Das aufrufende Programm muss eine RFC Verbindung herstellen können, z.B. in dem es die JCO
API der SAP einbindet, die SAP allen Kunden frei zur Verfügung stellt.
 Es muss ein Benutzerkonto verwendet werden, das S_RFC Privilegien zur Ausführung des
Funktionsbausteins hat.
Das bedeutet, dass jeder Rechner im Intranet eines Unternehmens potentiell einen remote-fähigen
Funktionsbaustein ausführen kann.
Auf einem SAP System existieren durchschnittlich 498<STAT> selbst entwickelte remote-fähige
Funktionsbausteine. Bei 61%<STAT> davon fehlt die Berechtigungsprüfung.
III. Technische Beschreibung der Mitigation
Alle remote-fähigen Funktionsbausteine müssen prüfen, ob der Aufrufer berechtigt ist die zugehörige
Businesslogik auszuführen. Dies sollte durch eine explizite Berechtigungsprüfung im Code erfolgen.
Die zu prüfenden Berechtigungen hängen von der Business Logik ab und sollten zusammen mit den
Fachverantwortlichen oder mit Sicherheitsexperten bestimmt werden.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
-8-
AUTH-04
Fehlender AUTHORITY-CHECK bei PAI Ereignissen
I. Hintergrund und Risiko
Klassische Dynpro-Anwendungen sind bei vielen Unternehmen immer noch verbreitet im Einsatz. Häufig
werden dabei Menüeinträge und Bildschirmelemente je nach den Berechtigungen der Benutzer ein- oder
ausgeblendet.
Es ist jedoch möglich Events gezielt auch durch direkt Eingabe ihrer Funktionscodes im SAPGUI
auszulösen, selbst wenn das zugehörige Bildschirmelement nicht vorhanden bzw. deaktiviert ist.
Wenn ein Bildschirmelement abgeschaltet wurde, dann darf eine Anwendung nicht (ohne adäquate
Berechtigungsprüfungen) auf Events dieses Elements reagieren. Andernfalls können Benutzer ohne jedes
Hilfsmittel und praktisch ohne Fachkenntnisse Berechtigungsprüfungen umgehen.
II. Technische Beschreibung des Risikos
Beim Anklicken von Menüeinträgen oder Buttons werden sogenannte Funktionscodes an die Anwendung
gesendet. Diese Funktionscodes kann ein Benutzer aber auch direkt im Kommandofeld des SAP GUI
eingeben, sofern sie ihm bekannt sind. Beispielsweise entspricht der Event des "Anzeigen" Buttons in
Transaktion SE24 dem Funktionscode "WB_DISPLAY".
Es ist zu beobachten, dass Entwickler diese Eigenschaft auch verwenden, um versteckte Events in
Anwendungen zu platzieren - also Funktionscodes für die es gar kein Bildschirmelement gibt. Dies stellt ein
hohes Risiko dar, da man auf diese Weise Hintertüren in eine Anwendung einschleusen kann.
III. Technische Beschreibung der Mitigation
1. Es dürfen nur Funktionscodes verarbeitet werden, die auch einem Bildschirmelement zugeordnet sind.
2. Wenn bestimmte Einträge eines Dynpro-Menüs ausgeblendet oder einzelne Buttons deaktiviert werden
sollen, dann muss die Behandlung der zugehörigen Funktionscodes programmatisch ebenfalls verhindert
werden. Daher müssen die Berechtigungsprüfungen nicht nur zum Zeitpunkt PBO (Deaktivierung der
Bildschirmelemente) stattfinden, sondern auch zum Zeitpunkt PAI (Prüfung der zugehörigen
Funktionscodes).
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
-9-
AUTH-05
Fehlende Ergebnisprüfung nach AUTHORITY-CHECK
I. Hintergrund und Risiko
Eine explizite Berechtigungsprüfung im Code besteht aus zwei Aktionen: der Anfrage durch den Befehl
AUTHORITY-CHECK OBJECT und der Auswertung des Ergebnisses in der Systemvariable sy-subrc.
Findet die Ergebnisauswertung nicht (formal korrekt) statt, ist die Berechtigungsprüfung wirkungslos.
II. Technische Beschreibung des Risikos
Der ABAP Befehl AUTHORITY-CHECK OBJECT führt eine Berechtigungsprüfung im SAP Kernel durch.
Dabei wird auch gegebenenfalls ein entsprechender Trace-Eintrag angelegt.
Allerdings leitet sich aus der Prüfung im Kernel zunächst keine Konsequenz für die weitere Ausführung eines
ABAP Programms ab. Nur wenn der Rückgabewert geprüft und bei unzureichender Berechtigung eine
entsprechende Reaktion eingeleitet wird, ist die Berechtigungsprüfung hinreichend.
III. Technische Beschreibung der Mitigation
Der Wert der Systemvariablen sy-subrc muss unmittelbar nach jedem Aufruf des Befehls
AUTHORITY-CHECK OBJECT ausgelesen und analysiert werden. Eine Berechtigungsprüfung ist nur dann
erfolgreich, wenn sy-subrc den Wert "0" hat.
Beispiel
AUTHORITY-CHECK OBJECT 'S_DEVELOP'
ID 'DEVCLASS' FIELD 'ZHR'
ID 'OBJTYPE'
FIELD 'CLAS'
ID 'OBJNAME'
FIELD 'Z_CL_HRPAY'
ID 'P_GROUP'
DUMMY
ID 'ACTVT'
FIELD '02'.
" Programm verlassen, falls Benutzer die angefragte Berechtigung nicht hat
IF sy-subrc <> 0.
EXIT.
ENDIF.
Achtung: Wird sy-subrc nicht unmittelbar nach der Berechtigungsprüfung ausgelesen, kann ein anderer
ABAP Befehl den Wert überschreiben.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 10 -
AUTH-06
Unvollständiger AUTHORITY-CHECK
I. Hintergrund und Risiko
Bei einer Berechtigungsprüfung im Code müssen alle Felder des relevanten Berechtigungsobjekts explizit
einbezogen werden.
Falls ein Feld bei der Prüfung vergessen wird, dann werden die Rechte des Benutzers in Bezug auf das Feld
nicht geprüft. In Konsequenz ist die Prüfung unvollständig und kann zu unberechtigtem Zugang führen.
II. Technische Beschreibung des Risikos
Der Befehl AUTHORITY-CHECK OBJECT führt eine Berechtigungsprüfung auf das Berechtigungsobjekt und
alle für das Berechtigungsobjekt angegebenen Felder aus.
Jedoch werden die einem Benutzer zugewiesenen Werte ignoriert, wenn ein oder mehrere Felder des
Berechtigungsobjekts nicht geprüft werden. Dies kann zu einer unerwünschten Rechteerweiterung führen,
wenn ein Benutzer sehr restriktive Werte in einem Feld hat das (irrtümlich) nicht geprüft wird.
III. Technische Beschreibung der Mitigation
Der Befehl AUTHORITY-CHECK OBJECT muss alle Felder auflisten, die dem zu prüfenden
Berechtigungsobjekt angehören.
Sollte ein Feld nicht benötigt werden, so ist dies explizit mittels der Option DUMMY anzuzeigen und zu
dokumentieren.
Der Einsatz von DUMMY zur Unterdrückung einer Feldprüfung gibt einem Auditor Aufschluss, dass (und
warum) das Feld absichtlich nicht überprüft werden soll. Der Auditor kann dadurch ausschließen, dass das
Feld irrtümlich vergessen wurde.
Beispiel
AUTHORITY-CHECK OBJECT 'S_DEVELOP'
ID 'DEVCLASS' FIELD 'ZHR'
ID 'OBJTYPE'
FIELD 'CLAS'
ID 'OBJNAME'
FIELD 'Z_CL_HRPAY'
" Dieses Feld wird für Klassen nicht benötigt
ID 'P_GROUP'
DUMMY
ID 'ACTVT'
FIELD '02'.
IF sy-subrc <> 0.
EXIT.
ENDIF.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 11 -
AUTH-07
Proprietäre Berechtigungsprüfung (sy-uname)
I. Hintergrund und Risiko
Alle Berechtigungen in SAP Systemen basieren auf den für die Benutzer gepflegten Rollen und Profilen. Die
SAP Standardfunktionalität protokolliert die Ergebnisse sämtliche Berechtigungsprüfungen revisionssicher
für Auditoren und Wirtschaftsprüfer.
Verwendet ein Programm jedoch proprietäre Berechtigungsprüfungen, so werden weder die Rollen und
Profile der Benutzer geprüft, noch korrekte Protokolle erzeugt.
II. Technische Beschreibung des Risikos
Es ist zu beobachten, dass Entwickler häufig Berechtigungsprüfungen basierend auf den Benutzernamen
von Mitarbeitern/Entwicklern programmieren. Solche Funktionalität wird meist zu Testzwecken erstellt, aber
häufig nicht entfernt bevor die Anwendung produktiv gesetzt wird.
Es kommt jedoch auch vor, dass Entwickler mit diesem Mechanismus vorsätzlich Hintertüren in
Anwendungen bauen.
Auf SAP Systemen befinden sich mit einer Wahrscheinlichkeit von 90%<%STAT> proprietäre
Berechtigungsprüfungen. Im Schnitt finden sich pro System etwa 200<%STAT>
Berechtigungs-prüfungen die auf sy-uname basieren.
Proprietäre Berechtigungsprüfungen stellen ein hohes Risiko für Unternehmen dar. Sie können nicht nur bei
Wirtschaftsprüfungen massive Probleme verursachen, sondern auch insgesamt ein Risiko für die
Geschäftsgeheimnisse eines Unternehmens darstellen.
III. Technische Beschreibung der Mitigation
1. Jegliche Berechtigungsprüfung im SAP muss technisch ausschließlich durch dem Befehl
AUTHORITY-CHECK OBJECT erfolgen. Der Befehl kann dabei auch indirekt verwendet werden, d.h. z.B.
durch den Aufruf von SAP Modulen, die ihn verwenden.
2. Die Ausführung von Geschäftslogik basierend auf sy-uname muss per Entwicklungsrichtlinie verboten
sein.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 12 -
2. Testbarkeit
Ein zentrales Sicherheitskonzept im SAP Standard ist die Trennung von Entwicklungs-, Test- und
Produktivsystemen.
Das Testsystem hat hierbei eine wichtige Rolle. Auf dem Testsystem wird entschieden, ob eine Anwendung
den Anforderungen des Unternehmens genügt. Hierbei werden sowohl funktionale als auch nicht-funktionale
Qualitätsaspekte der Anwendung überprüft.
Damit eine Qualitätsprüfung verlässliche Ergebnisse liefert, müssen nicht nur die Prüfer umfassende
Kenntnisse im Bereich Qualitätssicherung haben. Die Anwendung selbst muss auch prüfbar sein. Das
bedeutet, dass ein Prüfer die Anwendung zu Testzwecken ausführen und dass er im Zweifelsfall den
Quellcode der Anwendung analysieren kann.
Wenn bestimmte Funktionalitäten einer Anwendung sich auf dem Testsystem (von einem Prüfer) nicht
ausführen lassen, kann der Prüfer nicht erkennen, ob sie den Qualitätsanforderungen entsprechen. In Folge
dessen würde ungeprüfter Code auf ein Produktivsystem übertragen, was ein erhebliches Risiko für ein
Unternehmen darstellt.
Es ist daher essentiell wichtig, dass Eigenentwicklungen auf dem Testsystem hinreichend untersucht werden
können.
Grundsätzliche Anforderungen
1. Sämtliche Eigenentwicklungen müssen prüfbar sein.
Das bedeutet, dass sämtliche Funktionalität dokumentiert, auf einem Testsystem analysierbar und
ausführbar ist.
Spezielle Sicherheitsrisiken und Anforderungen
Im Folgenden werden spezielle Risiken behandelt, die im Kontext von Testbarkeit auftreten. Dabei wird
immer eine Empfehlungen für die Mitigation (Abschwächung) des beschriebenen Risikos abgegeben.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 13 -
TEST-01
Versteckter ABAP Code
I. Hintergrund und Risiko
Der SAP Standard erlaubt es Entwicklern, den Zugriff auf ABAP Quellcode zu verhindern. Hierzu gibt es
einen Mechanismus, der auf einem speziellen Kommentar basiert.
Alternativ ist zu beobachten, dass Entwickler Ihren Quellcode durch Verschleierungstechniken als
Zeichenketten maskieren, zur Laufzeit wieder demaskieren, als Code speichern und ausführen.
Solche Methoden ermöglichen es Schadcode auf ein System zu transportieren, der weder durch manuelle
noch durch automatisierte Codeanalysen erkannt werden kann.
II. Technische Beschreibung des Risikos
Wenn die erste Zeile eines ABAP Quellcodes eine bestimmte Signatur enthält, dann blockiert der SAP
Kernel den Lesezugriff auf diesen Quellcode. Beim Versuch versteckten Quellcode durch den Befehl READ
REPORT (aus der Tabelle REPOSRC) zu lesen, kommt es entsprechend zu einem Fehler. Diesen speziellen
Fehler erkennt man daran, dass sy-subrc auf den Wert 8 gesetzt wird.
Beispiel
*@#@@[SAP]
" FORM Routine mit Hintertür in einem versteckten Include
FORM geheime_backdoor.
READ REPORT 'YYY_BACKDOOR' INTO icode.
EDITOR-CALL FOR icode.
INSERT REPORT 'YYY_BACKDOOR' FROM icode.
ENDFORM.
III. Technische Beschreibung der Mitigation
Die Verwendung von Techniken, die das Lesen von Quellcode verhindern muss per Entwicklungsrichtlinie
verboten sein.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 14 -
TEST-02
Systemabhängige Ausführung
I. Hintergrund und Risiko
Die Systemvariable sy-sysid liefert einem ABAP Programm Informationen darüber auf welchem SAP
System es gerade ausgeführt wird.
Diese Funktionalität wird häufig verwendet, um systemspezifische Unterschiede programmatisch abzubilden.
D.h. dass sich manche Funktionen je nach dem System auf dem sie laufen leicht anders verhalten.
Das führt jedoch dazu, dass die tatsächliche Funktionalität wie sie für den produktiven Einsatz der
Anwendung vorgesehen ist auf dem Testsystem nicht geprüft werden kann. Dadurch wird Code ungetestet
auf ein Produktivsystem transportiert.
II. Technische Beschreibung des Risikos
Wenn Funktionen eines Programms auf einem Qualitätssicherungssystem nicht genauso durchlaufen
werden, wie auf dem Produktivsystem, kann die Qualitätssicherung keine hinreichende Testabdeckung
leisten.
Wenn die produktive Funktionalität eines Programms nicht testbar ist können sowohl Hintertüren als auch
fehlerhafte Geschäftslogik ins Produktivsystem ausgeliefert werden.
Beispiel
IF sy-sysid = 'P23'
lv_mailtarget = '[email protected]'.
ELSE.
lv_mailtarget = '[email protected]'.
ENDIF.
III. Technische Beschreibung der Mitigation
Die Verwendung von Techniken, die die Ausführung bestimmter Code-Zweige von einem bestimmten SAP
System abhängig macht muss per Entwicklungsrichtlinie verboten sein.
Sollten solche Praktiken tatsächlich erforderlich sein, muss detailliert dokumentiert werden, wo sie verwendet
werden und warum. Dann kann die Qualitätssicherung zumindest mittels manueller Code-Analyse erfolgen.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 15 -
TEST-03
Mandantenabhängige Ausführung
I. Hintergrund und Risiko
Die Systemvariable sy-mandt liefert einem ABAP Programm Informationen darüber auf welchem
Mandanten es gerade ausgeführt wird.
Diese Funktionalität wird häufig verwendet, um mandantenspezifische Unterschiede programmatisch
abzubilden. D.h. dass sich manche Funktionen je nach dem Mandanten an dem ein Benutzer angemeldet ist
leicht anders verhalten.
Das führt jedoch dazu, dass die tatsächliche Funktionalität wie sie für den produktiven Einsatz der
Anwendung vorgesehen ist auf dem Testsystem potentiell nicht geprüft wird. Dadurch wird Code
möglicherweise ungetestet auf einen produktiven Mandanten transportiert.
II. Technische Beschreibung des Risikos
Wenn Funktionen eines Programms auf einem Qualitätssicherungssystem nicht genauso durchlaufen
werden, wie auf dem Produktivsystem, kann die Qualitätssicherung keine hinreichende Testabdeckung
leisten.
Wenn die produktive Funktionalität eines Programms nicht testbar ist können sowohl Hintertüren als auch
fehlerhafte Geschäftslogik ins Produktivsystem ausgeliefert werden.
Beispiel
IF sy-mandt = '007'
lv_mailtarget = '[email protected]'.
ELSE.
lv_mailtarget = '[email protected]'.
ENDIF.
III. Technische Beschreibung der Mitigation
Die Verwendung von Techniken, die die Ausführung bestimmter Code-Zweige von einem bestimmten
Mandanten abhängig macht muss per Entwicklungsrichtlinie verboten sein.
Sollten solche Praktiken tatsächlich erforderlich sein, muss detailliert dokumentiert werden, wo sie verwendet
werden und warum. Dann kann die Qualitätssicherung auf den entsprechenden Mandanten stattfinden oder
zumindest mittels manueller Code-Analyse erfolgen.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 16 -
3. Datenschutz
SAP Systeme enthalten eine große Menge an unternehmenskritischen Daten. Der SAP Standard sieht
verschiedene Mechanismen vor, diese kritischen Daten vor unerlaubtem Zugriff zu schützen.
Allerdings können auch durch Fehler in Eigenentwicklungen unerlaubte Zugriffe und Datenabflüsse
ermöglicht werden. Erhält ein Mitarbeiter unerlaubt Zugriff auf Daten, so kann er diese in einem zweiten
Schritt in eine vom Unternehmen nicht mehr kontrollierbare Umgebung transferieren.
Grundsätzliche Anforderungen
1. Unternehmenskritische Daten müssen auch programmatisch vor unerlaubtem Zugriff geschützt sein.
2. Insbesondere gesetzliche Vorschriften (z.B. Bundesdatenschutzgesetz) sind einzuhalten.
Spezielle Sicherheitsrisiken und Anforderungen
Im Folgenden werden spezielle Risiken behandelt, die im Kontext von Datenlecks auftreten. Dabei wird
immer eine Empfehlungen für die Mitigation (Abschwächung) des beschriebenen Risikos abgegeben.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 17 -
DAT-01
Datenlecks
I. Hintergrund und Risiko
In SAP Systemen sind unter anderem folgende Arten von Daten gespeichert:
- Finanzdaten
- Personenbezogene Daten
- Geschäftsgeheimnisse
- Passwörter
Der Schutz dieser Daten ist aus verschiedenen Aspekten für Unternehmen, Organisationen und Behörden
wichtig. Dazu gehören gesetzliche Anforderungen, öffentliches Ansehen und nicht zuletzt die Wahrung von
Wettbewerbsvorteilen. Beim Verlust bestimmter Daten besteht darüber hinaus auch eine Meldepflicht (siehe
z.B. §42a BDSG).
Bei selbstgeschriebenen ABAP Programmen wird häufig nicht die notwendige Sorgfalt im Umgang mit
unternehmenskritischen Daten angewendet. Sollte ein Mitarbeiter dadurch unbefugt Zugang zu kritischen
Daten erhalten, ist er in der Lage diese Daten anschließend an Dritte zu übermitteln.
II. Technische Beschreibung des Risikos
Ein Risiko liegt insbesondere dann vor, wenn kritische Daten unberechtigt
- angezeigt (z.B. SAP GUI, HTML, UI5, Smartforms, Adobe Forms, ...)
- in Dateien gespeichert (sowohl Server- als auch Client-seitig)
- an andere Anwendungen oder Benutzer übertragen (z.B. via RFC, HTTP, FTP, ...)
werden.
III. Technische Beschreibung der Mitigation
Bei der Anzeige, der Übermittlung und dem Export kritischer Daten muss eine hinreichende
Berechtigungsprüfung erfolgen.
Als Vorstufe zu diesem Schutz ist es erforderlich, dass Unternehmen einen Überblick haben, welche Daten
im SAP System unternehmenskritisch sind bzw. gesetzlichen Anforderungen unterliegen.
Sämtliche lesenden Zugriffe auf kritische Daten müssen mit Berechtigungsprüfungen abgesichert und jeder
(beabsichtigte) Abfluss dieser Daten dokumentiert sein. Vermeiden Sie insbesondere Anwendungen, die
generischen Zugriff auf Daten ermöglichen (siehe MECH-03).
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 18 -
4. Injection Schwachstellen
Injection Schwachstellen basieren darauf, dass ein Angreifer Steuerzeichen und/oder Kommandos durch
den Datenkanal (Input) in eine Anwendung einschleust. Ein erfolgreicher Angriff kann den geplanten
Programmablauf durch unerwartete Kommandos schadhaft verändern.
Durch Eigenentwicklungen erhöht sich die Zahl der Eingabefelder (Input) des Systems im Schnitt um 15.230 <
%STAT>.
Injection Schwachstellen stellen das größte Sicherheitsrisiko durch Eigenentwicklungen dar. Je nach
Art der Injection kann ein Angreifer die vollständige Kontrolle über das betroffene SAP System
erlangen.
Generell sind die technischen Details von Injection Schwachstellen komplex, äußerst variantenreich und
insgesamt sehr schwer zu verstehen. Es ist daher sowohl für Entwickler als auch für Tester ohne spezielle
Schulung schwierig Schwachstellen zu erkennen bzw. zu beheben.
Grundsätzliche Anforderungen
1. Bei der Verarbeitung von Benutzereingaben ist generell eine Plausibilitätsprüfung der Daten
durchzuführen. Dies nennt man auch "Input Validierung". Input Validierung leistet nicht nur einen
grundlegenden Sicherheitsschutz (da Steuer- und Sonderzeichen in den meisten Datenfeldern keinen
Sinn machen und entfernt werden können), sondern verbessert auch die Datenqualität allgemein.
Input Validierung ist so zu implementieren, dass die Eingaben mit einer Liste erlaubter Werte abgeglichen
werden, d.h. mit dem sogenannten "White List Filter" Verfahren.
2. Es ist besondere Vorsicht geboten wenn Benutzereingaben mit Steuerzeichen oder Sprachelementen
(Semantik) vermischt werden und das Ergebnis anschließend als Ganzes verarbeitet oder ausgeführt
wird. In diesem Fall müssen sämtliche im verwendeten Kontext relevanten Steuerzeichen in den Daten
unschädlich gemacht werden. Diesen Vorgang nennt man auch "Output Encodierung" oder "Escaping".
Spezielle Sicherheitsrisiken und Anforderungen
Im Folgenden werden spezielle Risiken behandelt, die im Kontext von Injection Schwachstellen auftreten.
Dabei wird immer eine Empfehlungen für die Mitigation (Abschwächung) des beschriebenen Risikos
abgegeben.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 19 -
INJ-01
ABAP Command Injection
I. Hintergrund und Risiko
Der ABAP Sprachumfang erlaubt es ABAP Programmen zur Laufzeit neue ABAP Programme dynamisch zu
erstellen und auszuführen. Dieser Mechanismus lässt sich durch Konfiguration nicht abschalten. Er
funktioniert technisch ohne jede Berechtigungsprüfung und lässt sich auch ausführen, wenn ein Mandant als
produktiver Mandant konfiguriert und für Änderungen gesperrt ist. Auf diesem Weg ist es auch ganz einfach
möglich den SAP Standard zu ändern.
Wenn ein ABAP Programm von dieser Funktionalität Gebrauch macht, dann besteht ein sehr hohes
Sicherheitsrisiko für das gesamte SAP System, wenn Benutzereingaben als Teil der erstellten ABAP
Programme verwendet werden.
Wenn ein ABAP Programm schadhaft manipuliert wird, kann ein Angreifer die totale Kontrolle über das
gesamte SAP System übernehmen. Ebenso umgeht das dynamische Erstellen von ABAP Programmen auf
dem Produktivsystem implizit die Möglichkeit einer Qualitätssicherung auf dem QA System.
II. Technische Beschreibung des Risikos
Die Sprache ABAP hat weitgehende Zugriffsrechte auf einem SAP System.
Insbesondere ist es von ABAP aus möglich beliebige Datenbankeinträge ohne jede Berechtigungsprüfung
auszulesen, zu löschen oder zu manipulieren. Dadurch können sowohl Geschäfts- als auch
Konfigurationsdaten beliebig verändert werden.
Eine ABAP Command Injection Schwachstelle gibt einem Angreifer die totale Kontrolle über das
SAP System, egal welche sonstigen Sicherheitsmaßnahmen getroffen wurden.
Die ABAP Befehle INSERT REPORT und GENERATE SUBROUTINE POOL erlauben beide das dynamische
Erstellen von ABAP Programmen.
III. Technische Beschreibung der Mitigation
Die Verwendung der ABAP Befehle INSERT REPORT und GENERATE SUBROUTINE POOL muss per
Entwicklungsrichtlinie verboten sein.
Sollte dennoch dynamisch ABAP Code erstellt werden müssen, so muss detailliert dokumentiert werden, wo
und warum dies geschieht. Dann kann die Qualitätssicherung auch mittels manueller Code-Analyse erfolgen.
In keinem Fall darf Input Teil der dynamischen Erstellung von ABAP Programmen sein.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 20 -
INJ-02
OS Command Injection
I. Hintergrund und Risiko
Der ABAP Sprachumfang erlaubt es ABAP Programmen über mehrere, technisch verschiedene Wege
Kommandos an das Betriebssystem zu senden, auf dem der SAP Server installiert ist.
Wenn ein ABAP Programm von dieser Funktionalität Gebrauch macht, dann besteht ein sehr hohes
Sicherheitsrisiko für das gesamte SAP System, wenn Benutzereingaben als Teil der
Betriebssystem-kommandos verwendet werden oder wenn vorsätzlich schadhafte Kommandos ausgeführt
werden.
Wenn ein Betriebssystemkommando schadhaft manipuliert wird, kann ein Angreifer die totale
Kontrolle über das Betriebssystem des SAP Servers übernehmen. Vom Betriebssystem aus kann er
dann in einem zweiten Schritt auch Kontrolle über das SAP System und die Datenbank erlangen.
II. Technische Beschreibung des Risikos
Es ist zu beobachten, dass Entwickler von folgenden ABAP Befehlen Gebrauch machen, um generisch
Betriebssystemkommandos auszuführen:
CALL
CALL
OPEN
CALL
CALL
'SYSTEM'
'ThWpInfo'
DATASET FILTER
FUNCTION 'RFC_REMOTE_EXEC'
FUNCTION 'RFC_REMOTE_PIPE'
Alle diese Kommandos sind gefährlich, da sie die Ausführung beliebiger Betriebssystemkommandos
ermöglichen und damit die Sicherheitsmechanismen des SAP Standards aushebeln.
III. Technische Beschreibung der Mitigation
Betriebssystemkommandos dürfen von ABAP Programmen aus nur über die Standardfunktionsbausteine
'SXPG_CALL_SYSTEM' (lokale Ausführung) und 'SXPG_COMMAND_EXECUTE' (Ausführung auf einem
anderen SAP System) ausgeführt werden. Einzig diese beiden Funktionsbausteine sind im SAP Standard für
die Ausführung von Betriebssystemkommandos vorgesehen. Sie ermöglichen es die Kommandos
auszuführen, die zuvor mit den Transaktionen SM49 oder SM69 erstellt wurden. Durch diese Transaktionen
hat ein Administrator die Kontrolle darüber welche Betriebssystemkommandos auf einem SAP Server
ausgeführt werden können.
Die Ausführung der generell erlaubten Betriebssystemkommandos muss zusätzlich über das
Berechtigungsobjekt S_LOG_COM nur den befugten Benutzern freigeschaltet werden.
In keinem Fall darf Input Teil der Ausführung von Betriebssystemkommandos sein.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 21 -
INJ-03
Native SQL Injection
I. Hintergrund und Risiko
ABAP Programme können über die ADBC (ABAP Database Connectivity) Schnittstelle beliebige native SQL
Befehle an die Datenbank senden. Dadurch können auch viele Befehle ausgeführt werden, die die Standard
Open SQL Schnittstelle von ABAP gar nicht ausführen kann. Insbesondere können auch mehrere Befehle
hintereinander durch Verkettung ausgeführt werden.
Sollte ein Befehl, der an die ADBC Schnittstelle gesendet wird Benutzereingaben enthalten, besteht das
Risiko, dass der Befehl schadhaft verändert wird.
Da fast alle kritischen Geschäfts- und Konfigurationsdaten in der Datenbank liegen, kann ein
Angreifer durch eine Native SQL Injection die totale Kontrolle über den SAP Server übernehmen.
Beispielsweise gibt ein UPDATE auf die "richtige" Tabelle einem Benutzer SAP_ALL Rechte.
II. Technische Beschreibung des Risikos
Die ADBC Schnittstelle erlaubt es ABAP Programmen dynamisch Zeichenketten zusammenzusetzen und
dann als native(n) SQL Befehl(e) an die Datenbank zu senden.
ADBC basiert technisch auf mehreren Kernel Calls und ist durch die Klassen CL_SQL_STATEMENT,
CL_SQL_PREPARED_STATEMENT und CL_SQL_CONNECTION verschalt.
Da die gängigen Datenbanken die Verkettung von SQL Befehlen erlauben, kann eine native SQL Injection
den aktuellen SQL Befehl abschließen und einen ganz anderen Befehl ausführen.
Native SQL Befehle ermöglichen über den Funktionsumfang von Open SQL hinaus unter anderem:
- das Anlegen von neuen Datenbankbenutzern
- das Entfernen von Tabellen
- das Löschen der gesamten Datenbank
Beachten Sie bitte, dass der Einsatz von ADBC noch andere Sicherheitsrisiken (jenseits von SQL
Injection) birgt, da bestimmte Standardmechanismen wie z.B. die automatische Mandantentrennung
nicht greifen.
III. Technische Beschreibung der Mitigation
Die Verwendung von ADBC sollte per Entwicklungsrichtlinie verboten sein. Das verhindert zusätzlich Risiken
im Zusammenhang mit MECH-01.
Sollte es wichtige Gründe für den Einsatz von ADBC geben, so muss detailliert dokumentiert werden, wo und
warum dies geschieht. Ziehen Sie beim Einsatz von ADBC auf jeden Fall Sicherheitsexperten hinzu, da
sowohl die Wahrscheinlichkeit als auch die Auswirkung von Sicherheitsfehlern sehr hoch ist.
In keinem Fall darf Input Teil der Ausführung von ADBC Befehlen sein.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 22 -
INJ-04
Directory Traversal
I. Hintergrund und Risiko
ABAP Programme greifen in verschiedenen Anwendungsszenarien lesend und/oder schreibend auf das
Dateisystem des SAP Servers zu. Häufig werden dabei Dateiname und/oder Pfad durch Benutzereingaben
bestimmt.
Gelingt es einem Benutzer durch schadhafte Eingaben den Dateinamen/-Pfad zu verändern, kann dies zu
einem unberechtigten Zugriff führen.
Dadurch können potentiell beliebige Dateien auf dem SAP Server (je nach Art des Zugriffs) unbefugt gelesen
oder überschrieben werden. Dies ist z.B. im Falle von Konfigurationsdateien, Logs, und Systemprogrammen
ein Sicherheitsrisiko.
II. Technische Beschreibung des Risikos
In Pfad- bzw Dateinamen haben die Zeichenfolgen '../' und '..\' eine besondere Bedeutung. Je nach
Betriebssystem wechseln sie den Pfad eine Ebene in Richtung Hauptverzeichnis.
Die Zeichenkette
'C:\tmp\sap\customer\..\..\..\windows\saplogon.ini'
verweist effektiv auf die Datei
'C:\windows\saplogon.ini'.
Gibt wie in diesem Beispiel die Anwendung den Pfad vor und der Anwender den (vermeintlichen)
Dateinamen (im Beispiel rot markiert), so kann dies zu unerwarteten Nebeneffekten führen. Durch
geschicktes traversieren der Verzeichnisstruktur kann der Anwender unerlaubt Zugriff auf Dateien in
beliebigen anderen Verzeichnissen erhalten.
Relevant für einen Angriff sind die Zeichenfolgen '../' und '..\'. Führt die Anwendung keine hinreichende
Prüfung der Benutzereingaben durch, gibt sie damit unbefugten Anwendern weitreichenden Zugriff.
III. Technische Beschreibung der Mitigation
Wenn auf Dateien eines SAP Servers zugegriffen wird, sollten möglichst keine Benutzereingaben für den
Dateinamen bzw Pfad verwendet werden.
Muss ein Teil des Pfades oder des Dateinamens per Benutzereingaben bestimmbar sein, dann muss der
SAP Standard Funktionsbaustein 'FILE_VALIDATE_NAME' für die Validierung verwendet werden.
Dieser Baustein prüft, ob die für den Dateizugriff erstellte Zeichenkette auch tatsächlich eine Datei innerhalb
oder unterhalb des vorgegebenen Anwendungsverzeichnisses darstellt. Im obigen Beispiel würde der
Baustein erkennen, dass das vorgegebene Anwendungsverzeichnis verlassen wurde.
Weiter Details dazu finden Sie in SAP Note 1497003.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 23 -
INJ-05
Open SQL Injection
I. Hintergrund und Risiko
Open SQL bietet die Möglichkeit, Teile eines bereits kompilierten SQL Befehls erst zur Laufzeit zu definieren.
Dies nennt man auch dynamisches Open SQL.
Werden im dynamischen Teil des Open SQL Befehls Benutzereingaben verarbeitet, kann der betroffene
Open SQL Befehl schadhaft manipuliert werden.
Dadurch kann ein Angreifer sich unberechtigten Zugang zu Daten beschaffen.
II. Technische Beschreibung des Risikos
Folgende Elemente der Open SQL Befehle können zur Laufzeit gesetzt werden:
 Tabellenname
 WHERE Bedingung
 SET Bedingung
 GROUP BY Bedingung
 HAVING Bedingung
Beispiel
PARAMETERS value type string.
CONCATENATE `bname='` value `'` INTO lv_where.
DELETE FROM usr01 WHERE (lv_where).
Im obigen Beispiel werden alle Datensätze gelöscht, wenn die WHERE Bedingung wie folgt manipuliert wird:
Input
' OR MANDT LIKE '%
Zusammengesetzte WHERE Bedingung
bname='' OR MANDT LIKE '%'
III. Technische Beschreibung der Mitigation
Die Verwendung von dynamischem Open SQL sollte per Entwicklungsrichtlinie verboten sein. Dadurch
reduziert sich das Risiko erheblich, da es mehrere technisch verschiedene Angriffsvektoren gibt.
Die Klasse CL_ABAP_DYN_PRG enthält einige Methoden, die Manipulationen durch Benutzereingaben
verhindern können. Die Anwendung dieser Methoden ist jedoch nicht einfach. Daher empfiehlt es sich die
Entwicklungsrichtlinien hinreichend detailliert zu erweitern oder einen Sicherheitsexperten hinzuzuziehen.
Beispiel
PARAMETERS value type string.
" Mitigation einer SQL Injection in einer dynamischen WHERE Bedingung
lv_safe = cl_abap_dyn_prg=>quote_str( value ).
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 24 CONCATENATE `bname=` lv_safe INTO lv_where.
DELETE FROM usr01 WHERE (lv_where).
INJ-06
Cross-Site Scripting
I. Hintergrund und Risiko
Bei der Entwicklung von BSP Anwendungen müssen Entwickler häufig spezielle Layoutvorgaben umsetzen.
Dazu müssen sie eigenes HTML Markup schreiben und Benutzereingaben einbetten.
Werden die Benutzereingaben ohne Output Encodierung eingebettet, kann das HTML Markup schadhaft
manipuliert werden. Dadurch können insbesondere schadhafte JavaScript Programme in die BSP
Anwendung eingeschleust werden, die auf dem Rechner der Benutzer ausgeführt werden.
Diese Art von Angriff nennt man Cross-Site Scripting oder XSS.
II. Technische Beschreibung des Risikos
Durch Cross-Site Scripting sind verschiedene Angriffe möglich:
 Zugriff auf sämtliche Daten der Anwendung
 Zugriff auf das Dateisystem und die Dateien des angegriffenen Anwenders
 Portscans auf das angebundene Intranet vom Rechner des angegriffenen Anwenders aus
 Digitaler Identitätsdiebstahl
 Ausführen von Geschäftslogik im Namen und mit den Berechtigungen des angegriffenen Anwenders
Eine umfängliche Analyse von XSS Risiken können Sie dem englischsprachigen Dokument "The Cross Site
Scripting Threat" entnehmen:
https://www.virtualforge.com/de/library/white-papers/the-cross-site-scripting-threat.html
III. Technische Beschreibung der Mitigation
Cross-Site Scripting ist eine extrem variantenreiche Schwachstelle. Es empfiehlt sich daher, auf selbst
entwickeltes HTML in BSP Anwendungen oder HTTP Handlern möglichst zu verzichten.
Rendering Mechanismen wie Web Dynpro oder UI5 generieren HTML automatisiert. Da Entwickler nicht
mehr in das HTML Rendering eingreifen können, sind diese Plattformen deutlich sicherer in Bezug auf XSS.
Eine Umfassende Anleitung zum Schutz vor XSS Schwachstellen würde den Rahmen dieses Dokuments
sprengen. Entwickler brauchen unbedingt eine fallabhängige Anleitung, wie sie die Risiken vermeiden.
Einige technische Informationen finden Sie in folgenden SAP Hinweisen:
Hinweis 822881
Hinweis 887168
Hinweis 944279
Hinweis 1582867
- offizielle Dokumentation bzgl HTMLB Encodierung
- offizielle Dokumentation bzgl forceEncode
- offizielle Dokumentation bzgl forceEncodeOTR
- offizielle Dokumentation verschiedener Encodierungsfunktionen
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 25 -
5. Standard-Schutz
Der SAP Standard stellt Unternehmen verschiedene Sicherheitsmechanismen zum Schutz Ihrer Daten zur
Verfügung. Entsprechend basieren viele Sicherheitsstrategien von Unternehmen darauf, dass die
Mechanismen im SAP Standard ein solides Fundament darstellen und nicht unterlaufen werden (können).
Zu diesem Mechanismen gehören unter anderem:
- Mandantentrennung
- Identity Management
- Rollen und Berechtigungen
- Getrennte Entwicklungs-, Test- und Produktivsysteme
- Logging
Grundsätzliche Anforderungen
1. ABAP Programme dürfen Sicherheitsmechanismen des SAP Standards nicht aushebeln.
2. Wenn der SAP Standard einen Sicherheitsmechanismus für bestimmte Aufgaben vorsieht, dann muss
dieser Sicherheitsmechanismus auch in ABAP Programmen verwendet werden.
Spezielle Sicherheitsrisiken und Anforderungen
Im Folgenden werden spezielle Risiken behandelt, die im Kontext von bestehenden SAP
Sicherheitsmechanismen auftreten. Dabei wird immer eine Empfehlungen für die Mitigation (Abschwächung)
des beschriebenen Risikos abgegeben.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 26 -
MECH-01
Zugriff auf Daten eines anderen Mandanten
I. Hintergrund und Risiko
Der SAP Kernel sorgt dafür, dass Open SQL Befehle nur auf Daten aus demjenigen Mandanten zugreifen,
an dem der Benutzer angemeldet ist. Dadurch eine Trennung der Daten aus unterschiedlichen Mandanten
gewährleistet.
Es gibt jedoch verschiedene Möglichkeiten die automatische Mandantentrennung (bewusst) abzuschalten.
Sollte eine Anwendung Daten aus einem anderen Mandanten verarbeiten, umgeht sie die für die
Verarbeitung notwendigen Berechtigungen. Für einen legitimen Zugriff ist nämlich ein Benutzerkonto mit
entsprechenden Rechten auf dem relevanten Mandanten erforderlich.
Der Zugriff auf Daten eines anderen Mandanten ist vor allem bei Systemen gefährlich, deren SAP
Mandanten verschiedene Unternehmen abbilden. Das betrifft insbesondere Hosting Systeme.
II. Technische Beschreibung des Risikos
Die Open SQL Befehle SELECT, OPEN CURSOR, DELETE, INSERT, MODIFY und UPDATE können durch die
Option CLIENT SPECIFIED die Mandantentrennung des SAP Kernels gezielt deaktivieren.
Beispiel
" Mandantenübergreifende Ausgabe aller Rentenversicherungsnummern im System
SELECT RVNUM FROM PA0013 INTO lv_rvnum CLIENT SPECIFIED.
WRITE: / lv_rvnum.
ENDSELECT.
Mandantenübergreifender Datenzugriff mittels Open SQL kann nicht durch die Vergabe von Berechtigungen
verhindert werden. Open SQL macht keinerlei implizite Berechtigungsprüfungen.
Eine Mandantentrennung findet darüber hinaus bei nativem SQL nicht automatisch statt. Das bedeutet, dass
sämtliche Datenbankzugriffe mittels ADBC oder der Verwendung des Befehls EXEC SQL in einem Audit
geprüft werden müssen. Auch natives SQL macht keinerlei implizite Berechtigungsprüfungen.
III. Technische Beschreibung der Mitigation
Die Verwendung der Open SQL Option CLIENT SPECIFIED sollte per Entwicklungsrichtlinie verboten sein.
Datenzugriff mittels EXEC SQL sollte per Entwicklungsrichtlinie verboten sein.
Die Verwendung von ADBC sollte per Entwicklungsrichtlinie verboten sein. Das verhindert zusätzlich Risiken
im Zusammenhang mit INJ-03.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 27 -
Sollte es wichtige Gründe für den Einsatz von mandantenübergreifenden Zugriffen geben, so muss detailliert
dokumentiert werden, wo und warum dies geschieht.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 28 -
MECH-02
Generische Ausführung von Programmen oder Funktionen
I. Hintergrund und Risiko
Für die Ausführung von Programmen, Methoden, Funktionsbausteinen und anderen Modulen stehen im SAP
Standard verschiedene Transaktionen zur Verfügung. Der Zugriff auf diese Transaktionen kann durch eine
gezielte Vergabe von Berechtigungen reguliert werden. Der eingeschränkte Zugriff auf diese Transaktionen
ist ein wichtiger Bestandteil von Audits.
Technisch gesehen basiert die Ausführung von ABAP Modulen wiederum auf ABAP Befehlen. Das bedeutet,
dass Eigenentwicklungen durchaus in der Lage sind, beliebige Arten von ABAP Modulen generisch zu
starten.
Somit besteht das Risiko, dass die Absicherung von Transaktionen wie z.B. SE24, SE37 und SA38 durch
Eigenentwicklungen ausgehebelt wird.
II. Technische Beschreibung des Risikos
Die ABAP Befehle CALL TRANSACTION, CALL FUNCTION und CALL METHOD führen keine
Berechtigungsprüfung für die Ausführung von Transaktionen, Funktionsbausteinen und Methoden durch. Bei
SUBMIT findet nur dann eine Berechtigungsprüfung auf S_PROGRAM statt, wenn für das auszuführende
Programm eine Berechtigungsgruppe hinterlegt ist.
Wenn Eigenentwicklungen Anwendern erlauben generisch ABAP Module auszuführen, umgehen Sie damit
die (abgesicherten) Standardtransaktionen, die dafür vorgesehen sind.
Beispiel
" Generischer Report-Starter
PARAMETERS prog TYPE string.
SUBMIT prog.
III. Technische Beschreibung der Mitigation
Die generische Ausführung von Transaktionen, Programmen, Funktionsbausteinen und Methoden sollte per
Entwicklungsrichtlinie verboten sein.
Sollte es wichtige Gründe für eine generische Ausführung geben, so muss detailliert dokumentiert werden,
wo und warum dies geschieht.
Insbesondere müssen auch alle erforderlichen (Berechtigungs-)Prüfungen durchgeführt werden, die die
entsprechenden SAP Standardtransaktionen zur Absicherung dieses Risikos durchführen.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 29 -
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 30 -
MECH-03
Generischer Zugriff auf Tabelleninhalte
I. Hintergrund und Risiko
Der SAP Standard stellt verschiedene Transaktionen zur Verfügung, die den Zugriff auf Datenbanktabellen
ermöglichen. Beispielsweise SM30, SE16 und SE16N. Diese SAP Transaktionen führen umfangreiche
(Berechtigungs-)Prüfungen durch, um den Zugriff auf kritische Daten einzuschränken.
Der Zugriff auf diese Transaktionen kann durch eine gezielte Vergabe von Berechtigungen reguliert werden.
Der eingeschränkte Zugriff auf diese Transaktionen ist ein wichtiger Prüfbestandteil von Audits.
Technisch gesehen basieren die SAP Standardtransaktionen, die die Datenbank auslesen auf dem Befehl
SELECT. Das bedeutet, dass auch Eigenentwicklungen in der Lage sind, generisch Daten aus der
Datenbank zu lesen.
Somit besteht das Risiko, dass die Absicherung von Transaktionen wie z.B. SM30, SE16 und SE16N durch
Eigenentwicklungen ausgehebelt wird.
II. Technische Beschreibung des Risikos
Mittels dynamischem Open SQL kann ein Entwickler Programme mit generischem Tabellenzugriff
entwickeln. Da Open SQL keine Berechtigungsprüfungen durchführt, kann dadurch eine Hintertür entstehen.
Beispiel
" Generischer Tabellen-Leser
PARAMETERS table TYPE string.
DATA alv
TYPE REF TO cl_salv_table.
DATA lr_data
TYPE REF TO data.
FIELD-SYMBOLS <ft_table> TYPE STANDARD TABLE.
CREATE DATA lr_data TYPE STANDARD TABLE OF (table).
ASSIGN lr_data->* TO <ft_table>.
SELECT * FROM (table) INTO TABLE <ft_table>.
cl_salv_table=>factory(IMPORTING r_salv_table = alv CHANGING
t_table = <ft_table> ).
alv->display( ).
III. Technische Beschreibung der Mitigation
Generisches Auslesen von Tabelleninhalten sollte per Entwicklungsrichtlinie verboten sein.
Sollte es wichtige Gründe für eine generische Ausführung geben, so muss detailliert dokumentiert werden,
wo und warum dies geschieht.
Insbesondere müssen auch alle erforderlichen (Berechtigungs-)Prüfungen durchgeführt werden, die die
entsprechenden SAP Standardtransaktionen zur Absicherung dieses Risikos durchführen.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 31 -
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 32 -
Weiterführende Informationen
Autor / Expertise
Andreas Wiegenstein - der Autor dieses Dokuments - arbeitet beim deutschen SAP Sicherheitsunternehmen
Virtual Forge GmbH und befasst sich seit 2003 mit SAP Sicherheit.
Er ist Co-Autor verschiedener Standardwerke im Bereich SAP/ABAP Sicherheit:


"Sichere ABAP Programmierung" - SAP Press (August 2009) ISBN: 978-3-8362-1357-8
"Best Practice Leitfaden Development" - DSAG 2013
Experten von Virtual Forge haben insgesamt über 100 Anerkennungen von der SAP AG für Ihre Beiträge an
gemeldeten 0-Day Schwachstellen im SAP Standard erhalten.
Virtual Forge hält regelmäßig Vorträge über SAP Sicherheit auf internationalen SAP- /
Sicherheits-Konferenzen wie Troopers, DeepSec, IT Defense, DSAG, BlackHat, RSA, Hack in the Box, SAP
TechEd.
Sie können bei Fragen jederzeit mit dem Autor in Kontakt treten (via Xing oder Twitter: @codeprofiler).
Über Virtual Forge
Virtual Forge ist ein unabhängiger Anbieter von Sicherheits-, Compliance- und Qualitätsprodukten für
SAP-Systeme und -Anwendungen mit Hauptsitz in Heidelberg. Virtual Forge unterstützt SAP-Kunden bei der
automatischen Risikoerkennung und Fehlerkorrektur sowie bei präventiven Maßnahmen und dauerhaften
Kontrollen von Risiken in der gesamten SAP-Landschaft.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 33 -
Haftungsausschluss
In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden. Die
vorliegenden Angaben werden von der Virtual Forge GmbH bereitgestellt und dienen ausschließlich
Informationszwecken.
SAP, ABAP und weitere im Text erwähnte SAP-Produkte und –Dienstleistungen sowie die entsprechenden
Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen Ländern weltweit.
Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen. Die Angaben
im Text sind unverbindlich und dienen lediglich zu Informationszwecken.
Die Virtual Forge GmbH übernimmt keinerlei Haftung oder Garantie für Fehler oder Unvollständigkeiten in
dieser Publikation. Aus den in dieser Publikation enthaltenen Informationen ergibt sich keine weiterführende
Haftung.
Kein Teil dieser Publikation darf in irgendeiner Form oder zu irgendeinem Zweck reproduziert oder
übertragen werden ohne die ausdrückliche Einwilligung der Virtual Forge GmbH.
© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.
- 34 -