Maschinenraum · Auftakt einer Reihe
Editorischer Hinweis: 2018 stand an dieser Stelle eine kurze Notiz mit dem Titel „Neue Serie“. Die Serie ist nie geschrieben worden. Dieser Beitrag löst das Versprechen ein — und zwar nicht als Einzelartikel, sondern als durchgehende Reihe mit jeweils einem begleitenden, lauffähigen Beispiel im GitHub-Repository ABAP_Evildoers.
Warum der eigene Code das unterschätzte Risiko ist
Wenn über SAP-Sicherheit gesprochen wird, geht es fast immer um dieselben Themen: Profilparameter, Standardbenutzer, Berechtigungen, Patch-Stände, Gateway- und Message-Server-Härtung. Das ist richtig und wichtig, aber es ist nur die halbe Wahrheit. Die andere Hälfte sitzt im kundeneigenen ABAP-Quellcode, und genau dort schaut bei den allermeisten Sicherheitsbetrachtungen niemand hin.
Das ist erstaunlich, denn der Eigencode ist die Stelle, an der ein SAP-System am individuellsten, und damit am wenigsten standardisiert geprüft ist. Individuelle Entwicklungen sind in nahezu jeder SAP-Landschaft geschäftskritisch: Sie bilden Prozesse ab, die der Standard nicht kennt, greifen tief in zentrale Systemfunktionen ein, verarbeiten sensible Daten und laufen häufig mit weitreichenden Berechtigungen. Damit entsteht eine zusätzliche Angriffsfläche, die mit jeder Eigenentwicklung wächst und die von außen nicht sichtbar ist.
Verschärft wird das Ganze durch die Biografie dieses Codes. Kundeneigener ABAP-Code ist über Jahre, oft über Jahrzehnte gewachsen. Er wurde von wechselnden Teams betreut, von externen Dienstleistern ergänzt, unter Zeitdruck „mal eben“ erweitert und enthält historische Muster, die zum Zeitpunkt ihrer Entstehung üblich waren und heute als gefährlich gelten. Niemand hat den vollständigen Überblick. Und genau in dieser Gemengelage sammeln sich die Schwachstellen an: fehlende oder umgangene Berechtigungsprüfungen, unzureichende Validierung von Eingaben, unsichere Aufrufe kritischer Systemfunktionen, hartcodierte Geheimnisse, vergessene Debugging-Konstrukte.
In Zeiten zunehmender Cyberbedrohungen, wachsender Automatisierung und strenger werdender Regulatorik (NIS-2, DORA, branchenspezifische Anforderungen) ist die Absicherung des Eigencodes deshalb kein „Nice to have“ mehr, sondern Bestandteil jeder ernstgemeinten SAP-Security-Strategie. Eine einzelne dieser Schwachstellen ist selten dramatisch. Aber eine Häufung einfacher Schwächen reichert sich zu einem kritischen Angriffsszenario an und im schlimmsten Fall ist die Integrität des gesamten Systems betroffen.
Die ABAP-Laufzeitumgebung: Schutzschild und trügerische Sicherheit
Um zu verstehen, warum ABAP-Schwachstellen anders gelagert sind als in klassischen Sprachen, muss man die Laufzeitumgebung kennen. ABAP ist hier ein Sonderfall.
Anders als C oder Java wird ABAP nicht als nativer Maschinen- oder Bytecode ausgeführt, der direkt mit dem Betriebssystem spricht. Der Code läuft vollständig innerhalb einer kontrollierten Runtime, die der SAP-Kernel bereitstellt. Programme werden in einen intermediären Bytecode übersetzt, den ausschließlich die ABAP Virtual Machine interpretiert. Diese Architektur wirkt wie eine Sandbox: Systemnahe Operationen wie Datenbankzugriffe, Dateiverarbeitung, Netzwerkaufrufe sind abstrahiert und nur über klar definierte, vom Kernel überwachte Schnittstellen erreichbar.
Im Vergleich zu C, das direkten Speicherzugriff und Pointer-Arithmetik erlaubt, ist der ABAP-Entwickler von der ganzen Klasse risikoanfälliger Low-Level-Operationen weitgehend abgeschirmt. Klassische Speicherkorruption wie Buffer Overflows, Use-after-free gibt es in ABAP praktisch nicht. Und selbst gegenüber Java, das ebenfalls eine VM nutzt, ist die ABAP-Runtime deutlich restriktiver: Viele potenziell gefährliche Funktionen existieren gar nicht oder sind nur über spezielle, streng geregelte Kernelaufrufe erreichbar.
Das klingt beruhigend, aber genau hier liegt die Falle. Das Runtime-Design schützt vor technischen Fehlerklassen, nicht vor logischen. Es verhindert keinen einzigen der folgenden Fehler:
- eine Berechtigungsprüfung, die schlicht fehlt;
- einen Benutzervergleich, der das Berechtigungskonzept umgeht;
- ein hartcodiertes Passwort im Quelltext;
- den Aufruf eines deprecateten Kernel-Kommandos, das Betriebssystembefehle ausführt;
- einen schreibenden Zugriff auf eine Repository-Tabelle, der den Quellcode anderer Programme verändert.
Gerade weil die ABAP-Runtime so viele technische Risiken abfedert, verschiebt sich das Gewicht auf die semantischen und prozessbezogenen Schwachstellen. Das sind die Fehler, die kein Compiler und keine VM abfangen kann und die deshalb eine gezielte Code-Sicherheitsanalyse zwingend erforderlich machen.
Hinzu kommt die enge Verzahnung von Laufzeit, Oberfläche (Dynpro/SAP GUI bzw. Fiori) und Backend-Logik. Da die Verarbeitung serverseitig erfolgt und die UI kaum eigene Logik trägt, konzentriert sich das sicherheitsrelevante Geschehen in den Verarbeitungsschichten. Eine Schwachstelle im Code betrifft deshalb nicht nur „ein Programm“, sondern potenziell Transaktionalität, Benutzerführung und Prozessintegrität gleichzeitig.
Was eine Code-Analyse leisten kann und was nicht
Bevor diese Reihe in die einzelnen Muster einsteigt, ein Wort zur Methode, denn die Aussagekraft eines Befunds hängt davon ab, wie er entstanden ist.
Die Analysen, aus denen diese Reihe schöpft, basieren auf einer methodischen Stichprobenprüfung mit SAP-Bordmitteln. Kern ist der Standard-Report RS_ABAP_SOURCE_SCAN, ergänzt um ein eigenes Set spezifischer Suchmuster und Prüfkriterien. Diese Muster decken die typischen Risikobereiche ab: Remote Code Injection und Remote Code Execution, kritische Funktionsaufrufe und kernelnahe Operationen, direkte Web- und RFC-Aufrufe sowie Verstöße gegen den SAP Secure Programming Guide.
Wichtig ist die ehrliche Einordnung dieser Methode: Ein Pattern-Scan liefert Indikatoren, keine Urteile. Jede Trefferliste muss anschließend manuell bewertet werden, um Fehlalarme von echten Risiken zu trennen und den Befund im fachlichen Kontext einzuordnen. In den Projekten, aus denen diese Reihe entstanden ist, geschah das zweistufig: erst die Detailanalyse jeder Fundstelle, dann eine abschließende qualitative Sichtung der Gesamtliste mit der ausdrücklichen Frage, ob sich Hinweise auf bewusste Manipulation oder böswillige Absicht finden. Dieses Vorgehen reduziert das Risiko, etwas Relevantes zu übersehen.
Ebenso ehrlich: Ein solcher Scan ersetzt keine vollwertige statische Tiefenanalyse, wie sie ein spezialisiertes Werkzeug wie der SAP Code Vulnerability Analyzer (CVA) leistet. Der CVA bringt Datenflussanalysen, Kontextbewertung und Checks für komplexe Risiken mit. Der CVA sieht, ob eine unsichere Eingabe tatsächlich bis zu einer gefährlichen Senke fließt. Der Stichprobenscan ist demgegenüber der vorbereitende, risikoorientierte erste Schritt: Er macht Handlungsfelder sichtbar, auf denen eine umfassende Prüfung aufsetzen kann.
Der Prüfumfang umfasste konsequent die kundenindividuellen Namensräume Z* und Y* sowie reservierte kundeneigene Namensräume. Damit sind sowohl klassische Erweiterungen als auch unternehmensspezifische Komponenten abgedeckt aber der SAP-Standardcode selbst bleibt außen vor, denn dafür ist SAP zuständig, nicht der Kunde.
Die Mustergalerie: das kommt in dieser Reihe
Die folgende Tabelle ist der Bauplan der Reihe. Jedes dieser Muster bekommt einen eigenen Beitrag mit Risikobeschreibung, Bewertung und konkreter Maßnahm. Im Github-Repository ABAP_Evildoers ist jeweils ein lauffähiges Beispiel, an dem sich Scanner und Prüfungen kalibrieren lassen.
| Muster | Worum es geht | Einstufung |
|---|---|---|
CALL SYSTEM | Ausführung von Betriebssystembefehlen aus ABAP heraus (deprecated) | Hoch |
BREAK-POINT in Produktion | Vergessene Debugging-Konstrukte im Produktivcode | Medium |
Hartcodierte URLs (CREATE_BY_URL) | Direkte externe Verbindungen ohne zentrale Governance | Medium |
| Hartcodierte Passwörter | Zugangsdaten im Klartext im Quellcode | Hoch |
IF SY-UNAME = '…' | Benutzervergleich statt Berechtigungsprüfung | Hoch |
IF SY-MANDT = '…' | Mandantenabhängige Logik per Hardcoding | Medium |
REPOSRC (UPDATE/MODIFY) | Schreibender Zugriff auf den Repository-Quellcode | Sehr hoch |
USR02-BCODE | Auswertung veralteter, unsicherer Passwort-Hashes | Hoch |
Jeder dieser Beiträge folgt demselben Aufbau: zuerst das Muster und warum es entsteht, dann die Risikobeschreibung und -bewertung, schließlich die Maßnahme. Und ebenso ein Verweis auf das passende Beispiel im Repository.
Ausblick: Get Clean, Stay Clean
Die einzelnen Muster zu kennen ist die eine Sache. Sie in einer gewachsenen Landschaft mit zehntausenden Eigenobjekten systematisch loszuwerden und dauerhaft draußen zu halten, ist eine andere — und es ist eine Projekt-, keine Bastelaufgabe. Genau dafür hat sich das Begriffspaar Get Clean / Stay Clean etabliert: der einmalige, strukturierte Bereinigungsprozess auf der einen Seite, die kontinuierliche Qualitätssicherung auf der anderen.
Wie man so ein Projekt aufsetzt, ohne dass es in der Trefferliste erstickt, ist Thema des nächsten Beitrags. Danach gehen wir Muster für Muster durch.
Nächster Beitrag in dieser Reihe: „Get Clean & Stay Clean — wie man ein Eigencode-Sicherungsprojekt wirklich aufsetzt“.
