Top 20 Sicherheitsrisiken in ABAP Anwendungen

Transkript

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

2 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. * **

3 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 Berechtigunge n Kürze l AUTH Beschreibung 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 Schwachstelle n Standard-Schu tz INJ Sämtliche Eingaben müssen hinreichend von Schadcode befreit werden, bevor sie in potentiell gefährlichen ABAP Befehlen verwendet werden. MECH Vorhandene SAP Sicherheitsmechanismen dürfen durch ABAP Code nicht umgangen werden

4 - 4 -

5 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

6 AUTH-01 Fehlender AUTHORITY-CHECK in Reports 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. 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. 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

7 AUTH-02 Fehlender AUTHORITY-CHECK vor CALL TRANSACTION 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. 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. 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

8 AUTH-03 Fehlender AUTHORITY-CHECK in RFC-fähigen Funktionsbausteinen 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. 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. 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

9 AUTH-04 Fehlender AUTHORITY-CHECK bei PAI Ereignissen 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. 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. 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)

10 AUTH-05 Fehlende Ergebnisprüfung nach AUTHORITY-CHECK 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. 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. 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

11 AUTH-06 Unvollständiger AUTHORITY-CHECK 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. 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. 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

12 AUTH-07 Proprietäre Berechtigungsprüfung (sy-uname) 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. 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. 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

13 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

14 TEST-01 Versteckter ABAP Code 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. 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. Die Verwendung von Techniken, die das Lesen von Quellcode verhindern muss per Entwicklungsrichtlinie verboten sein

15 TEST-02 Systemabhängige Ausführung 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. 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 = 'viktor@datenklau.ru'. ELSE. lv_mailtarget = 'admin@example.org'. ENDIF. 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

16 TEST-03 Mandantenabhängige Ausführung 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. 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 = 'viktor@datenklau.ru'. ELSE. lv_mailtarget = 'admin@example.org'. ENDIF. 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

17 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

18 DAT-01 Datenlecks 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. 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. 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)

19 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 < %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

20 INJ-01 ABAP Command Injection 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. 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. 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

21 INJ-02 OS Command Injection 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. Es ist zu beobachten, dass Entwickler von folgenden ABAP Befehlen Gebrauch machen, um generisch Betriebssystemkommandos auszuführen: CALL 'SYSTEM' CALL 'ThWpInfo' OPEN DATASET FILTER CALL 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. 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

22 INJ-03 Native SQL Injection 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. 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. 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

23 INJ-04 Directory Traversal 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. 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. 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

24 INJ-05 Open SQL Injection 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. 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 '%' 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 ). CONCATENATE `bname=` lv_safe INTO lv_where DELETE FROM usr01 WHERE (lv_where).

25 INJ-06 Cross-Site Scripting 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. 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: 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 Hinweis Hinweis Hinweis offizielle Dokumentation bzgl HTMLB Encodierung - offizielle Dokumentation bzgl forceencode - offizielle Dokumentation bzgl forceencodeotr - offizielle Dokumentation verschiedener Encodierungsfunktionen

26 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

27 MECH-01 Zugriff auf Daten eines anderen Mandanten 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. 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. 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

28 Sollte es wichtige Gründe für den Einsatz von mandantenübergreifenden Zugriffen geben, so muss detailliert dokumentiert werden, wo und warum dies geschieht

29 MECH-02 Generische Ausführung von Programmen oder Funktionen 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. 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. 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

30 - 30 -

31 MECH-03 Generischer Zugriff auf Tabelleninhalte 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. 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( ). 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

32 - 32 -

33 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: "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 Ü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

34 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