34
Top 20 Sicherheitsrisiken in ABAP Anwendungen Detail-Level Ausarbeitung Version 0.5 Oktober 2014 Version 1.0 | Juli 2014

Top 20 Sicherheitsrisiken in ABAP Anwendungen

Embed Size (px)

Citation preview

Page 1: Top 20 Sicherheitsrisiken in ABAP Anwendungen

Top 20 Sicherheitsrisiken in ABAP Anwendungen

Detail-Level Ausarbeitung

Version 0.5Oktober 2014

Version 1.0 | Juli 2014

Page 2: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 3: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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ürzel

Beschreibung

Berechtigungen

AUTH Alle Geschäftsprozesse müssen ausreichend durch formal korrekte 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 Schwachstellen

INJ Sämtliche Eingaben müssen hinreichend von Schadcode befreit werden, bevor sie in potentiell gefährlichen ABAP Befehlen verwendet werden.

Standard-Schutz

MECH Vorhandene SAP Sicherheitsmechanismen dürfen durch ABAP Code nicht umgangen werden.

© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.

- 3 -

Page 4: Top 20 Sicherheitsrisiken in ABAP Anwendungen

© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.

- 4 -

Page 5: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 6: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 7: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.

- 7 -

TRY. CALL TRANSACTION 'SM30' WITH AUTHORITY-CHECK. CATCH cx_sy_authorization_error. EXIT.ENDTRY.

Page 8: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 9: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 10: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

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 -

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.

Page 11: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.

- 11 -

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.

Page 12: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 13: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 14: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

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 -

*@#@@[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.

Page 15: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

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 -

IF sy-sysid = 'P23'

lv_mailtarget = '[email protected]'.

ELSE.

lv_mailtarget = '[email protected]'.

ENDIF.

Page 16: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

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 -

IF sy-mandt = '007'

lv_mailtarget = '[email protected]'.

ELSE.

lv_mailtarget = '[email protected]'.

ENDIF.

Page 17: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 18: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 19: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 20: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 21: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 'SYSTEM'CALL 'ThWpInfo'OPEN DATASET FILTERCALL FUNCTION 'RFC_REMOTE_EXEC'CALL 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 -

Page 22: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 23: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 24: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

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

© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.

- 24 -

PARAMETERS value type string.

CONCATENATE `bname='` value `'` INTO lv_where.

DELETE FROM usr01 WHERE (lv_where).

PARAMETERS value type string.

" Mitigation einer SQL Injection in einer dynamischen WHERE Bedingung

lv_safe = cl_abap_dyn_prg=>quote_str( value ).

CONCATENATE `bname=` lv_safe INTO lv_where.

DELETE FROM usr01 WHERE (lv_where).

Page 25: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 - offizielle Dokumentation bzgl HTMLB Encodierung

Hinweis 887168 - offizielle Dokumentation bzgl forceEncodeHinweis 944279 - offizielle Dokumentation bzgl forceEncodeOTRHinweis 1582867 - offizielle Dokumentation verschiedener Encodierungsfunktionen

© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.

- 25 -

Page 26: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 27: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

" Mandantenübergreifende Ausgabe aller Rentenversicherungsnummern im System

SELECT RVNUM FROM PA0013 INTO lv_rvnum CLIENT SPECIFIED.

WRITE: / lv_rvnum.

ENDSELECT.

Page 28: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 29: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

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 -

" Generischer Report-Starter

PARAMETERS prog TYPE string.

SUBMIT prog.

Page 30: Top 20 Sicherheitsrisiken in ABAP Anwendungen

© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.

- 30 -

Page 31: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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

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 -

" 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( ).

Page 32: Top 20 Sicherheitsrisiken in ABAP Anwendungen

© 2014 Virtual Forge | www.virtualforge.com | Alle Rechte vorbehalten.

- 32 -

Page 33: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -

Page 34: Top 20 Sicherheitsrisiken in ABAP Anwendungen

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 -