Sicherheit von SAP in Bezug auf neue Technologien

Diplomarbeit 

in 

Computer Networking 

Sicherheit von SAP in Bezug auf 

neue Technologien 

Damian Schlager 

1. Betreuer: Prof. Dr. Christoph Reich 

2. Betreuer: Dipl.-Inf. Stefan Strobel (cirosec GmbH) 

Vorgelegt am: 20.2.2008 

Vorgelegt von: 


Johannesburgerstraße 18/1, 74081 Hork

Sicherheit von SAP in Bezug auf neue Technologien 

Abstract 

Diese Diplomarbeit befasst sich mit der Sicherheit von Webapplikationen auf 

Basis von SAP. Diese wurden trotz zunehmender Verbreitung bisher nie unter 

den bekannten Sicherheitsgesichtspunkten von Webapplikationen betrachtet. 

Ziel der Diplomarbeit ist es daher, Webapplikationen von SAP-Systemen auf ihre 

Sicherheit hin zu überprüfen und diese, wo möglich, in Bezug zu setzen mit den 

bekannten Problemen klassischer Webanwendungen. 

Hierzu wurden sowohl eine klassische Webapplikation als auch 

Webapplikationskomponenten von SAP-Systemen mittels Methoden, wie sie in 

der Praxis Verwendung finden, auf ihre Anfälligkeit gegenüber Angriffen und auf 

Absicherungsmöglichkeiten hin überprüft. 

Hierbei zeigte sich, dass Webapplikationen auf Basis von SAP ebenfalls für zum 

Teil neuartige Webapplikationsangriffe anfällig sind, sich aber auch mittels 

bekannter Methoden absichern lassen. Die Ergebnisse dieser Diplomarbeit stellen 

die Basis für zukünftige Überprüfungen und Absicherungen von Sap-Systemen 

dar. 

This diploma thesis addresses the security of web applications based on SAP. 

These were despite their increasing distribution never evaluated according to the 

known aspects of security that can be found in web applications. 

Hence, the purpose of this diploma thesis was to evaluate the security of web 

applications of SAP systems and to relate them to the known problems of classic 

web applications where possible. 

Therefore a classic web application and components of web applications of SAP 

systems were tested for their sensitivity to attacks as well as for possibilities to 

secure them, using methods that are found in practice. 

It appeared that web applications based on SAP are also vulnerable to web 

application attacks that were partially novel, but that they can be secured using 

known methods as well. The result of this diploma thesis is the base for future 

audits and measures to secure SAP systems. 


Seite I



Seite II


Inhalt 

1 Einleitung ......................................................................................... 1 

1.1 Problemstellung .......................................................................... 1 

1.2 Zielsetzung................................................................................. 1 

1.3 Aufbau dieser Arbeit .................................................................... 2 

2 Rahmenbedingungen .......................................................................... 3 

2.1 Beschreibung des technischen Umfeldes ......................................... 3 

2.1.1 Klassische Webapplikation...................................................... 3 

2.1.2 ERP..................................................................................... 4 

2.2 Sicherheitsaspekte im Webumfeld.................................................. 9 

2.2.1 Sicherheit allgemein .............................................................. 9 

2.2.2 Menschliche Aspekte ........................................................... 11 

2.2.3 Technische Aspekte............................................................. 13 

2.2.4 Übergreifende Aspekte......................................................... 16 

2.2.5 Betrachtungsweisen der Sicherheit ........................................ 17 

2.2.6 Einordnung dieser Diplomarbeit ............................................ 19 

2.3 Gefahren und Angriffe im Webumfeld ........................................... 19 

2.3.1 Inhalte und Ziele des Kapitels ............................................... 19 

2.3.2 Port 80 Problem.................................................................. 19 

2.3.3 Fehlerquellen in Webapplikationen......................................... 21 

2.3.4 Beschreibung der Webapplikationsangriffe .............................. 23 

2.4 Zusammenfassung .................................................................... 28 

3 Vergleich klassischer Webapplikationen mit SAP aus Angreifersicht.......... 29 

3.1 Webapplikationsscanner ............................................................. 29 

3.2 Angriffe auf Webapplikationen ..................................................... 30 

3.2.1 Typische Angriffe ................................................................ 30 

3.3 Angriffe auf SAP ........................................................................ 39 

3.3.1 Abgrenzung der Methodik zur Sicherheitsüberprüfung .............. 39 

3.3.2 Typische Angriffe ................................................................ 42 

3.3.3 Manuelle Überprüfung und weitere Ansatzpunkte für Angriffe .... 50 

3.3.4 Heterogene Systeme ........................................................... 56 

3.4 Vergleich der Ergebnisse ............................................................ 58 


4 Vergleich klassischer Webapplikationen mit SAP aus Verteidigersicht ....... 62 

4.1 Sicherheitsarchitekturen ............................................................. 63 

4.2 Web Application Firewalls ........................................................... 67 

4.3 Absicherungsmöglichkeiten klassischer Webapplikationen................ 70 

4.4 Absicherung des ERPs anhand von SAP......................................... 75 

4.5 Aufwand und erzielbare Ergebnisse bei der Absicherung.................. 82 


5 Zusammenfassung der Ergebnisse und Ausblick ................................... 86 

5.1 Zusammenfassung der Ergebnisse ............................................... 86 

5.2 Ausblick ................................................................................... 87 

6 Literaturverzeichnis .......................................................................... 89 

7 Glossar........................................................................................... 91 

8 Anhänge ......................................................................................... 94 

8.1 Anhang A: Beschreibung der Komponenten des SAP NetWeavers ..... 94 

8.2 Anhang B: Konfigurationsempfehlungen und Programmierrichtlinien .96 

8.3 Anhang C: Sicherheit on RFC..................................................... 100 


Seite III


Abbildungsverzeichnis 

Abbildung 1: Organisatorischer Aufbau des SAP NetWeavers .......................... 7 

Abbildung 2: Technischer Aufbau des SAP Netweavers................................... 8 

Abbildung 3: Port 80 Problem ...................................................................20 

Abbildung 4: Verteilung der Angriffshäufigkeit .............................................27 

Abbildung 5: Scan klassischer Webapplikation .............................................31 

Abbildung 6: Robots.txt ...........................................................................32 

Abbildung 7: Cross-Site-Scripting bei cirobank ............................................33 

Abbildung 8: Local-file-inclusion ................................................................35 

Abbildung 9: manuelles Cross-Site Scripting-cirobank...................................36 

Abbildung 10: Manuelle Local-File-Inclusion ................................................37 

Abbildung 11: SQL-Injection .....................................................................39 

Abbildung 12: WebInspect Plugin ..............................................................43 

Abbildung 13: 200 OK - not found .............................................................44 

Abbildung 14: WebInspect: Defaultpolicy bei SAP ........................................45 

Abbildung 15: Possible SQL Injection bei SAP ..............................................46 

Abbildung 16: False-Positives bei SAP ........................................................48 

Abbildung 17: Beispiel false-Positive .........................................................48 

Abbildung 18: Interne Pfade .....................................................................49 

Abbildung 19: Neuer HTTP Filter................................................................51 

Abbildung 20: Cross-Site-Scripting bei SAP .................................................51 

Abbildung 21: Source Code Disclosure........................................................55 

Abbildung 22:Aufbau einer heterogenen Umgebung .....................................56 

Abbildung 23: Directory-Listing mit Versionsangabe .....................................57 

Abbildung 24: Cross-Site-Scripting in Parameter..........................................58 

Abbildung 25: Topologiebeispiel Webapplikation BSI ....................................64 

Abbildung 26: Topologiebeispiel Webapplikation ..........................................64 

Abbildung 27: Empfohlene Topologie SAP ...................................................65 

Abbildung 28: Arbeitsweise WAF ...............................................................69 

Abbildung 29: Anzupassende Regel............................................................72 

Abbildung 30: Gelockter Angriff bei Citrix ...................................................72 

Abbildung 31: Dynamisches Regelwerk.......................................................73 

Abbildung 32: Statisches Regelwerk...........................................................74 

Abbildung 33: Geblockter Angriff bei NetContinuum .....................................74 

Abbildung 34: Geblocktes Parameter Tempering ..........................................75 

Abbildung 35: Einfache Diensteaktivierung im SAP GUI.................................77 

Abbildung 36: SAP Portal-URL ...................................................................80 

Abbildung 37: Gelerntes Regelwerk für das SAP Portal..................................81 

Abbildung 38: Verallgemeinertes Regelwerk für das SAP Portal ......................81 

Abbildung 39: Gleichartige Fehlermeldungen im Logfile.................................82 

Abbildung 40: Diensteabhängigkeit bei SAP ................................................83 

Tabellenverzeichnis: 

Tabelle 1: Anzahl der SAP URLs.................................................................40 

Tabelle 2: SAP Standardaccounts ..............................................................53 


Seite IV


1 Einleitung 

1.1 Problemstellung 

Neue Technologien, mit dem Ziel Applikationen über Web verfügbar zu 

machen, halten überall Einzug. So hat auch SAP neue Produkte auf den 

Markt gebracht, die den Zugang zu SAP einfacher und flexibler gestalten 

sollen. 

Erfahrungen aus anderen Bereichen zeigen aber, dass eine solche 

Umstellung oder Erweiterung häufig mit Sicherheitsproblemen einhergeht. 

Da die Verfügbarkeit und Sicherheit dieser Systeme jedoch unverzichtbar 

ist, gewinnt eine Sicherheitsuntersuchung besondere Bedeutung. 

Während die Möglichkeiten zur Absicherung von klassischen 

Webapplikationen, die beispielsweise mittels Apache und PHP realisiert 

sind, relativ gut bekannt sind, ist die Sicherheitsbetrachtung neuer 

Webtechnologien, wie beispielsweise die von SAP, noch weitgehendes 

Neuland. Der steigenden Nachfrage nach Sicherheitsüberprüfungen und der 

Absicherungen von klassischen Webapplikationen kann heute durch 

Fachkenntnis und entsprechende Produkte begegnet werden. Für die Webbasierten 

Komponenten von SAP fehlen im Moment jedoch noch die dazu 

erforderliche Fachkenntnis, sowie speziell angepasste Sicherheitsprodukte. 

1.2 Zielsetzung 

Ziel der Diplomarbeit ist es, die neuen, sicherheitskritischen 

Webapplikationen von SAP-Systemen auf ihre Sicherheit hin zu überprüfen 

und diese, wo möglich, mit den bekannten Problemen klassischer 

Webanwendungen in Bezug zu setzen. 

Es sollen vor allem die für die praktische Arbeit bei einer Auditierung oder 

Absicherung von Webapplikationen relevanten Gesichtspunkte 

herausgearbeitet werden. Diese sollen anhand praktischer Beispiele 

zunächst auf Webapplikationen auf Basis von SAP übertragen werden, um 

eine Aussage über die Anfälligkeit bzw. Resistenz von Webapplikationen 

von SAP gegenüber bekannten Webapplikationen treffen zu können. Des 

Weiteren ist zu untersuchen, ob Webapplikationen auf Basis von SAP neue 

Verwundbarkeiten aufweisen, die in eine Überprüfung mit einfließen 

müssen. Analog hierzu ist die Eignung bekannter 

Absicherungsmöglichkeiten für Webapplikationen auf Basis von SAP zu 

Damian Schlager Seite 1


untersuchen. Die Ergebnisse der Sicherheitsüberprüfung sowie die 

entsprechenden Absicherungsmöglichkeiten klassischer Webapplikationen 

werden mit den von SAP-Webapplikation verglichen und anschließend in 

einen Gesamtzusammenhang gestellt. 

Die Erkenntnisse dieser Diplomarbeit sollen dazu verwendet werden, 

zukünftig qualifizierte Sicherheitsüberprüfungen bzw. Absicherungen von 

Webapplikationen auf Basis von SAP durchführen zu können und damit 

zusammenhängend Aussagen über die allgemeine Sicherheit von 

Webapplikationen auf Basis von SAP treffen zu können. 

1.3 Aufbau dieser Arbeit 

Die vorliegende Diplomarbeit ist in drei große Bereiche unterteilt. 

Der erste Teil beschäftigt sich mit den Rahmenbedingungen dieser 

Diplomarbeit. Dies besteht sowohl aus technischen Grundlagen über 

Webapplikationen und SAP-Systeme, als auch einer Beschreibung der 

Sicherheitsprobleme bei Webapplikationen, die für Angriffe verwendet oder 

vor deren Verwendung geschützt werden muss. Außerdem fügt dieser Teil 

der Arbeit die folgenden Kapitel in einen größeren Zusammenhang ein, so 

dass die Bewertung der Ergebnisse und Aussagen der folgenden Kapitel 

besser in eine Gesamtbetrachtung der Sicherheit eingeordnet werden kann. 

Der zweite Teil dieser Arbeit beschäftigt sich mit der Sicht eines Angreifers 

einer Webapplikation, wie es für die Durchführung von 

Sicherheitsüberprüfungen relevant ist. Hier wird sowohl eine klassische 

Webapplikation als Referenz als auch Webapplikationen von SAP-Systemen 

überprüft. Der Fokus liegt hierbei sowohl auf Anwendung bekannter 

Webapplikationsangriffe als auch einer Überprüfung neuer Angriffswege auf 

SAP, die von klassischen Webapplikationen nicht bekannt sind. 

Im dritten Teil werden die Absicherungsmöglichkeiten von 

Webapplikationen auf Basis von SAP evaluiert. Auch hier wird ein Vergleich 

von klassischer Webapplikation und Webapplikation auf Basis von SAP 

gezogen und sowohl das mögliche Sicherheitsniveau als auch der dazu 

notwendige Aufwand bewertet. 

Abgeschlossen wird diese Diplomarbeit mit einem Fazit über die 

gewonnenen Erkenntnisse und einem Ausblick über die erwartete, 

zukünftige Entwicklung der in dieser Diplomarbeit behandelten Themen. 



2 Rahmenbedingungen 

Dieses Kapitel beschreibt die Rahmenbedingungen für die 

Sicherheitsüberprüfung, die für diese Diplomarbeit durchgeführt wurde. Es 

wird zunächst das technische Umfeld beschrieben. Hierzu wird sowohl die 

als Beispiel herangezogene klassische Webapplikation und deren 

dahinterliegende Technik beschrieben, als auch das SAP-System, das in 

dieser Diplomarbeit als Beispiel für ERP Systeme dient. 

Des Weiteren werden die für diese Diplomarbeit relevanten 

Sicherheitsaspekte in eine Gesamtbetrachtung des Themas Sicherheit von 

IT-Systemen und deren Aspekten eingeordnet. Abschließend werden die 

Ursachen der in dieser Diplomarbeit näher betrachteten Angriffe auf 

Webapplikationen aufgezeigt, sowie die Grundlagen der in dieser 

Diplomarbeit thematisierten Webapplikationsangiffe beschrieben. 

2.1 Beschreibung des technischen Umfeldes 

2.1.1 Klassische Webapplikation 

Webapplikationen und ihr Einsatz 

Webapplikationen haben ihren Ursprung in Client-Server-Strukturen, bei 

den das Programm auf einem Server läuft, der Benutzer dieses aber über 

einen anderen Computer entfernt bedienen kann. Ein Beispiel hierfür ist die 

SAP-GUI, welche einem Benutzer den Zugriff auf SAP-Systeme ermöglicht. 

Die eigentlichen SAP-Inhalte werden jedoch auf zentralen, leistungsfähigen 

Servern generiert und bereitgestellt. 

Bei Webapplikationen gibt es nicht mehr einen speziellen Client, sondern 

hier werden die Inhalte vom Server so aufbereitet, dass sie mit gängigen 

Webbrowsern dargestellt werden können. Dies bringt verschiedene Vorteile 

mit sich, Beispiel hierfür ist, dass bei einer Änderung des Programms nicht 

mehr auch die Clients neu ausgerollt werden müssen, was vor allem bei 

größeren Unternehmen schwierig ist und sich daher mit Hilfe der 

Webapplikationen Kostenvorteile ergeben. 

Eine Webapplikation ist außerdem universeller einsetzbar, sowohl aus 

Benutzersicht, da er nicht mehr an das spezielle Client-Programm 

gebunden ist und hier mit dem üblicherweise bereits vorhandenen 

Webbrowser arbeiten kann, als auch beispielsweise aus Netzwerk- und 

Betriebssystemsicht. 



Die Bedienung von Webapplikationen erfolgt über Hyperlinks. Bekannte 

Programmelemente wie Buttons, Auswahllisten etc. können mittels HTML- 

Elementen abgebildet werden. Daten, die vom Client zum Server gesendet 

werden, können als HTTP-POST- bzw. HTTP-GET-Parameter sowie mittels 

HTTP Headern und Cookies übertragen werden. Nachdem alle Parameter 

auf diese Weise beim Server angekommen sind, werden diese an das 

Server-Programm weitergeleitet und dort verarbeitet. Das Ergebnis dieser 

Verarbeitung wird dann als Webseite dargestellt und der beschriebene 

Ablauf kann wieder von vorne beginnen. 

cirobank 

Als Referenz für eine klassische Webapplikation wird in dieser Diplomarbeit 

die „cirobank“ verwendet. Es handelt sich hierbei nicht um eine im Internet 

verfügbare Anwendung, was sich aus Gründen der Vertraulichkeit verbietet, 

sondern um eine für Demonstrationszwecke bei der cirosec GmbH erstellten 

Webapplikation. 

Auch wenn die Webapplikation speziell zu Demonstrationszwecken erstellt 

wurde, spiegelt sie dennoch wieder, welche typischen Probleme auch bei 

Webapplikationen möglich sind, die sich im Internet oder in Intranets von 

Unternehmen finden. Tatsächlich werden bei Sicherheitsüberprüfungen 

häufig solche Lücken vorgefunden und können auch mit einem 

vergleichbaren Aufwand ausgenutzt werden. 

Die Webapplikation, die in dieser Diplomarbeit als Referenzapplikation 

verwendet wird, besteht aus folgenden Komponenten: 

Client: - Browser; beliebiger Rechner 

Server: - Ubuntu 6.10 mit Apache 2.0.55, PHP 5.1.6 

- Windows Server 2003 mit MS SQL Server 2005 

2.1.2 ERP 

ERP-Systeme und ihr Einsatz 

Unter ERP-Systemen versteht man eine komplexe Anwendungs-Software, 

die zur Unterstützung der Ressourcenplanung des, im Idealfall, gesamten 

Unternehmens dient 1 . 

ERP-Systeme haben ihren Ursprung in Industriebetrieben. Dieses Konzept 

wurde dann auch in andere Bereiche übernommen. So haben sich die 

1 http://de.wikipedia.org/wiki/Enterprise_Resource_Planning 



ursprünglichen ERP-Systeme weiter entwickelt bis sie praktisch überall 

eingesetzt wurden 2 . Die Weiterentwicklung der ERP-Systeme schreitet auch 

weiter voran und ERP-Systeme beinhalten immer mehr Funktionen und 

Fähigkeiten zum einen, und sollen zum anderen besser erreichbar und 

verfügbar sein, wofür man zunehmend auf webbasierte Technologien setzt. 

Die Idee der weitergehenden Vernetzung und Vereinheitlichung der 

Schnittstellen greift das Konzept von ERP II auf. Hier beschränkt sich das 

ERP-System nicht auf die Unternehmensgrenzen, sondern versucht auch 

Kunden, Lieferanten, Partnerunternehmen etc. mit zu integrieren, was zu 

Herausforderungen bei der Interoperabilität, Erreichbarkeit, Verfügbarkeit 

und Sicherheit führt. Auch im Rahmen dieser Entwicklung wird zunehmend 

auf webbasierte Technologien gesetzt, um die Integration verschiedenster 

Systeme und Bereiche zu erreichen. 

Allen ERP-Systemen gemein ist, dass sie versuchen, einzelne Daten von 

verschiedensten Stellen in einem System zusammenzuführen. Des 

Weiteren ist ein zentrales Ziel von ERP-Systemen die Unterstützung von 

Geschäftsprozessen und diese so effizient wie möglich zu gestalten. 

Insgesamt sorgt ein ERP-System also für eine Zusammenführung und 

Effizienzsteigerungen von Systemen, die zuvor inkompatibel zueinander 

waren und sogenannte Insellösungen darstellten, und die nun als 

integrierter Teil von Geschäftsprozessen und Daten arbeiten. 

Der Aufbau eines ERP-Systems, das diese Ziele erfüllen soll, ist eine 

komplizierte Aufgabe, deren Durchführung zwischen drei Monaten und 

einem Jahr in Anspruch nehmen kann. 

Für diese Diplomarbeit wurde ein ERP-System beispielhaft herangezogen, 

um eine entsprechende Evaluierung durchzuführen. 

Die Marktanteile von Anbietern in Deutschland setzen sich wie folgt 

zusammen 3 : 

SAP: ~55% 

Info: ~5,5% 

Microsoft: ~4% 

Sage: ~3% 

Viele kleinere Anbieter 

2 http://www.tech-faq.com/erp.shtml 

3 http://www.computerwoche.de/top_100/software/546025/ 



Wie hier zu sehen ist, ist SAP mit über 50% Marktanteil mit Abstand 

größter Hersteller von ERP-Systemen, als auch mit 10,25 Milliarden Euro 

Umsatz im Jahr 2007 und 40.000 Kunden nahezu marktbeherrschend. 

SAP hat ebenfalls den Anspruch, alle Anforderungen an ein ERP bzw. ERP II 

System zu erfüllen sowie das sicherste System anzubieten. 

Neben vielen neuen Funktionen und Fähigkeiten, die einen Teil der 

gegenwärtigen Entwicklung von ERP-Systemen kennzeichnen arbeitet SAP 

auch an Merkmalen von ERP II wie z.B. ein Supplier Relationship 

Management, aber auch an Schnittstellen zu vielen anderen Produkten, z.B. 

Integration in Microsoft-Office-Komponenten. Insgesamt stellt SAP eine 

branchenübergreifende, allumfassende Lösung dar und ist daher äußerst 

komplex zu implementieren. 

Für den Aufbau eines SAP-Systems gibt es bereits Vorgangsmodelle, diese 

zielen aber darauf ab, die Komplexität des Gesamtsystems SAP zu einer 

konkreten Installation zu meistern. Daher liegt das Hauptaugenmerk auf 

Geschäftsprozessmodellierung und Datenmodellierung, aber nicht auf 

Sicherheitsgefährdungen oder deren Vermeidung durch besondere 

Architekturen oder andere Schutzmassnahmen. 

Besonders geeignet für diese Diplomarbeit ist jedoch SAP, weil SAP seit 

wenigen Jahren massiv auf die Nutzung von neuen Technologien setzt, vor 

allem auf die Verfügbarkeit im Web und Anbindung von Kunden, 

Lieferanten, Partner, etc. Hierfür ist ein neues Konzept entstanden, das auf 

diese Anforderungen zugeschnitten ist. 

Organisatorischer Aufbau des SAP NetWeavers 

Die NetWeaver-Plattform soll die Basis für die Entwicklung neuer Lösungen 

sein, die die Idee der service-orientierten Architektur (SOA) bei SAP 

umsetzt. Als offizieller Nachfolger von SAP R/3 dient es neben der Basis für 

neue Applikationen auch als Plattform für die Integration bestehender 

Anwendungen und soll einen Rahmen für sicheren und stabilen Code 

inklusive Codeverwaltung stellen. 

In Abbildung 1: Organisatorischer Aufbau des SAP NetWeavers sind die 

verschiedenen Bereiche des SAP NetWeavers schematisch dargestellt. 

Auf dem Bild ist zu sehen, dass SAP NetWeaver einen Rahmen um die von 

SAP getrennt behandelten Bereiche People Integration, Information 

Integration und Process Integration mit ihren jeweiligen Teilbereichen 

bildet und hierbei auch den SAP Application Server als einheitliche Plattform 

stellt. Umfasst wird dies durch ein übergreifendes Life Cycle Management 



und Composite Application Framework für die Entwicklung 

bereichsübergreifender Applikationen. 

Abbildung 1: Organisatorischer Aufbau des SAP NetWeavers 

Eine kurze Zusammenfassung dieser Bereiche und deren Rolle in der SAP 

Netweaver Gesamtkonzeption ist in Anhang A: Beschreibung der 

Komponenten des SAP NetWeavers zu finden. 

Technischer Aufbau des SAP NetWeavers 

Betrachtet man den technischen Aufbau des SAP NetWeaver ergibt sich 

wiederum ein anderes Bild, wie in Abbildung 2: Technischer Aufbau des SAP 

Netweavers gezeigt. 

Kern der Architektur ist der SAP Web Application Server, der aus vielen 

internen und externen Komponenten besteht, die wiederum über 

verschiedene Mechanismen miteinander kommunizieren 4 . 

4 

http://help.sap.com/saphelp_nw04/helpdata/de/84/54953fc405330ee10000000a114084/content.ht 

m 



Abbildung 2: Technischer Aufbau des SAP Netweavers 

Im Folgenden sind einige der zentralen Komponenten dieses Bildes näher 

beschrieben. Insbesondere den Schnittstellen, die von außen erreichbar 

sind, gilt ein besonderes Interesse, da hier die primären Angriffspunkte zur 

Sicherheitsüberprüfung zu finden sind. 

ICM: ICM steht für Internet Communication Manager und ist die zentrale 

Instanz für Verbindungen ins Internet. Dadurch, dass der Internet 

Communication Manager zunächst alle Zugriffe aus dem Internet entgegen 

nimmt, liefen auch über ihn der Grossteil der Tests, auch wenn hierbei 

natürlich andere Ziele hinter dem Internet Communication Manager das 

eigentlich Ziel waren, wie z.B. die Applikationslogik oder die Datenbank. 

Dispatcher: Der Dispatcher nimmt die Anfragen von den SAP GUIs 

entgegen, die bisher der Hauptkommunikationsweg von den Clients zum 

SAP Applikationsserver war. Eine weitere Aufgabe des Dispatchers ist es, 

die Anfragen auf die Workprozesse zu verteilen. 

Gateway: Das SAP Gateway ist die Kommunikationsschnittstelle für das 

SAP eigene RFC-Protokoll. Dies wird zur Kommunikation zwischen SAP 

Komponenten benutzt, oder zwischen SAP Komponenten und Komponenten 

von Drittherstellern. Da dies ebenfalls vor allem in bisherigen SAP 

Versionen ein zentraler Bestandteil war, und die Kommunikation über RFC 

sehr tief in die Kommunikation mit SAP-Systemen eingeht, war die dieser 

Kommunikationsweg eine zusätzlich zu dieser Diplomarbeit durchgeführte 

Überprüfung, deren Ergebnisse in Anhang C: Sicherheit on RFC kurz 

beschrieben werden. 



Message-Server: Der Message-Server ist ein weiteres System zur 

Kommunikation zwischen SAP-Systemen und dient in Erster Linie zum 

Lastausgleich. 

Wie hier ebenfalls gut zu erkennen ist, sind die Stacks für ABAP und JAVA 

vollständig getrennt. Beide verfügen über eigene Scheduling-Systeme und 

Arbeitsprozesse. Es ist möglich, auf einem SAP Web Applikation Server nur 

einen der beiden Stacks zu installieren, oder auch beide parallel. Sind beide 

Stacks installiert, gibt es unter Umständen Möglichkeiten, eine Komponente 

auf verschiedenen Wegen zu Veröffentlichen. Je nach Verwendung des 

JAVA- oder ABAP-Stacks und deren Kommunikationswegen ergeben sich 

völlig andere Angriffsvektoren, was eine generische Überprüfung erschwert. 

Vorhandene SAP-Systeme 

Nach erfolgter Installation standen für die weitere Arbeit mehrere Systeme 

bereit. Für diese Diplomarbeit wurde eine Installation unter Linux für SAP 

NetWaver 700 ABAP Stack sowie Windows Server 2003 für SAP NetWeaver 

700 JAVA Stack durchgeführt. Eine bereits bestehende SAP Installation, 

SAP NetWeaver 640 ABAP, wurde ebenfalls für zusätzliche Prüfungen 

genutzt. 

Ziel der Benutzung der Versionen 640 und 700 war es, grundsätzliche 

Vergleiche zwischen den Versionsständen ziehen zu können und mögliche 

Veränderungen und Entwicklungen aufzuzeigen. 

Zusammenfassend wurde die Diplomarbeit auf Basis der folgenden drei 

Systeme erstellt: 

NetWeaver 2004s Testdrive (Kernelversion 700, Systemname n4s) 

NetWeaver 2004s Trial (Kernelversion 700, Systemname sapj2e) 

Das zusätzliche SAP System mit Versionsstand 640 bestand aus: 

NetWeaver 2004 Testdrive (Kernelversion 640, Systemname nw4) 

2.2 Sicherheitsaspekte im Webumfeld 

2.2.1 Sicherheit allgemein 

Programme, Systeme, Netzwerke und Architekturen auf ihre Sicherheit hin 

zu überprüfen sind im Computerbereich zu einer weitgehend normalen 

Tätigkeit geworden. Doch sind für eine Sicherheitsbeurteilung auch immer 

die Fragen zu beantworten, was Sicherheit eigentlich bedeutet, was das 



Ziel bei einer Absicherung ist, welches ein angestrebter Sollzustand ist und 

auch welche Art von Gefahren damit reagiert werden kann. 

Eine allgemein akzeptierte Definition 5 der IT-Sicherheit, grenzt Sicherheit 

als einen Zustand ein, in dem 

keine Einbrüche in das System auftreten 

keine Unterbrechungen auftreten 

und kein Verlust von Daten auftreten 

Vertraulichkeit gewährleistet ist 

Authentizität gewährleistet ist 

IT-Systeme, die dies erfüllen sollen, müssen daher folgende Eigenschaften 

aufweisen: 

Verlässlichkeit von Systemen und Netzwerken 

Verfügbarkeit von Systemen und Daten 

Vertraulichkeit von Daten 

Integrität von Prozessen, Aktivitäten und Prozessen 

Zuordenbarkeit von Aktionen zu Personen 

Nachvollziehbarkeit von Aktionen 

Authentizität von Daten 

Es gibt inzwischen einige Standards, die sich auch mit IT-Sicherheit 

beschäftigen, wie z.B.COBIT, COSO oder das IT-Grundschutzhandbuch des 

BSI. Diese sollen es erleichtern, verschiedene Sicherheitsniveaus in der IT- 

Sicherheit im Allgemeinen zu erreichen. Neben diesen Standards werden 

vor allem Anforderungen für Compliance immer bedeutender, so dass sich 

hauptsächlich große Unternehmen um verschiedene Aspekte der Sicherheit 

kümmern müssen und diese zu einem ganzheitlichen Konzept zu vereinen, 

um die Anforderungen von z.B. SOX, Basel II oder PCI zu erfüllen. 

So wurden und werden auch für SAP-Installationen 

Sicherheitsüberprüfungen durchgeführt, doch unterscheiden sich diese 

fundamental von der Motivation, die dieser Diplomarbeit zugrunde liegt. 

Bisherige Sicherheitsüberprüfungen beruhen meist auf Compliance- 

Anforderungen, für deren Erfüllung gänzlich andere Faktoren relevant sind 

als bei der Prüfung im Rahmen dieser Diplomarbeit, die sich auf eine 

praktische Herangehensweise aus den Erfahrungen mit klassischen 

Webapplikationen stützt. 

5 Grundschutzhandbuch Bundesamt für Sicherheit in der Informationstechnik, Baustein 04 



Im Folgenden sollen verschiedene Aspekte aufgegriffen werden, die für die 

Sicherheit von Webapplikationen und Webapplikationen auf Basis von SAP 

besonders relevant sind und größtenteils durch Erfahrungen und Gespräche 

des Verfassers mit SAP-Beratern, Administratoren oder Anwendern erstellt 

wurden. Diese Punkte werden dann in diesem Zusammenhang konkreter 

beschrieben und im Bezug auf Webapplikationen und Webapplikationen auf 

Basis von SAP bewertet. 

2.2.2 Menschliche Aspekte 

Installation und Konfiguration durch Berater 

Gerade bei großen Unternehmen die auch zur Zielgruppe von SAP gehören 

sind IT-Abteilungen und Sicherheitsverantwortliche etabliert. Es besteht 

daher grundsätzlich die Möglichkeit, den Aufbau von neuen 

Webapplikationen durch gute Kenntnisse der technischen Themen und 

interner Organisationsstruktur durchzuführen, auch wenn dies z.B. aus 

Zeitmangel häufig nicht geschieht. 

Die Installation und Konfiguration von SAP-Systemen ist sehr komplex und 

zeitaufwändig. Daher wird üblicherweise auf externe, spezialisierte 

Dienstleister zurückgegriffen, die die Installation und Konfiguration 

vornehmen. Auch wenn dies nicht unbedingt negative Einflüsse auf die 

Funktionalität des Systems hat, kann die von externen Kräften 

durchgeführte Konfiguration unter Umständen doch die geforderten 

Eigenschaften nicht erfüllen, da z.B. Berechtigungen falsch gesetzt werden 

oder zu restriktive Berechtigungen wieder großzügig zurückgenommen 

werden. Damit direkt zusammenhängend ist die Tatsache, dass auch bei so 

lang angesetzten Projekten wie einer SAP-Installation die Zeit für die 

notwendigen Arbeiten knapp bemessen ist und der Fokus der Arbeit 

selbstverständlich bei der Lauffähigkeit des Systems liegt. Außerdem kann 

beobachtet werden, dass eine Konfiguration, bei der auch auf ein hohes 

Schutzniveau geachtet wird nicht notwendigerweise, aber doch häufig eine 

Konfiguration, die sich auf die Lauffähigkeit eines Systems konzentriert, 

verkompliziert. Darüber hinaus sind SAP-Installationen individuell und es 

gibt keine Installation bzw. darauf folgende Konfiguration, die umfassend 

für alle Systeme gleich ist. Damit geht einher, dass – so wie es keine 

umfassende, allgemeingültige Konfiguration gibt – auch keine 

allgemeingültige Konfiguration von Sicherheitseinstellungen existiert. Es 

gibt zwar Einstellungen, die auf nahezu jedem System getroffen werden 

sollten (Vgl. Kapitel 4.4), dies kann jedoch nicht die feingranularen 



Einstellungen wie eine spezifische Rechtevergabe ersetzen, die für jede 

Umgebung individuell getroffen werden müssen oder spezielle 

Einstellungen, die die Sicherheit von Webapplikationen verändern. 

Ebenfalls als Folge der oben genannten Punkten, so haben Gespräche mit 

SAP Beratern gezeigt, ist das Sicherheitsbewusstsein bei SAP Beratern eher 

gering, oder bekannte Möglichkeiten ein System sicherer zu gestalten 

werden wegen Zeitmangels unterlassen. 

Administratoren 

Administratoren sind ein zentrales Element bei der Absicherung auch von 

Webapplikationen. Die Umsetzung ist zwar oftmals mangelhaft, jedoch sind 

Konzepte und Strategien um auch Administratoren in ein 

Sicherheitskonzept zu integrieren bekannt 6 . 

Allerdings werden SAP-Systeme und andere Netzwerkkomponenten oder 

Systeme oftmals getrennt betrachtet. So wird von der „SAP Welt“ 

gesprochen, wenn es um Fragen von SAP Systemen geht und daher 

zuständige Netzwerkadministratoren oder für die Sicherheit zuständigen 

Mitarbeiter auch keine SAP Experten sind. Auch hier liegt der Fokus auf der 

Lauffähigkeit der Systeme. Die Sicherheitsthematik ist zwar bekannt, aber 

üblicherweise noch ein offener Punkt. Eine umfassende oder ins Detail 

gehende Evaluierung von Sicherheitsaspekten kann daher nur selten 

durchgeführt werden. Dies wird duch die zunehmende Öffnung von SAP 

nach außen, wie z.B. zu Partnern oder direkt ins Internet, auch ein 

zukünftiger Markt für Beratungsunternehmen darstellen. 

Anwender 

Anwender von Applikationen, klassischen Webapplikationen, als auch von 

SAP-Software werden zunehmend als Sicherheitsfaktor erkannt 7 . 

Das bekannteste Beispiel hierfür ist die Wahl von Passwörtern. Daher sollte 

die Applikation bzw. das ERP-System unter Anderem möglichst gute 

Sicherheitstechnologien und Methoden bereitstellen die den Anwender in 

ein Sicherheitskonzept integrieren, wie z.B. eine Password-Policy, bei der 

die Komplexität der Passwörter und deren Gültigkeitsdauer festgelegt wird 8 . 

6 Bundesamt für Sicherheit in der Informationstechnik: Leitfaden IT Sicherheit – IT-Grundschutz 

kompakt, http://www.bsi.de/gshb/Leitfaden/GS-Leitfaden.pdf 

7 http://www.conpro.ch/de/themen/information-security.aspx 

8 http://www.sans.org/resources/policies/Acceptable_Use_Policy.pdf 



2.2.3 Technische Aspekte 

Multi Tier Architektur 

Viele klassische Webapplikationen sind wie auch SAP NetWeaver selbst als 

3 Tier Architektur entworfen. Ein Frontend auf dem Client, die Middle Tier 

auf dem Applikationsserver und ein Backend mit allen Daten. Die 

Konstruktion als 3 Tier Architektur soll einige Vorteile bringen um typischen 

Problemen wie sie bei großen Systemen wie SAP auftreten und sorgt für 

eine bessere Abstraktion, Skalierbarkeit und Zuverlässigkeit des 

Gesamtsystems. 

Bei dieser 3 Tier Architektur ist der Client in erster Linie für die Darstellung 

zuständig und beinhaltet wenig oder gar keine Anteile and der 

Applikationslogik. Gerade bei SAP wird hier zunehmend Wert auf die 

Unabhängigkeit des Endgerätes gelegt bzw. über andere SAP Komponenten 

wie XI für diese Unabhängigkeit gesorgt. Da sich diese Diplomarbeit mit 

Webapplikationen befasst, ist in diesem Fall der Client ein gängiger 

Browser. Es wurde je nach Applikation auf Internet Explorer 7 oder 

aktuellen Firefox zurückgegriffen. 

Die Mittel- bzw. Applikationsschicht beinhaltet das, was man vereinfacht als 

serverseitige Dienste ansieht. Hier befindet sich die Business Logic, 

systemorientierte Dienste und weitere Programme, die unter Umständen 

zur Ausführung der Business Logic notwendig sind. Außerdem sind hier die 

Schnittstellen zu möglichen weiteren Programmen und Komponenten zu 

finden. Beim NetWeaver wird dieses Modell noch dahingehend erweitert, 

dass sich die Applikationslogik nicht auf einem einzelnen SAP System 

befinden muss, sondern eine eigene Form von WebServices verwendet 

werden kann. 

Die Datenbankschicht ist bei SAP wieder ähnlich den anderen Multi Tier 

Architekturen. SAP unterstützt neben der eigenen Datenbank MaxDB, die 

bei dieser Diplomarbeit verwendet wurde, auch andere Datenbanken als 

Backend wie z.B. Oracle. 

Soll die Sicherheit von SAP betrachtet werden, muss dies daher über alle 

Ebenen erfolgen, um alle beteiligten Komponenten abzudecken. Gleichzeitig 

stellt die Applikationsschicht den größten Anteil, da sich hier unter anderem 

die Logik der einzelnen Programmen, sämtliche Administrationswerkzeuge, 

die Schnittstellen nach außen, Benutzerverwaltung, Sitzungsverwaltung 

und diverse andere Komponenten befinden. 



Authorisierungsmodell 

Die Rechtevergabe auf Webapplikationen oder Teilen der Webapplikationen 

unterscheidet sich grundlegend von SAP-Systemen. Bei klassischen 

Webapplikationen liegt der Fokus meist auf Trennung einzelner Benutzer 

und einer eventuellen Abgrenzung zu einer Administrationsrolle. 

Die Ausgestaltung von Autorisierungsmodellen ist bei SAP besonders 

komplex, da sie sich auf das Gesamtsystem SAP beziehen. Die korrekte 

Rechtevergabe wird auch in dieser Diplomarbeit des öfteren ein Thema 

sein, weswegen hier näher auf das Authorisierungsmodell bei SAP 

eingegangen wird. 

Schon aufgrund der Größe und Komplexität von SAP Systemen arbeitet 

man auch hier mit einem hohen Abstraktionsniveau, das über die üblichen 

Rollenmodelle hinausgeht. Hier muss auch zwischen ABAP-Stack und Java- 

Stack unterschieden werden, da sich das Authorisierungsmodell zwischen 

beiden Stacks unterscheidet. Darüber hinaus verwenden beide Stacks 

unterschiedliche Benutzer, die nicht frei zwischen beiden Stacks 

übernommen werden können. Es ist zwar möglich, mit dem Java-Stack auf 

ABAP-Benutzer zuzugreifen und es wird hier auch ein Abgleich zwischen 

den Benutzerdatenbanken durchgeführt, doch sind Java-Benutzer dem 

ABAP-Stack unbekannt. 

Der ABAP-Stack baut auf einer rollenbasierten Benutzerverwaltung auf. 

Rollen und Benutzer sind hier vom System implementiert, wie es von 

anderen rollenbasierten Authorisierungssystemen bekannt ist. Hier 

bedeutet das z.B. dass nur die GUI-Inhalte angezeigt werden, die der Rolle 

oder dem Benutzer entsprechen. Des Weiteren müssen Berechtigungen 

vergeben werden, wer z.B. welche Buchung im System vornehmen darf. 

Um dies zu erleichtern, können Berechtigungsprofile für bestimmte 

Applikationen festgelegt werden, bei großen Applikationen gibt es darüber 

hinaus die Möglichkeit Sammelprofile zu verwenden, die mehrere Profile 

beinhalten. Rollen enthalten schon viele Profile für typische Rollen von 

Benutzern in einem Unternehmen, wie beispielsweise Administratoren. 

Beim Java-Stack, bzw. Portalapplikationen des Java-Stacks, basiert die 

Berechtigungsvergabe auf sogenannten Security-Zones. Portalapplikationen 

und Dienste müssen solchen Security Zones zugeordnet werden. Die 

Zuordnung erfolgt hierbei beim „Deployen“ einer Applikation, also bereits, 

wenn die Applikation in das SAP-Portal hineingeladen wird. Die 

Berechtigungen der Benutzer, Gruppen und Rollen werden dann auf die 



Security-Zones angewandt. Vordefinierte Security Zones sind z.B. 

low_safety, medium_safety und high_safety, wobei Applikationen zur 

Administration grundsätzlich high_safety zugeordnet sind. Sind die 

Berechtigungen korrekt vergeben, kann die entsprechende Applikation nach 

dem Deploy über die eindeutige URL, die zu der Applikation gehört, 

aufgerufen werden. 

Es kann durchaus vorkkommen, dass die Berechtigungen für den Aufruf der 

URL und damit der Applikation gegeben ist, aber nicht für die sogenannten 

IViews, aus denen die Applikation für den Benutzer aufgebaut ist. Ist dies 

der Fall, kann die Applikation bzw. Teile daraus über die URL aufgerufen 

werden, die Applikation ist jedoch nicht bedienbar, da die Rechte auf die 

IViews durch das setzen der Security Zones fehlen 9 . 

Programmierungsaspekte 

Wie in Kapitel 2.3.3 beschrieben wird, ist die sogenannte Eingabeprüfung 

ein zentraler Teil der Sicherheitsüberlegungen im Webumfeld um bösartige 

oder auch nur unerwartete Eingaben zu verhindern. Es ist hier bei neueren 

Versionen ein Fortschritt erkennbar, doch war der zentrale Gedanke bei der 

Eingabeprüfung seitens des SAP-Applikationsservers bisher zu verhindern, 

dass der Benutzer versehentlich etwas falsches eingibt das z.B. die 

Datenkonsistenz gefährden könnte - eine absichtliche Eingabe unerwarteter 

Werte war nicht die Motivation 10 . 

Die proprietäre Sprache ABAP von SAP ist unter Sicherheitsgesichtspunkten 

eine Unbekannte. Expertenmeinungen über die Sicherheit der Sprache 

selbst existieren nicht und auch generische Ansatzpunkte um 

Schwachstellen im Programmablauf aufzufinden oder auszunutzen sind 

nicht bekannt. Auch die Versuche im Rahmen dieser Diplomarbeit einen 

generischen Angriffspunkt wie z.B. eine Form des Command-Injection (Vgl. 

Kapitel 2.3.4) zu finden blieben ohne Ergebnis. Dass kein Ansatzpunkt 

bekannt ist und auch nicht gefunden werden konnte kann als Vorteil 

gesehen werden und zeigt auch, daß ABAP eine Resistenz aufweist. 

Dennoch kann dies nicht als endgültiges Ergebnis betrachtet werden, da die 

Suche im Rahmen dieser Diplomarbeit im Vergleich zu bekannten Sprachen 

wie z.B. Perl, in dessen Überprüfung viele Personen über längere Zeit 

arbeiten, kein vergleichbarer Aufwand gegenübergestellt werden kann. 

9 Enterprise Portal, SAP Security and Authorizations 

10 SAP Web Application Server; Frederic Heinemann, Christian Rau 



2.2.4 Übergreifende Aspekte 

Organisatorische Maßnahmen und Integration in 

Sicherheitsüberprüfungen 

Außer den menschlichen und technischen Faktoren gibt es auch Faktoren, 

die sich übergreifend auswirken. Die organisatorischen Bedingungen und 

Entscheidungen sind hier ein Tema. Für viele Bereiche in der IT haben auch 

organisatorische Maßnahmen Einzug gehalten um die Arbeit zu 

strukturieren, wie schon verschiedene Standards, z.B. ITIL 11 zeigen. 

Demgegenüber wird SAP nur selten z.B. in Evaluationen der 

konzeptionellen Sicherheit auf Netzwerkebene oder sonstigen 

ganzheitlichen Überprüfungen mit einbezogen 12 . Sicherheitsüberprüfungen 

der Webapplikationen, wie sie bei klassischen Webapplikationen bereits 

üblich sind, werden bislang nur in sehr wenigen Ausnahmefällen 

durchgeführt. Gleichzeitig gewinnen sie jedoch an Bedeutung und es ist 

eine steigende Nachfrage hierfür erkennbar. 

Spezielle Eigenschaften von SAP-Systemen wurden bei solchen 

Webapplikationsüberprüfungen kaum beachtet, da es hier ebenfalls im 

Gegensatz zu klassischen Webapplikationen keine Erkenntnisse oder 

Erfahrungen gibt. 

Wirtschaftliche Bedeutung 

Bei klassischen Webapplikationen ist der potentielle wirtschaftliche Schaden 

eines Sicherheitsvorfalls sehr individuell und kann von sehr geringem 

direkten Schaden bis zu im Ernstfall unternehmensgefährdentem Schaden. 

Bei SAP werden hingegen immer kritische Daten verarbeitet, so dass das 

Schadensrisiko im Durchschnitt wesentlich höher liegen sollte. Darüber 

hinaus sind auch immer indirekte Schäden wie z.B. Vertrauensverlust zu 

beachten, der sich nur schwer beziffern lässt. 

Es gab einige Versuche, den direkten Schaden zu beziffern, der durch 

Komprommittierung von IT Systemen durchschnittlich entsteht 13 . So liegen 

die ermittelten Schäden je nach Studie zwischen 167.000 Dollar und 4.8 

Millionen Dollar und weitere 1000 Dollar pro Stunde zur Wiederherstellung 

des Ursprungszustandes. Wie hier zu sehen ist, sind die Daten nicht 

stichhaltig und eine weitere Studie von Forrester Research zeigt, dass 25% 

derjenigen, die auf solche Fragen geantwortet haben, den Schaden gar 

11 http://www.itil.org/ 

12 http://www.securitymanager.de/magazin/artikel_988_sap-security_roadmap_zu_umsetzung.html 

13 http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1248216,00.html?track=NL- 

430&ad=581112USCA&asrc=EM_NLT_1164363&uid=4199563 



nicht kennen oder nicht wissen, wie man ihn beziffern könnte. Hierbei 

sagten 11% die einen Verlust von Daten bestätigt haben, dass keine 

weiteren Kosten entstanden, was nicht der Wahrheit entsprechen kann. 

Verlässliche Daten zum wirtschaftlichen Schaden gibt es also derzeit noch 

nicht, doch wie sich ein möglicher Schaden auswirken kann, lässt sich am 

Beispiel ChoicePoint aufzeigen, dessen Aktienwert auf 2 Jahre nach einem 

bekannt gewordenen Sicherheitsvorfall noch immer 20% unter dem Wert 

liegt, das das Unternehmen vor diesem Vorfall hatte. Gartner schätzt 

außerdem, dass die Kosten für einen Verlust von Daten bis 2009 um 20% 

pro Jahr steigen wird. 

Zusammenfassend lässt sich sagen, dass einzelne Aspekte kein 

realistisches Bild der Sicherheit bringen können, viel mehr muss letztlich 

eine Gesamtbetrachtung durchgeführt werden. Bei Betrachtung einzelner 

Aspekte entgehen komplexere Probleme, wie z.B. der Mitarbeiter, der 

mangels Schulungen nicht richtig mit der proprietären Sprache umgehen 

kann, oder ein gutes Sicherheitsmodell, das durch fehlerhaftes Setzen von 

Berechtiungen unterlaufen wird, oder ein fehlerhafter Prozess, in dessen 

Zuge unsichere Einstellungen von einem Testsystem in das 

Produktivsystem übernommen werden. 

2.2.5 Betrachtungsweisen der Sicherheit 

Klassische SAP-Sicherheit 

Wie in allen Bereichen der IT gibt es auch für SAP bereits einen Markt für 

Dienstleistungen im Sicherheitsbereich. Jedoch decken diese gänzlich 

andere Themen ab als sie in dieser Diplomarbeit behandelt werden. Es gibt 

auch einige Anbieter, die sich um das Thema sichere Kommunikation 

kümmern und in diesem Rahmen Lösungen für SSL, VPN und PKI anbieten. 

Der größte Teil der Anbieter für Sicherheit bei SAP bearbeitet jedoch das 

durchaus komplexe und wichtige Gebiet der Benutzer- oder 

Rollenverwaltung, Berechtigungen und Profile sowie eventuell Information- 

Ownership und Themen rund um Complianceandforderungen. 

Risiko – Kontroll - Analyse 

Eine Empfehlung 10 im Rahmen der SAP-Sicherheit beschreibt eine 

sogenannte Risiko – Kontroll – Analyse um die Sicherheitsprobleme der 

SAP-Technologie, Anwendungen, Organisation und gesetzliche 



Anforderungen zu identifizieren. Als Beispiel werden risikoreiche 

Transaktionen aufgefürt, die mit Hilfe der Risiko – Kontroll – Analyse 

identifiziert werden und geeignete Gegenmassnahmen vorgeschlagen 

werden können. 

Der Vorgang wird als zentrale Komponente einer Sicherheitsstrategie 

vorgestellt und wird in 4 Schritten beschrieben: 

Gefahrenanalyse: Herausarbeitung der Verwundbarkeiten und 

Gefahren eines IT Systems 

Auswirkungsanalyse: Herausarbeitung der Auswirkungen eines 

Angriffs, eines Ausfalls von IT Systemen oder menschliche Fehler 

Gefährdungsanalyse: Konkrete identifizierung der Gefährdungen und 

deren Gewichtung und Eintrittswahrscheinlichkeit 

Kontrollanalyse: Herausarbeitung der Gegenmassnahmen, allerdings 

ohne detaillierte Schritte zur Erreichung des Ziels. 

Angreifersicht 

Die Motivation und das Ziel von Angreifern kann sehr unterschiedlich sein 14 . 

Sie reicht von Neugier von technologischen Möglichkeiten, Vandalismus bis 

hin zu Wirtschaftskriminalität und Verfälschung von Informationen durch 

Geheimdienste. 

Es überwiegt hier die Betrachtungsweise der technischen Sicherheit bzw. 

die technischen Möglichkeiten zur Erreichung der oben genannten Ziele, wie 

sie auch in dieser Diplomarbeit verwendet wird. Auch social Engineering 

gehört mit in die Angreifersicht, ist aber trotz deren Effektivität nur selten 

erwähnt und wird auch bei dieser Diplomarbeit nicht weiter verfolgt. 

Verteidigersicht 

Die Verteidigersicht ist der Angreifersicht recht ähnlich. Sie beschreibt den 

umgekehrten Weg und beschäftigt sich mit den Sicherungsmaßnahmen 

gegen die Gefährdungen von IT-Systemen. Die Verteidigersicht wie sie in 

dieser Diplomarbeit verstanden wird beschäftigt sich vor allem mit der 

technischen Sicherheit wie sie in Sicherheitsabteilungen von Unternehmen 

gesehen wird und beschreibt keine weitergehenden Maßnahmen wie z.B. 

organisatorische Maßnahmen. 

14 Andy Müller-Maguhn – Vortrag “Die Illusion IT-Sicherheit: Strategien und Erfahrungen“ 



2.2.6 Einordnung dieser Diplomarbeit 

Diese Diplomarbeit beschäftigt sich in erster Linie mit der Angreifersicht 

und Verteidigersicht, wie sie in Kapitel 2.2.5 beschrieben wird. Die Kapitel 3 

und 4 entsprechen diesen beiden Sichten und untersuchen dieses Szenario 

jeweils unter einer praktischen Vorgehensweise und Verwendung 

technischer Möglichkeiten. 

Bei einer Gesamtbetrachtung der Sicherheit können diese technischen 

Sichten nur ein Teil der zu betrachtenden Situation und Möglichkeiten sein, 

stellen jedoch die größten und auch am häufigsten angewandten Aspekte 

dar. Daher wurden in den Unterkapiteln des Kapitels 2 zusätzlich weitere 

Sicherheitsaspekte mit aufgenommen die in den Kapiteln 3 und 4 

durchgefürhten Untersuchungen in einen Gesamtzusammenhang zu stellen 

wie es in Kapitel 5 zusammengefasst wird. 

2.3 Gefahren und Angriffe im Webumfeld 

2.3.1 Inhalte und Ziele des Kapitels 

Dieses Kapitel soll einen Überblick über das Thema 

Webapplikationssicherheit verschaffen. Was hier beschrieben wird ist 

sowohl für die klassischen Webapplikationen relevant als auch für die 

Webapplikationen auf Basis von SAP. Es wird zunächst an das Thema 

Webapplikationssicherheit herangeführt und beschrieben, wodurch sich 

dieses Thema von anderen Sicherheitsthemen und Angriffswegen 

unterscheidet. Danach werden die Ursachen beschrieben, die Angriffe 

überhaupt erst ermöglichen und auch bekannte Angriffstechniken bis hin zu 

konkreten Beispielen. 

Das Ziel dieses Kapitels ist jedoch nicht eine Anleitung zu geben, wie 

Webapplikationen gehackt werden können oder Hintergründe, Fehlerquellen 

und Angriffstechniken über eine allgemeine Bewertung hinaus zu 

beurteilen. Ziel dieses Kapitels ist es, das Thema Webapplikationssicherheit 

zu verstehen sowie die Ausführungsmölichkeiten zu kennen und 

einschätzen zu können. 

2.3.2 Port 80 Problem 

Ein oft verwendetes Schlagwort bei Behandlung des Themas 

Webapplikationssicherheit ist das Port 80 Problem. Typische Firewalls 



erkennen und verhindern eine Vielzahl von Angriffen im Wesentlichen 

dadurch, dass sie nur die gewollten Netzwerkports für kontrollierten 

Verkehr zulassen. Das Wesen von Webapplikationsangriffen ist allerdings, 

dass sie genau dieses Protokoll verwenden und somit für die Firewalls auch 

erlaubten und gewünschten Verkehr darstellen, der die Firewall dann auch 

passieren wird. 

Demgegenüber sind Webapplikationen inzwischen weit verbreitet und auch 

zu sehr komplexen Gebilden gewachsen, die Zugriffe auf eine Datenbank 

vermitteln, über eine Sitzungsverwaltung verfügen und viele weitere 

Techniken beinhalten, die gleichzeitig potentielle Gefahrenstellen sind. Die 

Werkzeuge um Angriffe auf Webapplikationen durchzuführen sind 

vorhanden und die Methoden, die dahinter stehen bekannt. Völlig 

fehlerfreies Programmieren und Konfigurieren hat sich als unmöglich 

herausgestellt, auch wenn es selbstverständlich auch sehr sichere, große 

Applikationen gibt. 

Abbildung 3: Port 80 Problem 

Wie in Abbildung 3: Port 80 Problem zu sehen laufen die Angriffe über die 

beabsichtigterweise offenen Ports der Firewall die somit kein Hindernis 

darstellen und die beteiligten Systeme ungeschützt in Internet stehen. 

Durch die Nutzung der offenen Ports können aber sehr wohl 

Applikationslogik, Prozesse, das Betriebssystem und eine dahinter liegende 

Datenbank Ziele eines Angriffs sein. 



2.3.3 Fehlerquellen in Webapplikationen 

Es gibt einige Grundsätze, die beim Programmieren von Webapplikationen 

beachtet werden sollten. Die meisten der hier erwähnten Punkte lassen sich 

auch auf andere Arten von Applikationen anwenden, sie treten jedoch bei 

Webapplikationen besonders deutlich in Erscheinung. Spezifische 

Programmierrichtlinien für Webapplikationen sind in Kapitel 4.3 und 4.4 

beschrieben, dieses Kapitel beschränkt sich auf allgemeine Grundsätze, die 

für das Verständnis von Webapplikationssicherheit wichtig sind und deren 

Unkenntnis oder Nichtbeachtung zu einem großen Teil der Probleme führen. 

Diese Punkte wurden hauptsächlich auf Basis der praktischen Arbeit des 

Verfassers erstellt. 

Fehlende Eingabevalidierung 

Ein Großteil der Webapplikationsangriffe basiert auf dem Fehlen oder einer 

nicht korrekt durchgeführten Eingabevalidierung. Bei einer 

Eingabevalidierung müssen grundsätzlich alle Daten die vom Client 

kommen geprüft werden, da sie gefälscht oder verändert sein können. 

Behandlung unterschiedlicher Codierungen 

Eine ungewöhnliche Codierung kann eine Rolle bei der 

Webapplikationssicherheit spielen und muss bei der Eingabevalidierung 

beachtet werden. Es gibt eine Vielzahl von Codierungsmöglichkeiten, die 

alle erkannt werden und in korrekter bzw. normalisierter Form an eine 

Prüfroutine übergeben werden müssen. Nur so kann eine Prüfung auch 

angewendet werden. 

Clientseitiger Code 

In einigen seltenen Fällen wird bei klassischen Webapplikationen eine 

Eingabevalidierung mittels Code auf dem Client durchgeführt. Da sich 

dieser jedoch wie alle Daten auf dem Client auch unter Kontrolle des Clients 

befindet, können Prüfungen in diesem Fall als wirkungslos angesehen 

werden. Grundsätzlich muss jeglicher Code auf dem Client als nicht 

vertrauenswürdig angesehen werden und auf dem Client niemals 

sicherheitsrelevante Routinen verwendet werden. 

Schwache Sitzungsverwaltung 

Da Webapplikationen wie andere Applikationen auch Sitzungsgebunden 

sind, HTTP aber keine Sitzungsverwaltung bietet, muss diese auf 



Applikationsebene implementiert werden. Es ist unabdingbar, dass eine 

Sitzungsverwaltung sorgfältig implementiert werden muss, so dass eine 

Sitzung beispielsweise nicht veränderbar oder vorhersagbar ist. 

Ausgabevalidierung 

Unter den Punkt Ausgabevalidierung fällt vor allem der Bereich der 

Fehlermeldungen. Im Gegensatz zu der Eingabevalidierung soll hier aber 

dafür gesorgt werden, dass keine Daten zum Client gelangen, die dort nicht 

benötigt werden. Gerade Fehlermeldungen verraten häufig Systeminternas, 

wie z.B. eingesetzte Produkte, deren Version oder Teile der Programmlogik, 

in manchen Fällen sogar Debugausgaben. All dies sind wertvolle 

Informationen für einen Angreifer, die er für weitere Schritte verwenden 

kann. Daher sollten Fehlermeldungen grundsätzlich nur über das Auftreten 

eines Fehlers informieren, aber keine Systemrelevanten Daten 

herausgeben. Darüber hinaus hilft eine sorgfältige Ausgabevalidierung auch 

die Durchführung von Angriffen zu verhindern. Ein Beispiel hierfür ist 

Cross-Site-Scripting, das zwar Häufig von der Eingabevalidierung 

abgefangen wird, aber grundsätzlich eher als Problem der Ausgabeseite 

angesehen werden muss, da bei Cross-Site-Scripting die Fähigkeit des 

Browsers ausgenutzt wird, Code auszuführen, der sich nicht an dieser Stelle 

in ausführbarer Form in der Antwort des Webservers befinden sollte. 

Kommentare/Testprogramme/Backups 

Kommentare, Testprogramme und Backups sind alles Informationsquellen 

für einen Angreifer, oder im schlimmsten Fall sogar einfache Zugänge zu 

einem System. Doch selbst als reine Informationsquellen können sie bei 

weiteren Schritten hilfreich sein. Besonders interessant und auch in der 

Realität zu finden sind dort Informationen über die Programmlogik oder 

auch kritische Informationen wie z.B. Connection-Strings zum Backend. 

Unzureichende Konfiguration der Komponenten 

Auch eine unzureichende Konfiguration der Komponenten ist ein zentraler 

Punkt, der häufig vernachlässigt wird. Es werden zusätzliche Angriffspunkte 

geschaffen, wenn z.B. die Defaultkonfiguration von Komponenten 

verwendet wird oder die Konfigurationseinstellungen aus einem 

Testsystem, das üblicherweise weniger gesichert wird als ein 

Produktivsystem. Hierbei spielt auch wieder die knappe Zeit eine Rolle, 

infolge dessen oft die sorgfältige Konfiguration sicherheitsrelevanter 



Einstellungen vernachlässigt wird. Ebenso ist eine mögliche mangelnde 

Fachkenntnis in diesem Bereich eine Ursache für eine unzureichende und 

damit unnötig unsichere Konfiguration. 

2.3.4 Beschreibung der Webapplikationsangriffe 

Im Folgenden werden einige der wichtigsten Angriffsklassen und Methoden 

kurz erläutert und in einigen Fällen mit exemplarischen Beispielen 

verdeutlicht. Die konkrete Ausgestaltung dieser Methoden kann von Fall zu 

Fall variieren, da Webapplikationen grundsätzlich Unikate sind und die 

Angriffe den Gegebenheiten angepasst werden müssen. Diese Liste ist nicht 

vollständig und soll nur einige der wesentlichen Methoden näher bringen. 

Cross-Site-Scripting 

Cross-Site-Scripting ist eine der bekanntesten Attacken, gleichzeitig ist es 

wohl die Methode, die trotz des sehr hohen Bekanntheitsgrades am 

wenigsten verstanden wurde. Entgegen der gängigen Annahme ist Cross- 

Site-Scripting kein Angriff auf die Applikation, den Server oder ähnliches 

und ist somit kein Angriff, der die Sicherheit des Servers direkt beeinflusst. 

Im Gegensatz zu den anderen Angriffsmethoden kennt Cross-Site-Scripting 

3 Beteiligte. 

Angreifer 

Server 

Opfer 

Der Server ist also, wie zu sehen, nicht das Opfer, sondern ein Vermittler 

des Angriffes. Der Ablauf eines Cross-Site-Scripting Angriffs beginnt immer 

gleich. Das Opfer, ein Benutzer der verwundbaren Applikation, muss 

zunächst dazu gebracht werden einen präparierten Link zu benutzen. Dies 

muss in den meisten Fällen, aber nicht notwendigerweise, aktiv geschehen. 

Das heißt, das Opfer klickt beispielsweise auf den präparierten Link der sich 

in einer Email befindet. Der Link verweist dann auf eine Applikation, die für 

Cross-Site-Scripting verwundbar ist. Bei dieser Applikation darf und soll es 

sich sogar um eine für das Opfer vertrauenswürdigen Applikation handeln, 

da sich der Schadcode innerhalb des Links, in seltenen Fällen dann auf der 

Seite selbst, auf eine vermeintlich vertrauenswürdigen Seite befindet. Bei 

der für das Opfer vertrauenswürdigen Applikation kann es dann 

beispielsweise einen für Cross-Site-Scripting verwundbaren Parameter 



geben, der dann mit Werten wie document.location 

.replace('http://hackers.server/stealcookie.cgi?'+document.cook 

ie); aufgerufen wird. Wie in diesem Beispiel ersichtlich erhält 

der Angreifer die Cookies des Opfers, unter denen sich auch eines befinden 

kann, das eine gültige Sitzung auf der verwundbaren Applikation darstellt. 

Der Angreifer könnte nun also, obwohl er selbst keine oder andere 

Berechtigungen in der Applikation hat, in der Identität des Opfers arbeiten. 

Der Angriff, in diesem Fall der Wert des Parameters, muss jedoch nicht 

immer so eindeutig sein. Es gibt eine Vielzahl an Variationen um z.B. eine 

Ein- bzw. Ausgabeprüfung zu umgehen. Das folgende Beispiel würde bei 

einer Verwundbaren Applikation eine Alertbox mit XSS als Text erzeugen 15 : 

'';!--"=&{()} 

 

 

Wie zuvor schon angedeutet, unterscheidet man bei Cross-Site-Scripting 

zwischen 2 Arten: 

nicht persistent 

persistent 

Nicht persistentes Cross-Site-Scripting verhält sich wie in dem Beispiel 

zuvor beschrieben. Es ist grundsätzlich nur für eine Sitzung gültig und das 

Opfer muss den initial gesendeten bzw. verwendeten Link aktivieren. 

Bei einem persistenten Cross-Site-Scripting wird der Link in einem System 

gespeichert, so dass dieser den Opfern nicht gesordert gesendet werden 

muss. Dadurch trifft der Angriff jeden, der die Daten und damit das Skript 

abruft. Denkbar ist dies z.B. in einem Forum, dessen 

Mitgliederbeschreibung für Cross-Site-Scripting anfällig ist und somit jeder, 

der die Mitgliederbeschreibung abruft, von der Attacke betroffen ist, ohne 

dass von den Opfern eine weitere Aktion notwendig ist 16 . 

Eine anschauliche Demonstration, was mit Cross-Site-Scripting möglich ist, 

findet sich auf www.bindshell.net/beef/. 

15 http://ha.ckers.org/xss.html 

16 http://www.heise.de/newsticker/meldung/100976 



Cross-Site-Scripting findet üblicherweise über JavaScript statt, 

grundsätzlich ist aber jeder vom Browser ausgefürhrte Code geeignet. 

SQL-Injection 

SQL-Injection gehört zu einer der potentiell gefährlichsten Attacken, da 

hierdurch unternehmenskritische oder sonstige wichtigen Daten offen 

liegen können, wie z.B. Kreditkartennummern von Kunden. Weniger 

bekannt aber ähnlich gefährlich ist, dass viele 

Datenbankmanagementsysteme Schnittstellen für 

Betriebssystemkommandos bereitstellen, wie xp_cmdshell des MS SQL 

Servers, der in der Vergangenheit standardmäßig mit administrativen 

Rechten auf dem Betriebssystem lief. 

Ursache für SQL-Injection ist häufig, dass Benutzereingaben Teil eines SQL- 

Befehls an das Backend sind. Die Webapplikation wirkt hierbei also als 

Interface für SQL-Befehle. Das Gefährliche ist, dass hier die Möglichkeiten 

der Eingabe über das vom Programmierer Erwartete hinausgehen. Erwartet 

wird für gewöhnlich eine Benutzereingabe, die im späteren SQL-Befehl 

einen Parameterwert oder einen Teil dessen darstellt, z.B. ein 

Benutzername. Es ist aber möglich, die erwartete Eingabe zu verändern 

oder zu erweitern, so dass anstatt des Parameterwertes, der eigentlich 

erwartet wurde, ein Teil eines SQL-Befehls entsteht, der den ursprünglichen 

SQL-Befehl verändert, oder aber auch ein neuer SQL-Befehl bzw. eine 

Verkettung von SQL-Befehlen. 

Ein oft beschrittener Weg bei einer gefundenen SQL-Injection 

Schwachstelle ist es, zunächst die Systemtabellen auszulesen. Da ein 

relationales Datenbanksystem alle Informationen auch über sich selbst 

auch in seinen Tabellen speichern muss, können hier alle gewünschten 

Informationen über die Datenbank ausgelesen werden, die Möglichkeit der 

Eingabe der entsprechenden Befehle und die notwendigen Rechte 

vorausgesetzt. Danach können die gewünschten Informationen wie z.B. 

Kreditkartennummern gezielt abgefragt werden oder andere gewünschte 

Aktionen wie das gezielte Verändern von Datenbankeinträgen durchgefürt 

werden. 

Auch bei SQL-Injection gibt es eine weitere Variante, die Blind-SQL- 

Injection. Während man bei einer gewöhnlichen SQL-Injection den Aufbau 

des vom System verwendeten SQL-Befehls anhand von Fehlermeldungen 

erkennen kann, ist dies bei Blind-SQL-Injection nicht möglich. Ein Angreifer 

muss sich daher den korrekten Aufbau des SQL-Befehls anhand von 



Veränderungen der Antworten der Applikation, z.B. allgemein gehaltene 

Fehlerseiten, erarbeiten um die Lücke auch tatsächlich ausnutzen zu 

können und um die Befehle einzuschleußen. 

Weitgehend unbekannt ist die Tatsache, dass SQL-Injection nicht nur über 

die Manipulation von Benutzereingaben für Parameter möglich ist. Es sind 

grundsätzlich alle Daten betroffen, die für einen SQL-Befehl verwendet 

werden, auch z.B. HTTP Header. 

Verhindern lässt sich SQL-Injection hingegen sehr einfach durch die 

Verwendung von prepared Statements. 

Command-Injection 

Die Ursache für Command-Injection ist der für SQL-Injection recht ähnlich. 

Hier ist die Benutzereingabe aber nicht Teil eines SQL-Befehls, sondern 

eines Kommandos, z.B. ein Kommando des darunter liegenden 

Betriebssystems. Wie bei SQL-Injection geschieht dies durch Verändern 

oder Erweitern der erwarteten Benutzereingabe. Ist z.B. die Eingabe einer 

Pipe ( | ) bei einer Perl-basierter Applikation erlaubt, kann dies dazu 

führen, dass die beabsichtigte Eingabe so verändert wird, dass ein 

Angreifer die Eingabe um eigene Befehle erweitern kann 17 : 

Beabsichtigt: ..../show.pl?format=default 

Angriff: .../show.pl?format=/bin/ls| 

Bei php ist folgende Variante denkbar: 

Beabsichtigt: …/diskusage.php?directory=~/ 

Angriff: …/diskusage.php?directory=;cat etc/passwd 

Hierdurch wird ein Angreifer in die Lage versetzt, alle Befehle auf z.B. 

Betriebssystemebene auszuführen, die auch die Applikation aufrufen kann, 

inklusive derer Berechtigung auf dem Betriebssystem. 

File Execution/Include 

Ursächlich für File-Execution bzw. File-Include ist die Möglichkeit eines 

Benutzers, Dateinamen anzugeben oder Dateien hochzuladen, die danach 

aufgerufen werden können. Dies führt zur Ausführung von 

benutzerdefinierten Dateien, dies es unter Umständen erlauben, die 

Fähigkeiten des Applikation im Sinne des Angreifers zu erweitern. Es sind 

auch hier verschiedene Varianten möglich 

17 http://www.webappsec.org/projects/threat/classes/os_commanding.shtml 



Einbinden von Includes auf dem Server 

Einbinden von Includes von anderen Orten 

Hochladen von Dateien gefolgt von deren Ausführung 

Logikfehler 

Ein wichtiger Punkt bei der Überprüfung von Webapplikationen ist die 

Prüfung auf Fehler in der Anwendungslogik. Dieser Schritt erfordert viel 

Zeit und ist auch nahezu unmöglich zu automatisieren. Ursachen und Ziele 

von Logikfehlern bzw. deren Ausnutzung sind äußerst vielfältig, ebenso der 

potentielle Schaden. Es ist häufig verbunden mit den zuvor genannten 

Angriffen und geht üblicherweise über verschiedene 

Parametermanipulationen. 

Daten von 2006: 

Ergänzend ist in Abbildung 4: Verteilung der Angriffshäufigkeit eine 

Statistic über die Häufigkeit von verschiedenen Webapplikationsangriffen 

dargestellt 18 . Diese Diplomarbeit folgt nicht der in dieser Grafik 

vorgenommenen Unterteilung, da z.B. Path-Traversal zumeist auf falsche 

Konfiguration zurückzuführen ist, jedoch ist hier der überragende Anteil an 

Cross-Site-Scripting erkennbar, gefolgt von SQL-Injection. 

Abbildung 4: Verteilung der Angriffshäufigkeit 

18 http://www.webappsec.org/projects/statistics/ 



2.4 Zusammenfassung 

In diesem Kapitel wurden Parallelen und Unterschiede im Aufbau von 

klassischen Webapplikationen und SAP als Beispiel für ein ERP-System 

dargestellt und hierbei insbesondere den für diese Diplomarbeit wichtigen 

Aufbau des SAP NetWeavers näher erklärt und somit die dieser 

Diplomarbeit behandelten Zielsysteme und Architekturen definiert. 

Nachfolgend wurde wurde das Thema Sicherheit diskutiert und die 

Unterschiede zwischen klassischen Webapplikationen und SAP-Systemen 

anhand relevanter Aspekte herausgearbeitet um die in dieser Diplomarbeit 

näher behandelten Sicherheitsaspekte aus der Sicht von Angreifer und 

Verteidiger in einen größeren Zusammenhang einzuordnen, wie dies vor 

Allem in Kapitel 5 geschieht. 

Abgeschlossen wurde dieses Kapitel mit der Beschreibung der für diese 

Diplomarbeit relevanten Teilbereiche der technischen Sicherheit, die 

Angriffe, wie sie in dieser Diplomarbeit durchgeführt werden, erlauben und 

einer Beschreibung der verwendeten Angriffstechniken selbst. 



3 Vergleich klassischer Webapplikationen 

mit SAP aus Angreifersicht 

Im folgenden Kapitel wird die Sicherheit von Webapplikationen auf Basis 

von SAP aus Angreifersicht evaluiert. Nach einer kurzen Einführung zu 

Webapplikationsscannern wird hierzu wird zunächst eine beispielhafte 

Überprüfung der klassischen Webapplikation cirobank durchgeführt, die als 

Referenz zu der darauf folgenden Überprüfung der SAP-Systeme dient. Bei 

SAP wird das Basis-System sowohl des ABAP- als auch des JAVA-Stacks 

überprüft. Zusätzlich werden noch die Ergebnisse eines Audits einer realen 

Webapplikation auf Basis von SAP mit JAVA-Stack in kurzer Form 

aufgezeigt. Die Ergebnisse aus den Überprüfungen der klassischen 

Webapplikation und der Webapplikationen auf Basis von SAP werden 

anschließend einem Vergleich unterzogen und die gefundenen Ergebnisse 

bewertet. 

3.1 Webapplikationsscanner 

Webapplikationsscanner sind Sicherheitswerkzeuge, die dafür entwickelt 

werden, Webapplikationen auf ihre Sicherheit hin zu untersuchen. Sie 

evaluieren dabei jede Möglichkeit zur Eingabe die die zu untersuchende 

Webapplikation bietet. Sind diese gefunden, wird auf jede eine Vielzahl von 

Anfragen gesendet, die bekannte Angriffe enthalten und die Antwort der 

Webapplikation dahingehend untersucht, ob der zuvor durchgeführte 

Angriff erfolgreich war. Der große Vorteil eines Webapplikationsscanners 

ist, dass so eine Unmenge an Angriffsmöglichkeiten durchprobieren werden 

kann. Diese sind manuell nicht zu bewältigen und bieten einen guten ersten 

Eindruck der zu überprüfenden Webapplikation sowie Ansatzpunkte für eine 

weitergehende, manuelle Überprüfung. 

Die meisten klassischen Webapplikationen können von einem Scanner gut 

auditiert werden und dessen Ergebnisse mit einiger Erfahrung so 

angewandt werden, dass die darauf folgende, manuelle Überprüfung 

zielgerichteter verlaufen kann. Ein Webapplikationsscanner kann allerdings 

nicht die ganze Arbeit übernehmen und eignet sich nur für die zuvor 

beschriebenen Zwecke. Das Verhältnis des Zeitaufwandes zwischen einer 

automatischen Überprüfung und manueller Überprüfung ist etwa 1/3 zu 

2/3. 



3.2 Angriffe auf Webapplikationen 

3.2.1 Typische Angriffe 

Da ein Scanner inzwischen hoch entwickelt ist und auf Webapplikationen 

verschiedenster Art reagieren können soll, konnte das automatisierte Audit 

der Webapplikation cirobank mit Defaulteinstellungen durchgeführt werden. 

Eine Optimierung hinsichtlich der durchgeführten Tests wäre möglich um 

Zeitvorteile und akkuratere Scaneinstellungen zu erhalten, ist aber in 

diesem Fall vom Verfasser als nicht notwendig erachtet worden, da der 

Gewinn durch eine Optimierung den Aufwand nicht rechtfertigt. 

Ein eher überaschendes Ergebnis des automatisierten Audits war die hohe 

Zahl der false-Positives. Dass die Ergebnisse eines solchen Scans zur 

Mehrheit aus false-Positives besteht, ist nicht ungewöhnlich, jedoch 

übersteigt hier das Verhältnis zwischen false-Positives und echten 

Ergebnissen den üblichen Rahmen mit hier ca. 0.2% realen Ergebnissen bei 

Weitem. Die Ursache für diesen ungewöhnlich hohen Anteil liegt in einer 

seltenen Eigenart der Webapplikation cirobank, auf bestimmte Anfragen mit 

einem HTTP Status 200 zu antworten, obwohl die angeforderte Ressource 

in Wahrheit nicht auf dem Server vorhanden ist. Obwohl diese Zahl 

zunächst einen erhöhten Aufwand bei der Auswertung der Ergebnisse 

vermuten lässt, war die Auswertung letztendlich kaum hierdurch 

beeinträchtigt. Zum einen lassen sich nach einiger Erfahrung mit dem 

Umgang und Auswertung der Ergebnisse von automatisierten 

Webapplikationsaudits viele false-Positives schnell erkennen, zum anderen 

hat die Ursache, dass in diesem Fall die vielen false-Positives zu Stande 

kamen einen Ausschluss eben dieser false-Positives sehr erleichtert, da sie 

in den überwiegenden Fällen in Gruppen und in derselben Anzahl auftraten. 

Der Ablauf des automatisierten Audits entsprach den Erwartungen. Der 

Scanner konnte die Webapplikation crawlen, das heißt, den enthaltenen 

Links folgen, und die gefundenen Seiten den eingestellten Sicherheitstests 

unterziehen. Eine Besonderheit des WebInspect 19 ist es, dass der Scanner 

die gefunden Seiten sofort auditiert und das crawlen parallel weiter läuft, 

daher sind die ersten Ergebnisse sehr schnell sichtbar, wie in Abbildung 5: 

Scan klassischer Webapplikation, bei der eine Übersicht der laufenden 

Auditierung sichtbar sit. 

19 https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-201- 

200^9570_4000_100__ 



Abbildung 5: Scan klassischer Webapplikation 

Auf diesem ersten Screenshot ist das Ergebnis des Scans nach 1 Minute 

und 33 Sekunden zu sehen. Auf der linken Seite sind die bereits gefunden 

Seiten der Webapplikation, die sukzessive aktualisiert werden, sobald neue 

Seiten gefunden werden. Daher ist auch die am rechten oberen Rand zu 

sehende Information „Crawl 66 of 66“ nur vorläufig und wird sich mit dem 

weiteren Fortgang des Audits noch erhöhen. Das Hauptfenster zeigt 

kontextsenitive Informationen an, hier eine Zusammenfassung des 

ablaufenden Scans. Möglich sind auch andere Informationen wie die HTTP 

Anfrage, Antwort etc. Im unteren Bereich werden die gefundenen 

Sicherheitsprobleme nach Klassen gruppiert und die Kritikalität angezeigt. 

Im Folgenden sind die Ergebnisse des Scans zusammengefasst, angefangen 

von den bereits auf dem oben gezeigten Bild zu sehenden Ergebnissen. 

Directory-Listing: Es wurden verschiedene Directory-Listings 

gefunden. Über Directory-Listing lassen sich häufig Informationen 

gewinnen, darunter Dateien, die dem Benutzer unbekannt sein 

sollten wie Backupdateien, oder auch Informationen über den 

Aufbau der Applikation. 

Die hier gefundenen Directory-Listings beziehen sich allerdings 

ausnahmslos auf ungefährliche Verzeichnisse wie das 

Standardverzeichnis /icons des Apache. Ein Directory-Listing auf 

Verzeichnisse mit relevanten Inhalten ist in diesem Fall nicht 

möglich. 



Cross-Site-Tracing: Cross-Site-Tracing ist eine weniger bekannte 

Variante des Cross-Site-Scripting und wird dazu benutzt, Cookies 

von Opfern zu stehlen. Bei Cross-Site-Tracing wird eine HTTP TRACE 

Anfrage des Clients auf einen Server angestoßen, von dem der 

Angreifer die Cookies des Opfers erhalten möchte. Aufgrund der 

HTTP Methode TRACE wird von diesem Server das Cookie des 

Clients wieder zurück gegeben und danach zum Angreifer gesendet. 

Dies ist in erster Linie ein Konfigurationsproblem und kann 

vermieden werden, indem die Methode HTTP TRACE auf dem 

Webserver verboten wird, wie es generell empfohlen wird, sofern 

diese Methode nicht explizit benötigt wird. 

Robots.txt: Die robots.txt wird verwendet, um Suchmaschinen 

mitzuteilen, welche Seiten einer Internetpräsenz oder 

Webapplikation von den Suchmaschinen-Robots durchsucht werden 

sollen bzw. welche für die Suchmaschine und damit auch normalen 

unbekannten Benutzern verboten ist. Da die robots.txt immer 

aufrufbar sein muss um sie den Suchmaschinen bekannt zu machen, 

ist sie natürlich auch von Angreifern einsehbar. Im Falle von Regeln, 

die das Besuchen von Teilen der Internetpräsenz oder 

Webapplikation verbieten, kann dies dazu führen, dass ansonsten 

unentdeckte Verzeichnisse bekannt werden wie hier in Abbildung 6: 

Robots.txt. In dieser Applikation ist das Verzeichnis /admin/ als für 

Suchmaschinen verboten gekennzeichnet, offenbart aber dadurch 

dessen Existenz. 

Abbildung 6: Robots.txt 

Miscellaneous Uncategorized Directories: Die auf dem ersten 

Screenshot sichtbare ‘Miscellaneous Uncategorized Directories’ sind 

das erste Beispiel der vom Scanner produzierten false Positives. Es 

ist bei näherer Betrachtung allerdings schnell zu erkennen, dass die 



Ursache in diesem Fall - und mit Verlauf des Scans weiteren Fällen 

– die für den Scanner problematische Eigenart der Webapplikation 

ist, in einigen Bereichen mit HTTP Status 200 auf ungültige Anfragen 

zu antworten, so dass der Scanner annehmen muss, die Anfrage 

war erfolgreich und die Ressource vorhanden. 

Bereits die nach etwa eineinhalb Minuten gefundenen Ergebnisse sind recht 

typisch für die Funktion des automatisierten Scans. Auch zu diesem frühen 

Zeitpunkt fanden sich Ergebnisse, die richtig erkannt wurden, Ergebnisse, 

die sich bei näherer Betrachtung als richtig aber unkritisch herausstellten 

und Ergebnisse, die false-Positives darstellen. 

Nachfolgend sind die weiteren, relevanten Ergebnisse aufgeführt, die das 

automatische Audit gefunden hat. 

Cross-Site-Scripting: Wie in beinahe allen Webapplikationen die 

überprüft werden, findet sich auch in cirobank eine Cross-Site- 

Scripting Schwachstelle. Dieser Screenshot zeigt die HTTP Antwort 

des Webservers auf die sehr einfach gehaltene Attacke. Man kann in 

Abbildung 7: Cross-Site-Scripting bei cirobank erkennen, dass die 

Scripttags nicht kodiert werden und daher vom Browser interpretiert 

und Code ausgeführt wird.. Wie in kapitel 2.3.4 beschrieben ist dies 

ein Standardtest der zeigt, ob ein Angriff mittels Cross-Site- 

Scripting möglich ist. 

Abbildung 7: Cross-Site-Scripting bei cirobank 



Logindaten werden unverschlüsselt übertragen: Durch die 

Verwendung von HTTP als Protokoll und nicht etwa mit SSL 

verschlüsseltes HTTP werden die Logindaten nicht verschlüsselt 

übertragen. Solche Daten sollten grundsätzlich besser über HTTPS 

gesendet werden. 

Remote-File-Inclusion: Bei einer Remote-File-Inclusion kann ein 

Angreifer, wie in Kapitel 2.3.4 beschrieben, einen Code auf der 

Webseite zur Ausführung bringen. So kann beispielsweise eine 

sogenannte Web-bzw. Php-Shell genutzt werden, die weitgehende 

Möglichkeiten auf dem Zielserver erlaubt. 

Local-File-Inclusion: Die gefundene Local-File-Inclusion basiert bei 

der cirobank auf demselben verwundbaren Parameter wie die 

Remote-File-Inclusion. Der Unterschied bei der Local-File-Inclusion 

ist, dass hier Dateien eingebunden werden, die sich lokal auf dem 

Webserver befinden. Dass dies nicht PHP-Dateien sein müssen, zeigt 

schon dieses Beispiel. Hier ist es verbunden mit den weitgehenden 

Leserechten des Webservers möglich, sich Dateien auf dem Server, 

die nicht öffentlich verfügbar sein sollten, anzeigen zu lassen. Auf 

dem Screenshot: Abbildung 8: Local-file-inclusion ist die Einbindung 

der Unix-passwd Datei zu sehen. 

Sehr bemerkenswert ist hier die Fähigkeit des Scanners, Angriffe zu 

kombinieren. So ist es bei cirobank nicht auf direkte Art möglich, die 

erwähnte /etc/passwd anzuzeigen, da ein Anzeigen von nicht html-, phpoder 

Bilddateien verboten wurde. Jedoch ist es möglich, die Applikation zu 

täuschen indem ein NULL-Byte (%00) and den Dateinamen angehängt wird, 

gefolgt von einem .html. Somit ist die angeforderte Ressource für die 

Webapplikation eine HTML-Datei, also erlaubt zum anzeigen, die tatsächlich 

gelesene Datei ist aber nicht /etc/passwd.html sonder die existierende 

/etc/passwd (siehe Abbildung 8: Local-file-inclusion). 

Diese Anfrage alleine ist schon komplex und kombiniert verschiedene 

Schwachstellen, die in Webapplikationen auftreten können und zusammen, 

so wie hier, zu einem realen Angriff werden. Dies zeigt, wie weit entwickelt 

die automatisierten Scanner in Bezug auf das Auditieren von 

Webapplikationen bereits sind. 



Abbildung 8: Local-file-inclusion 

Die weiteren Ergebnisse des automatisierten Audits waren bis auf zwei 

Ausnahmen, die der Scanner korrekt erkannt hat, sehr schnell als False 

Positives erkennbar. 

Standardverzeichnisse: Der Scanner überprüft viele Verzeichnisse, 

die sich häufig Webapplikationen finden, darunter auch admin/. 

Dieses Ergebnis ist zusammen mit der gefundenen robots.txt in 

diesem Fall redundant. 

PHP Fehlermeldungen: Das automatisierte Audit erzeugte viele PHP 

Fehlermeldungen die zeigen, welche Zeichen bei einer Eingabe 

erlaubt sind und die auch Teile der internen Verzeichnisstruktur 

offenbarten. 

Insgesamt hat sich gezeigt, dass das automatisierte Audit sehr gut 

funktioniert hat. 

Manuell 

Auch die manuelle Überprüfung zeigte einige der von dem automatisierten 

Audit gefundenen Schwachstellen. Diese Schwachstellen soll die manuelle 

Überprüfung nochmals verifizieren und vor Allem auch erweitern und als 

Basis für weitere Schritte benützen. 




Die offensichtlichste Schwachstelle ist die auch vom Scanner gefundene 

Anfälligkeit für Cross-Site-Scripting. Auf der Weboberfläche zeigt sich diese 

bei Eingabe eines Benutzernamens, der das Skript enthalten kann. Das 

Skript kommt dann zur Ausführung, wenn nach der Eingabe der Link 

„Kennwort zurücksetzen“ aktiviert wird. Dass das Cross-Site-Scripting hier 

funktioniert hat schon das automatische Audit gezeigt, hier wird zur 

Verdeutlichung kein Skript, sonder ein einfacher html-Verweis verwendet. 

Dies ist kein Cross-Site-Scripting im engeren Sinne mehr, verdeutlicht aber 

die Funktionsweise dieses Fehlers und ist auch für sich genommen ein 

weiteres Problem, das vom Scanner so nicht überprüft wurde. 

Der Parameter user, der sich hinter dem Feld Benutzername’befindet, wird 

hier mit ">


mögliche Local-File-Inclusion. 

Das in der robots.txt erwähnte Verzeichnis admin/ ist durch ein Passwort 

geschützt. In Zusammenhang mit der File Inclusion Schwachstelle lässt sich 

der dazugehörige Benutzername und Passwort auslesen. Hierzu wird nicht, 

wie bei dem automatisierten Audit gesehen, die /etc/passwd mit dem 

Zusatz %00.html eingebunden, sondern wie in Abbildung 10: Manuelle 

Local-File-Inclusion zu sehen die im admin-Verzeichnis liegende .htpasswd, 

die Benutzernamen und Passwort enthält. Dieses ist zunächst natürlich 

verschlüsselt, würde sich aber im konkreten Fall mittels eines Programms, 

das Passworthashes testet, schnell gefunden werden. 

Abbildung 10: Manuelle Local-File-Inclusion 

Parameter-Tampering 

Kontinuierliches Prüfen von Parametern in einer Webapplikation ist eine 

Hauptaufgabe bei deren Überprüfung. Nicht immer findet ein 

automatisiertes Audit auch nur Ansatzpunkte für die gezielte Veränderung 

von Parametern. Hier ist es oft die Erfahrung, die entscheidet, welche 

Parameter einer gründlicheren Überprüfung unterzogen werden sollen und 

die am vielversprechendsten scheinen. Im Konkreten Fall handelt es sich 

um einen Parameter, der zunächst kryptisch aussieht, sich jedoch mit 

hoher Wahrscheinlichkeit als Base64 Codiert identifizieren lässt. Nach 

Dekodierung des dem in der Webapplikation verwendeten Parameters 

‚dXNlcl9pZD0xNQ==’ ergibt sich ‚user_id=15’. Durch gezieltes Verändern 

dieser ID auf ‚user_id=1’, Base64 kodiert ‚dXNlcl9pZD0x’, wird im Menu 

der Webapplikation das Feld ‚Kunden’ mit ‚Admin’ ersetzt und erlaubt den 

Zugang zum Administrationsbereich. 



SQL-Injection 

Das automatisierte Audit ergab 107 mögliche SQL-Injection 

Schwachstellen. Typischerweise werden bei einem automatisierten Audit 

mehr Hinweise auf SQL-injection gefunden, als tatsächlich vorhanden sind 

und in diesem Fall konnten alle diese Treffer schnell als False-Positives 

erkannt werden. Dennoch verbirgt sich eine, für den Scanner unsichtbare, 

SQL-Injection Schwachstelle in der Applikation, die sich bei einer manuellen 

Prüfung entdecken lässt. Bei der Webapplikation cirobank befindet sich im 

Administrationsbereich ein Feld für die Suche nach Benutzern, das sich 

schnell als für SQL-Injection verwundbar erweist. Eine Eingabe von ' 

UNION ALL SELECT dbid, name, null, null FROM 

master..sysdatabases;-- anstatt eines echten Benutzernamens führt zu 

einer erweiterten Ausgabe, bei der die Datenbanken auf dem 

Datenbankmanagementsystem angezeigt werden. Wie in Kapitel 2.3.4 

beschrieben lässt sich so nach und nach ein gezielter Angriff bzw. gezieltes 

Auslesen von Information mittels SQL-Injection durchführen. Die in diesem 

Statement verwendeten ‚null’ sind zum Auffüllen der angezeigten Spalten 

notwendig und ein Beispiel, wie der korrekte Aufbau eines SQL-Injection 

Kommandos nach und nach herausgefunden werden kann. 

In Abbildung 11: SQL-Injection wurde genau dieses Kommando 

eingegeben. Unterhalb der Benutzernamen sind die Datenbanknamen zu 

sehen, auf die ein Zugriff über die Webapplikation ursprünglich nicht 

möglich sein sollte. 



Abbildung 11: SQL-Injection 

3.3 Angriffe auf SAP 

3.3.1 Abgrenzung der Methodik zur 

Sicherheitsüberprüfung 

Das Vorgehen zur Überprüfung von Webapplikationen sollten sich nicht 

wesentlich unterscheiden, ungeachtet dessen, ob es sich um klassische 

Webapplikationen handelt oder um spezielle Webapplikationen auf Basis 

von SAP. 

Vor Anfertigung dieser Diplomarbeit gab es allerdings keinerlei Kentnisse 

über Attacken, Anfälligkeit für Attacken oder Besonderheiten bei der 

Überprüfung von Webapplikationen auf Basis von SAP. Zu allen diesen 

Punkten wurde im Rahmen dieser Diplomarbeit viel Forschungsarbeit 

geleistet um die Grundlage für eine geregelte Überprüfung von 

Webapplikatoinen auf Basis von SAP zu schaffen. 



Hierbei hat sich gezeigt, dass bei der Überprüfung der Webapplikationen 

eines SAP-Systems zusätzliche Vorbereitungen getroffen werden müssen 

um eine Überprüfung vernünftig und vollständig durchführen zu können. 

Die Komplexität von SAP-Systemen ist hier einer der Hauptgründe, weshalb 

die Sicherheit von SAP-basierten Webapplikationen kaum oder gar nicht 

behandelt wurde. Diese Komplexität setzt sich auch bei den 

Webapplikationen fort und erfordert weitere Schritte um eine Überprüfung 

durchzuführen. Eine der ersten Fragen ist, welche Dienste bzw. 

Webapplikationen auf dem SAP-System aufrufbar sind. Schon dies ist in 

den meisten Fällen unbekannt und eine einfache Möglichkeit die tatsächlich 

vorhandenen Dienste zu erkennen fehlt. 

Daher ist der erste Schritt bei der Überprüfung der Webapplikationen eines 

SAP-Systems festzustellen, welche Dienste bzw. Webapplikationen 

angeboten werden. Hierfür wurde zunächst ein Perl-Skript gefertigt, später 

dann auf ein Plugin für den auch schon bei den klassischen 

Webapplikationen verwendeten WebInspect geschrieben, der diese Arbeit 

übernimmt. Dies kann nur automatisiert durchgefürhrt werden, da die 

mögliche Zahl an Diensten schon bei einer Basisinstallation ohne weitere 

Komponenten sehr hoch ist. Die einzelnen von einem SAP-System 

angebotenen Webapplikationen zeichnen sich durch eine eindeutige Starturl 

aus. In den in dieser Diplomarbeit verwendeten SAP-Systemen der Version 

7.00 konnten insgesamt über 2000 URLs identifiziert werden (Tabelle 1: 

Anzahl der SAP URLs). 

Tabelle 1: Anzahl der SAP URLs 

Komponente 

URLs 

ABAP-Stack: 569 

JAVA-STACK: Shortcuts zu anderen Applikationen 130 

JAVA-STACK: Webdynpro-Applikationen 390 

JAVA-STACK: Portal-Applikationen 1008 

JAVA-STACK: gesamt: 1528 

SAP gesamt 2097 

Dienste ohne Shortcuts 1976 

Auf Nachfrage bei Verantwortlichen ist die genaue Kenntnis darüber, 

welche Dienste angeboten werden nur selten vorhanden, schon daher ist 



ein solcher Scan zum Auffinden von den entsprechenden URLs sinnvoll. 

Außerdem lässt sich hierdurch auch definitiv feststellen, welche Dienste 

auch wirklich aufrufbar sind, unabhängig von einer unter Umständen nur 

schwer zu durchschauenden Konfiguration verschiedener Komponenten. 

Der Grund für die Erstellung des Skriptes bzw. des Plugins für das Prüfen 

der URLs ist, dass diese nicht durch automatisches Crawlen gefunden 

werden können. Es ist unter Umständen nicht einmal ein aufrufbares 

Rootverzeichnis vorhanden, weswegen ein automatisierter Scan gar nicht 

funktionieren und schon bei der ersten Seite stoppen würde. Ein manuelles 

Audit wäre aufgrund der Vielzahl an möglichen URLs wie oben erwähnt 

ebenfalls nicht möglich. Ebenso existieren kaum Links zwischen den 

Applikationen, so dass auch nach Kenntnis von einigen Applikationen 

andere noch immer verborgen bleiben. 

Zusammenfassend haben also folgende Punkte zur Erstellung des Skriptes 

und Plugins zur Überprüfung von SAP Systemen geführt: 

Mögliche URLs müssen im Vorfeld bekannt sein 

Mögliche URLs können nicht von Hand überprüft werden 

Automatische Crawlen der URLs ist im Vorfeld notwendig 

Die Basis-URLs, die die Dienste beschreiben, müssen im Vorfeld ein 

solches Programm eingetragen werden 

Soll nur ein einzelnes System überprüft werden, bestünde auch die 

Möglichkeit, dass ein Administrator die theoretisch aufrufbaren URLs 

anhand der Konfiguration ermitteln kann. Tatsächlich sind auch 

verschiedene Stellen in der Konfiguration die Quellen für die URLs die in 

das Skript und Plugin eingetragen wurden. Dennoch soll das Ziel sein, eine 

häufiger anwendbare Methode zur Überprüfung zu haben, die es nicht 

verlangt, bei jeder Überprüfung sämtliche URLs in der Konfiguration neu 

herauszuziehen. Es ist ebenfalls für weitere Überprüfungen wie den 

automatischen Teil des Audits über z.B. WebInspect notwendig, diese URLs 

in einer geeigneten Form zur Verfügung zu haben. 

Bei der Überprüfung der gefundenen URLs tritt ein ähnliches Phänomen auf 

wie bei der Referenzapplikation cirobank. Während es für klassische 

Webapplikationen jedoch eher selten ist, dass ein HTTP Status 200 als 

Antwort auf nicht verfügbare Ressourcen gesendet wird, ist es bei SAP der 

Normalfall. 



Das zu Beginn erstellte Perlskript, das die Überprüfung von URLs vornahm, 

konnte nicht unterscheiden, ob eine Webapplikation tatsächlich verfügbar 

ist oder nicht. Hier hat sich die Komplexität von SAP als Lösung erwiesen, 

da es möglich ist SAP insofern zu beeinflussen, dass sich das 

Antwortverhalten ändert. Während es, wie erwähnt, bei 

Standardantworten, die das SAP System auf die Anfragen zurück sendet, 

nicht erkannt werden kann, ob z.B. eine Authentifizierung verlangt wird 

oder nicht, kann es durch die Wahl verschiedener spezieller Parameter 

gelingen, das Antwortverhalten so zu beeinflussen, dass das Perlskript dies 

anhand der Antworten feststellen kann (siehe Kapitel 3.3.3). 

Die Entwicklung des Perlskriptes wurde jedoch zugunsten eines Plugins für 

WebInspekt nicht mehr weiter verfolgt. Auch mit diesem Plugin ist es 

möglich, die URLs des SAP-Systems zu überprüfen und bietet noch weitere 

Vorteile. Der größte Vorteil neben einer besseren Benutzbarkeit und zu 

erwartender Akzeptanz ist, dass die URLs für die normale Arbeit von 

WebInspect benutzt werden können. Nur so kann also der erste Teil einer 

Überprüfung stattfinden, das crawlen durch den Scanner und das 

automatische Audit, bei dem eine Vielzahl von Web-Attacken auf die 

Webapplikationen gesendet werden. 

Erst danach kann eine Überprüfung stattfinden, wie sie grundsätzlich von 

klassischen Webapplikationen bekannt ist. Allerdings müssen auch hierbei 

noch spezielle Eigenschaften von SAP beachtet werden, wie z.B. spezielle 

Parameter. 

3.3.2 Typische Angriffe 

Wie schon bei der klassischen Webapplikation wird auch hier zunächst eine 

Vielzahl an bekannten Webapplikationsangriffen durch das Programm 

WebInspect durchgeführt. Eine Voraussetzung für die Funktionsfähigkeit 

des Programms, das für klassische Webapplikationen geschrieben wurde, 

ist wie in Kapitel 3.3.1 erwähnt, ein Plugin, das WebInspect ermöglicht die 

für die Arbeit benötigten Start-URLs zu finden. Jede dieser URLs wird dann 

wie ein Rootverzeichnis auf einem klassischen Webserver behandelt und 

den darin enthaltenen Links zu weiteren Seiten auf diesem Server gefolgt. 

Auf Screenshot Abbildung 12: WebInspect Plugin ist eine Ansicht der 

Regeln des bei WebInspect enthaltenen Policy Managers zu sehen, in den 

die zusätzlichen Prüfungen für SAP schon eingetragen sind. Ein einzelner 

Eintrag besteht aus der Art der des Angriffs und Prüfung, einer 



Einschätzung der Gefährlichkeit, sollte die Prüfung erfolgreich sein, die URL, 

die geprüft werden soll und der erwarteten Antwort des Servers bei Erfolg. 

Ergänzt wird dies durch Informationen über den gefundenen Dienst, so 

dass ein Anwender des Programms, der sich nicht mit den SAP Diensten 

auskennt, ebenfalls eine Einschätzung vornehmen kann. Zu sehen sind hier 

unter Custom Checks die ersten Einträge für den ABAP-Stack eines SAP- 

Systems. 

Abbildung 12: WebInspect Plugin 

Auch bei diesem Plugin wurden die SAP-spezifischen Antworten 

berücksichtigt. Wäre dies nicht geschehen, hätte die Überprüfung auf 

Erreichbarkeit der SAP-Dienste ein falsches Ergebnis geliefert. Das 

Verhalten von Webapplikationen auf Basis von SAP sieht für einen Benutzer 

sowohl für den ABAP-Stack als auch für den JAVA-Stack im Wesentlichen 

identisch aus. Allerdings unterscheiden sich die von SAP zurückgesendeten 

Antworten im ABAP-Stack und JAVA-Stack erheblich, so dass dies von dem 

WebInspect Plugin ebenfalls erkannt werden muss. 

Bei den von WebInspect durchgeführten Angriffen ist es unabdingbar, dass 

Fehlerseiten möglichst zuverlässig erkannt werden können. Hier enthält 

WebInspect bereits viele Einstellungen und auch eine gewisse Intelligenz, 

so dass Fehlerseiten von Webapplikationen erkannt werden können. 

Allerdings erwies sich ein Teil dieser Intelligenz als unvereinbar mit dem 



Antwortverhalten von SAP Systemen. Um die Prüfung auf Fehlerseiten 

zuverlässig zu implementieren ist es notwendig, sowohl Returncodes zu 

berücksichtigen als auch den Body der Antwort auf Inhalte zu durchsuchen 

und diese Resultate zu kombinieren. 

ABAP 

Bei der Prüfung des ABAP-Stacks ist die erste Auffälligkeit, dass – wie bei 

Teilen der Referenzapplikation cirobank – die zurückgegebenen HTTP 

Statuscodes nicht dem entsprechen, was durch das entsprechende RFC 

vorgeschlagen wird. Es wird auf beinahe alle Anfragen ein „200 OK“ zurück 

gesendet, das eigentlich nur für erfolgreiche Anfragen vorgesehen ist. Hier 

wird jedoch auch ein „200 OK“ zurück gesendet, wenn die Ressource nicht 

gefunden werden kann (Abbildung 13: 200 OK - not found), obwohl hier im 

RFC 20 der Status-Code 404 vorgesehen ist und WebInspect dies ohne 

weitere Anpassungen auch so erwartet. Daher werden viele 

Standardprüfungen, die beispielsweise auf häufig anzutreffende Dateien 

oder Dateiendungen wie .bak prüfen, von WebInspect als erfolgreich 

angezeigt. 

Abbildung 13: 200 OK - not found 

Der ABAP-Stack des SAP NetWeaver liefert bei Anfrage auf das 

Rootverzeichnis einen Fehler zurück, der keine weiteren Links auf andere 

Seiten beinhaltet. Zur Verdeutlichung des Problems, dass WebInspect die 

Start-URLs der einzelnen Dienste im Vorfeld bekannt sein muss sei in 

Abbildung 14: WebInspect: Defaultpolicy bei SAP das Ergebnis eines Scans 

ohne das Plugin aufgeführt. Wie zu sehen ist, besteht der ABAP-Stack des 

SAP NetWeaver aus lediglich dem Rootverzeichniss, das gegen alle Angriffe 

immun ist. 

20 http://www.w3.org/Protocols/rfc2616/rfc2616.html 



Abbildung 14: WebInspect: Defaultpolicy bei SAP 

Aus diesem Grund sind alle hier gewonnen Erkenntnisse nur mit Hilfe des 

Plugins möglich, das WebInspect auf den Scan und Audit eines SAP 

NetWeavers vorbereitet. Unter Verwendung des Plugins steigt die Zahl der 

Gefundenen URLs von 1 URL auf 22588 URLs alleine für den ABAP Stack 

an, die dann überprüft werden. 

Das automatische Audit brachte auch unter Verwendung des Plugins und 

damit nach Auditierung aller Dienste des ABAP-Stacks nur wenige, reale 

Ergebnisse. 

Auch hier sind trotz der Anpassungen an SAP viele false-Positives, die 

allerdings auch bei automatischen Audits von klassischen Webapplikationen 

auftreten. 

Wie bereits im Vorfeld erwartet wird das standardmässig aktivierte sap 

info gefunden, das verschiedene, interne Informationen über das SAP- 

System liefert. Es beinhaltet detaillierte Versionsinformationen des SAP- 

Systems und einiger Komponenten, die interne IP Adressen, 

Datenbankinformationen und interne Systembezeichnungen, die für einige 

Funktionen benötigt werden. 

Als nicht kritisch sind von WebInspect gefundene Kommentare im Quelltext 

einzustufen, die sich auf eine frühere Verwendung von Includes beziehen, 

die aber nicht mehr verwendet werden. Es ist technisch gesehen die 

Preisgabe von internen Informationen und des Programmaufbaus, eine 

tatsächliche Verwendung dieser Informationen für einen Angriff ist aber 

extrem unwahrscheinlich. 



Bei der Überprüfung des ABAP-Stacks mittels WebInspect finden sich 

mitunter Meldungen, die sich zunächst nicht eindeutig als reale Ergebnisse 

oder false-Positives erkennen. Hier ist zusätzlicher Arbeitsaufwand 

notwendig um diese Meldungen auf Richtigkeit zu überprüfen. Hierzu 

gehört im Falle des überprüften SAP NetWeaver eine mögliche SQL- 

Injection Schwachstelle, die wie hier zu sehen gemeldet wird (Abbildung 

15: Possible SQL Injection bei SAP). 

Abbildung 15: Possible SQL Injection bei SAP 

Grund für diese Meldung ist der Parameter: sap-system-loginoninputprocessing=onChangePwd'+OR, 

der mit einem SQL-Injection 

Testpattern belegt wurde und die darauf folgende Antwort des SAP- 

Systems aus einer Fehlermeldung bestand, die nicht zu den häufig 

anzutreffenden Standardfehlerseiten gehört. 

Meldungen dieser Art des WebInspects sind ein Beispiel für die Grenzen von 

automatisierten Tests. Obowhl die Voraussetzung für WebInspect anhand 

des Resultates auf eine mögliche SQL-Injection Schwachstelle gegeben 

sind, zeigte sich auch in diesem Fall nach weiteren Prüfungen, dass es sich 

um ein false-Positive handelt. Eine Einschleußung von SQL-Anweisungen ist 

hier nicht möglich. Darüber hinaus handelt es sich hier um eine 

beabsichtige Fehlerseite, die aufgrund einer fehlgeschlagenen 

Eingabeprüfung angezeigt wird, und die nicht nur auf Versuche für SQL- 

Injection reagiert, sondern eine allgemeine Eingabeprüfung darstellt. Daher 

sollten auch in Zukunft Meldungen über mögliche SQL-Injection 

Schwachstellen in SAP kritisch betrachtet werden. 



Die meisten gefundenen Schwachstellen beziehen sich auf die Möglichkeit, 

interne Informationen über das SAP-System einzusehen. Über verschiedene 

Dienste können so detaillierte Informationen über das SAP-System, wie 

verschiedenste Versionsstände und interne IP-Adressen z.B. über 

sap_info, als auch bei dem SAP-System aufrufbare, zusätzliche URLs z.B. 

über icf_info/urlprefix abgefragt werden. 

PORTAL 

Der Ablauf des automatischen Audits des JAVA-Stacks des SAP NetWeavers 

ist gleich und geschieht mit den gleichen Voraussetzungen wie mit dem 

ABAP-Stack. Auch hier zeigen sich die Grenzen des automatischen Audits, 

das bei klassischen Webapplikationen sehr gut funktioniert. Im Gegensatz 

zum ABAP-Stack würde ein Start des WebInspects mit den 

Standardeinstellungen ohne Plugin einige Seiten und Applikationen 

auditieren, da hier ein Teil des Inhalts ausgehend von dem Rootverzeichnis 

verlinkt ist. Dies ist jedoch nur ein Teil der Applikationen, daher ist auch 

hier die Benutzung des Plugins mit den voreingestellten Applikationen und 

weiteren Einstellungen notwendig, um sich ein Gesamtbild verschaffen zu 

können. 

Ebenso wie beim ABAP-Stack verhält sich der SAP NetWeaver auch hier 

nicht RFC-konform, indem er auf nicht verfügbare Ressourcen mit einem 

Statuscode „200 OK“ antwortet. Des Weiteren sind beim JAVA-Stack 

wesentlich mehr Fehlermeldungen des Servers zu verzeichnen. Ein 

vollständiges, automatisches Audit aller auf SAP NetWeaver mit JAVA-Stack 

verfügbaren Applikationen ist kaum möglich, da es eine viel zu lange Zeit in 

Anspruch nimmt ohne erkennbar neue Ergebnisse zu liefern. Auf dem 

folgenden Screenshot (Abbildung 16: False-Positives bei SAP) ist zu 

erkennen, dass das Audit zu diesem Zeitpunkt schon 3GB an Antwortdaten 

zu verarbeiten hat und die Anzahl der gefunden Schwachstellen mit über 

37000 unrealistisch hoch ist. Der Grund für diese hohe Zahl ist im unteren 

Teil des Bildes zu erkennen, wo gleich mehrere Gruppen mit 

Schwachstellen aufgeführt werden, die an 117 Stellen gefunden wurden 

und bei denen es sich offensichtlich um false-Positives handelt. 



Abbildung 16: False-Positives bei SAP 

In diesem Zusammenhang zeigt sich wiederum auch, dass die Ergebnisse 

des automatischen Audits generell manuell verifiziert werden sollten, da 

auch wie im folgenden Fall Prüfungen nicht gründlich durchgeführt werden. 

Hier (Abbildung 17: Beispiel false-Positive) wurde das < und > in der 

Antwort durch < und > codiert, wodurch der hier als erfolgreich 

gemeldete Angriff nicht funktionieren würde. 

Abbildung 17: Beispiel false-Positive 

Das im Falle einer Basisinstallation des SAP Netweaver JAVA-Stacks wie in 

dieser Diplomarbeit einzige nennenswerte Ergebnis trotz der zahlreichen 

Applikatonen, die das System anbietet, ist die Offenlegung interner Pfade 

und Informationen, wie Abbildung 18: Interne Pfade zu sehen. 



Abbildung 18: Interne Pfade 

Dass durch das automatische Audit nur so wenige Schwachstellen gefunden 

wurden, wurde im Vorfeld nicht erwartet. Unter anderem auf Backtraces 

von diversen Fehlermeldungen, die die Prüfungen des Programms 

verursacht haben ist zu sehen, dass bei der Verarbeitung auf dem JAVA 

Stack auch immer Sicherheitskomponenten integriert sind, die dann z.B. 

auch dafür sorgen, dass wie oben gesehen, Tags codiert werden. 

Es kann bereits jetzt gesagt werden, dass für Applikationen auf Basis des 

JAVA Stacks tatsächlich die korrekt vergebenen Berechtigungen eine 

wesentliche Rolle spielen. Gerade hier ist auch das WebInspekt Plugin eine 

gute Methode, um die korrekte Rechtevergabe zu überprüfen. Durch 

Angabe von keinem Benutzer, unpriviligierten Benutzer etc. innerhalb des 

WebInspects kann so, auch ohne automatisches Audit, innerhalb von 

Minuten festgestellt werden, ob Benutzergruppen eventuell auf 

Applikationen zugreifen können, die nur für höher priviligierte Benutzer 

zugänglich sein sollten. 

Dass diese durch den SAP NetWeaver JAVA gegebene Sicherheit 

keineswegs allgemeingültig ist, ist in Kapitel 3.3.4 beschrieben, bei der 

kurz auf die Auswirkungen von Architekturen eingegangen wird, bei denen 

SAP NetWeaver nur einen Teil der Verarbeitungsschritte von Anfragen und 

Antworten übernimmt. 



3.3.3 Manuelle Überprüfung und weitere 

Ansatzpunkte für Angriffe 

Die manuelle Überprüfung muss bei jedem Audit durchgeführt werden, 

unabhängig davon, ob es sich um ein Audit eines SAP NetWeaver handelt 

oder um eine spezielle Applikation, die auf dem NetWeaver ausgeführt 

wird. 

Im Rahmen dieser Diplomarbeit wurde besonderen Wert darauf gelegt, 

sowohl Aussagen über Anfälligkeiten für Angriffe treffen zu können, als 

auch bislang unbekannte Ansatzpunkte zu entwickeln, die sich so bei 

klassischen Webapplikationen nicht finden. Da über diese neuen 

Ansatzpunkte bislang nichts bekannt ist, wurde hier viel Arbeit während der 

Durchführung dieser Diplomarbeit investiert. 


Cross-Site-Scripting ist, wie die meisten der entdeckten 

Sicherheitsprobleme, vor Allem bei SAP NetWeaver auf ABAP Basis zu 

finden. Es ist gleichzeitig ein Thema, das bei SAP sehr wohl als Problem 

erkannt wurde und für das auch zunehmend Lösungsmöglichkeiten gesucht 

und implementiert werden. Verschiedene Tests mit dem zusätzlich 

installierten SAP NetWeaver mit ABAP-Stack in der Version 640 zeigten, 

dass es hier deutliche Fortschritte gibt und in Version 700 weniger 

Möglichkeiten zur Durchführung von Cross-Site-Scripting bestehen. 

Bei SAP besteht häufig die sonst seltene Möglichkeit, Cross-Site-Scripting 

als Teil der URL und nicht als GET oder POST Parameter zu verwenden. Ein 

sehr einfaches Beispiel findet sich in der ABAP Applikation /sap/cachetest. 

Ruft man diese Applikation mit Hilfe der URL 

/sap/bc/cachetest/alert(‘XSS’) auf, wird bei einem 

SAP NetWeaver in der Version 640 dieses Script tatsächlich ausgeführt und 

in diesem Fall die Alertbox angezeigt. In Version 700 hat SAP einen HTTP 

Filter eingebaut, der auch vor Cross Site Scripting schützen soll. Eine 

Eingabe von /sap/bc/cachetest/alert(‘XSS’) hier 

führt zu einer „Access denied“ Fehlermeldung (Abbildung 19: Neuer HTTP 

Filter): 



Abbildung 19: Neuer HTTP Filter 

Dass bei SAP die Sicherheit ihrer Produkte und hierbei auch Cross-Site- 

Scripting bei der Webapplikationssicherheit eine zunehmende Bedeutung 

gewinnt, spielt sicherlich eine Rolle dabei, dass das automatische Audit 

keine verwertbaren Cross-Site-Scripting Schwachstellen gefunden hat und 

auch hier bei der manuellen Prüfung die Ausnutzung erschwert wird. 

Dies bedeutet allerdings nicht, dass die Probleme behoben sind, es wird 

zwar die Eingabe von Tags and dieser Stelle 

verhindert, aber dies deckt nicht alle Möglichkeiten ab Cross-Site-Scripting 

Schwachstellen auszunutzen und ist außerdem noch applikationsabhängig. 

Es ist daher beispielsweise in der Komponente 

/sap/bc/bsp/sap/btf_ext_demo auch weiterhin möglich, mit Hilfe dieser 

bekannten Tags Cross-Site-Scripting durchzuführen (Abbildung 20: Cross- 

Site-Scripting bei SAP). 

Abbildung 20: Cross-Site-Scripting bei SAP 

Es ist also durchaus eine Verbesserung mit neueren Versionen zu 

verzeichnen, aber dies kann das Ausnutzen von Cross-Site-Scripting 



Schwachstellen nicht grundsätzlich verhindern, weil z.B. auch gründliche 

Programmierung aller Applikationen notwendig ist. 

Des Weiteren ist auch wie in Kapitel 2.3.4 beschrieben die Eingabe von 

Schadcode nicht die einzige Möglichkeit für Cross-Site- 

Scripting. Die Filterung, die SAP NetWeaver durchführt ist unvollständig 

und kann so bei einigen Applikationen ein Cross-Site-Scripting nicht 

verhindern. Es wird das tag herausgefiltert, allerdings ist das 

tag für Cross-Site-Scripting wie erwähnt nicht zwingend. 

So kann z.B. in der SAP Webgui auch in der neuen Version 700 ein Cross- 

Site-Scripting erzeugt werden, indem der Parameter 

~webguiuserareaheight wie im Folgenden Beispiel belegt wird: 

/sap/bc/gui/sap/its/webgui/?~webguiuserareaheight="> Diese Eingabe liefert ebenfalls 

einen Proof-of-Concept, dass Cross-Site-Scripting hier funktioniert. 

Standardaccounts 

Als ein überaschend grosses Problem haben sich die Standardaccounts bei 

SAP-Systemen erwiesen. Bei klassischen Webapplikationen ist die Sorge, 

dass Benutzernamen oder Passwörter leicht zu erraten oder zu einfach 

gestaltet sind, überall verwendete, bekannte Benutzernamen – 

Passwortkombinationen findet man selten. Im Gegensatz dazu ist vor Allem 

beim ABAP-Stack die Verwendung von bekannten Standardaccounts üblich. 

Da diese Accounts unter Umständen den kompletten Zugriff auf das SAP- 

System erlauben, müssen diese nach der Installation unbedingt deaktiviert 

werden. Bei SAP NetWeaver JAVA wurde auf Standardaccounts 

überwiegend verzichtet. Trotzdem können auch hier automatisch generierte 

Benutzernamen für verschiedene Zwecke hergeleitet werden, da der 

dynamische Anteil der Systemname des SAP-Systems ist, der unter 

Umständen ausgelesen werden kann. Tabelle 2: SAP Standardaccounts 

bietet eine kurze Übersicht über die bekanntesten Standardaccounts. 



Tabelle 2: SAP Standardaccounts 

Mandant Username Passwort 

000, 001, 066 und alle neuen 

Mandanten (002 bis 999) 

SAP* 

000, 001 DDIC 19920706 

06071992 oder PASS 

000 TMSADM PASSWORD 

066 EARLYWATCH SUPPORT 

000 SAPCPIC Admin 

SDM 

J2EE_ADM_ 

J2EE_GST_ 

Sdm 

SAP* ist hierbei sogar ein Sonderfall, da der Account automatisch wieder 

mit dem Standardpasswort neu generiert wird, sollte versucht werden ihn 

zu löschen 21 . 

ITS Parameter 

Der ITS akzeptiert selbst einige Parameter, die als HTTP GET Parameter an 

URLs angefügt werden können. Dabei können vor allem verschiedene 

Clientparameter beeinflusst werden, aber auch das Verhalten des ITS. 

Parameter: sap-client 

Hiermit kann die Clientnummer beeinflusst werden, mit der sich der 

Benutzer oder das Programm am Server anmeldet. Gerade dieser 

Parameter hat sich als eine der schwerwiegendsten Probleme 

herausgestellt, da hierüber ein Teil der Benutzerauthentifizierung 

umgangen werden kann. 

Dieser Parameter kann dazu verwendet werden, sich mit bekannten 

Benutzern anzumelden, die unter einer anderen Clientnummer registriert 

sind. Ein Beispiel hierfür ist die Verwendung von sap-client=066, was den 

Mandanten für die Wartung des SAP-Systems darstellt. Mit Verwendung 

dieses Parameters können sich dann Benutzer anmelden, die bei den für die 

Applikation vorgesehenen, produktiven Mandanten nicht verfügbar wären. 

Bei dem SAP Mandanten 066 ist eine Anmeldung als der Standardbenutzer 

EARLYWATCH möglich, der auf vielen System nicht deaktiviert wurde. 

21 Es muss zuerst der Loginparameter login/no_automatic_user_sapstar auf einen Wert größer 0 

gesetzt werden. Erst nachdem dies geschehen ist kann die user ID gelöscht werden. Somit wird der 

user SAP* mit Standardpasswort nicht mehr automatisch generiert, wenn er aus der Datenbank 

gelöscht wird. (Quelle: 

http://searchsap.techtarget.com/generic/0,295582,sid21_gci1167162,00.html) 



Dieser Paramter bzw. Angriff kann sehr einfach verwendet werden, sehr 

weitreichende Systemrechte zu gewinnen. Darüber hinaus wird unter 

Umständen die Verfügbarkeit des Supportclienten verlangt um Support zu 

bekommen, was die Eintrittswahrscheinlichkeit dieses Angriffs stark erhöht. 

Parameter: sap-login-method 

Festlegung der Authentifizierungsmethode, hier kann z.B. http_basic 

eingetragen werden, um eine Basic-Authentifizierung zu erzwingen. Dieser 

Parameter wurde im Rahmen dieser Diplomoarbeit in Kombination mit dem 

folgenden sap-login-basic_auth verwendet. 

Parameter: sap-login-basic_auth 

Mittels sap-login-basic_auth=X wird dem Server mitgeteilt, dass eine 

Authentifizierung bereits stattgefunden hat, und sich die Daten in einem 

Cookie befinden, das mitgeschickt wird. Damit ist der Benutzer zwar nicht 

automatisch angemeldet, weil keine Sessiondaten übertragen werden, aber 

damit ist es möglich, die normale Authentifizierungsseite zu umgehen, und 

eine Basic-Authentifizierung auszulösen. 

Nützlich war diese Eigenschaft, um die SAP-Server skriptbasiert 

dahingehend zu testen, ob ein Dienst eine weiter gehende Authentifizierung 

verlangt oder nicht, da diese Information auf diese Weise über den HTTP- 

Status Code erlangt werden kann. 

Anzeige des Quellcodes 

Der ABAP-Stack bringt eine Funktion zum Debuggen von Programmfehlern. 

In Fällen, bei denen ein Programmfehler provoziert werden kann, werden 

also als Antwort detaillierte Informationen ausgegeben, wie der Fehler 

entstand mitsamt verschiedenen Daten des darunter liegenden SAP 

Systems. Dies geht so weit, dass der Quellcode mit angegeben wird, sollte 

ein Programmfehler auftreten. 



Abbildung 21: Source Code Disclosure 

Im vorliegenden Fall (Abbildung 21: Source Code Disclosure) beinhaltet die 

Zeile REPLACE ‚/N’ IN SECTION OFFSET 0 LENGTH 2 OF TCODESTR WITH 

‚’ IN CHARACTER MODE IGNORING CASE einen Fehler, der die Möglichkeit 

bietet, eine Eingabe zu tätigen, die das Programm nicht verarbeiten kann. 22 

Der hier vorliegende, konkrete Fall ist nicht kritisch, es zeigt aber, dass ein 

System auf ABAP Basis per Design die Möglichkeit bereitstellt, den 

Quellcode mitsamt einiger detaillierter Systeminformationen einzusehen. Es 

kann nicht ausgeschlossen werden, dass andere Programme, oder auch nur 

bei Unternehmen übliche Anpassungen bestehender Programme wichtige 

Informationen enthalten, daher sollte eine Anzeige des Quellcodes von 

Programmen niemals für anonyme oder unpriviligerte Benuter möglich sein. 

22 Um dieser Fehler auszunutzen müssen 2 Parameter gesetzt werden. Zum einen muss der 

Parameter ~transaction nicht belegt sein, wie in Zeile 66 und 67 zu lesen ist. Ist dies gegeben, wird 

der Parameter ~okcode ausgewertet, der im normalen Betrieb immer 2 oder mehr Zeichen enthält. 

Da es sich um sowohl um ~transaction als auch ~okcode um normale HTTP GET Parameter handelt, 

kann manuell sehr einfach auch nur eine Stelle eingegeben werden. Der eigentliche Programmfehler 

tritt dann wie oben erwähnt in den Zeilen 78/79 auf, wo versucht wird, 2 Zeichen des Parameters 

~okcode zu entfernen. Sind hier weniger als 2 Zeichen enthalten, fürt dies zu der Debugausgabe. 



3.3.4 Heterogene Systeme 

Architekturbeispiel 

Während der Bearbeitung dieser Diplomarbeit bestand für den Verfasser die 

Möglichkeit, eine Webapplikation zu auditieren, die auf dem SAP NetWeaver 

JAVA aufsetzt, jedoch aus verschiedenen Komponenten besteht, die in 

Abbildung 22:Aufbau einer heterogenen Umgebung in vereinfachter Form 

beschrieben werden. So waren an dem Aufbau der Webapplikation SAP, 

Apache und Tomcat beteiligt. Die Details dieser Überprüfung sind 

selbstverständlich nicht öffentlich, doch konnten diese Ergebnisse in kurzer 

und anonymisierter Form in diese Diplomarbeit mit übernommen werden 

um Aussagen über die Sicherheit von Webapplikationen auf Basis von SAP 

zu belegen. Die Auditierung dieser Applikation zeigte Schwachstellen auf, 

die durch die Überprüfung des SAP NetWeavers JAVA für diese Diplomarbeit 

nur ansatzweise zu erkennen waren. 

Die Authentifizierung der Benutzer wurde in diesem Beispiel getrennt 

hiervon durch ein spezielles Sicherheitsprodukt vorgenommen. 

Abbildung 22:Aufbau einer heterogenen Umgebung 



Die relevanten Zugriffe erfolgten zunächst, durch einen Apache im reverseproxy-Modus 

mit mod_security geschützt, auf einen SAP NetWeaver. Von 

einer dort installlierten Komponente wurden die Anfragen zu einem Apache 

mit Tomcat weitergeleitet, auf dem wiederum ein Plugin für diese 

zusätzliche SAP-Komponente aktiviert war. Als letzter Schritt wurde dann 

auf einem weiteren SAP System die weitere Verarbeitung übernommen und 

auch der Zugriff auf eine Datenbank vorgenommen, die u.a. sensible 

Kundendaten enthielt. Es entstand also eine Architektur, die sich dem 

Client als Mischarchitektur von SAP NetWeaver JAVA und klassischer 

Webapplikation über Tomcat darstellte. 

Die in diesem Beispiel auditierte Applikation war relativ klein und, da auf 

interne SAP-Datenbestände zugegriffen wurde, speziell und gründlich 

abgesichert, was im Vorfeld keine große Anzahl an Funden von 

Gefährdungen erwarten ließ. Dennoch zeichnet dieses Beispiel ein 

ernüchterndes Bild von der zuvor an einem reinen SAP-System überprüften 

Sicherheit von Webapplikationen auf Basis von SAP. 

Es lassen sich aus dieser Überprüfung vier signifikante Ergebnisse 

erkennen, die sich aus falscher Konfiguration des SAP-Systems, mögliches 

Cross-Site-Scripting, und Parameter-Tampering zusammen setzen. 

Die fehlerhafte Konfiguration eines beteiligten SAP-Systems führte zur 

Preisgabe der verwendeten Version und, als kritischer zu betrachten, der 

Möglichkeit von Directory-Listings (Abbildung 23: Directory-Listing mit 

Versionsangabe). 

Abbildung 23: Directory-Listing mit Versionsangabe 

Durch dieses Directory-Listing konnten verschiedenste Dateien 

heruntergeladen werden und war nicht auf dieses Verzeichnis beschränkt. 

Cross-Site-Scripting war hier gleich an mehreren Stellen möglich. So war 

durch die Eingabe von 

"onload=javascript:alert(document.cookie)>


dieser Applikation angezeigt (Abbildung 24: Cross-Site-Scripting in 

Parameter). 

Abbildung 24: Cross-Site-Scripting in Parameter 

Ein weiteres Cross-Site-Scripting wurde in einer für klassische 

Webapplikationen in dieser Form nicht bekannten Variante gefunden. Hier 

war die Eingabe von zwei Slashes (//) am Ende der URL notwendig gefolgt 

von dem Angriffspattern. In diesem Fall ergab sich ein Angriffsmuster von 

der URL: 

https://..../xxxter//">alert(document.cookie). 

Auch hier wurden alle gültigen Cookies preisgegeben und die Mölichkeit des 

Cross-Site-Scriptings erwiesen. 

Ein schwerwiegender Fehler war in dieser Applikation, dass es möglich war, 

einen Parameter zu verändern, der die Ausgabe der Applikation 

beeinflusste. Durch gezieltes Verändern dieses Parameters war es möglich, 

auf einen Teil der in der internen Datenbank hinterlegten Daten 

zuzugreifen, die zu anderen Benutzern gehörten. Die Eigenschaft der 

Applikation, auf die Veränderung des Parameters mit der Herausgabe von 

benutzerfremden Daten zu reagieren war hierbei auf einen Fehler bei SAP 

zurückzuführen. 

Die Überprüfung eines im Einsatz befindlichen SAP-Systems auf JAVA Basis 

hat also reale Schwächen aufgezeigt, die auch, wie in diesem Fall, den 

Livegang einer Applikation die zuvor hin Hinblick auf Sicherheit entwickelt 

wurde zu verzögern. 

3.4 Vergleich der Ergebnisse 

Bei der klassischen Webapplikation waren die Ergebnisse so zu erwarten. 

Auch wenn es sich nur um eine Beispielapplikation handelte, so konnte 

doch gezeigt werden, dass schon das automatische Audit sehr gute 

Ergebnisse liefern konnte, die durch eine manuelle Nacharbeit, wie sie auch 

üblich ist, vervollständigt werden konnte. Die Ergebnisse belaufen sich von 

unkritischen, kleinen Fehlern in der Konfiguration wie bei den Directory- 

Listings, über Cross-Site-Scripting bis hin zu SQL-Injection und damit 



direktem Zugriff auf die Datenbank. Diese Ergebnisse waren relativ einfach 

zu erreichen, da sowohl das Programm WebInspect dafür ausgelegt als 

auch die durchzuführenden Arbeiten und Möglichkeiten bekannt waren. 

Demgegenüber war die Sicherheit von SAP in Hinblick auf Webapplikationen 

vor der Durchführung dieser Arbeiten noch völlig unbekannt und wurde 

auch noch nie ernsthaft untersucht. Das Programm WebInspect war nicht 

auf die Gegebenheiten von SAP angepasst und konnte nur sehr wenige 

Ergebsnisse liefern, die sich dann allerdings in Verbindung mit den 

sogenannten heterogenen Systemen doch insoweit verbesserten, dass 

bekannte Angriffe auf klassische Webapplikationen auch auf das dahinter 

liegende SAP-System übertragen werden konnten, wie bei den gefundenen 

Cross-Site-Scripting Schwachstellen in der URL, für die SAP als Ursache 

ausgemacht werden konnte. Bei der manuellen Überprüfung der SAP 

Systeme ergab sich ein anderes Bild der Situation und vor Allem für den 

ABAP-Stack konnten gravierende Sicherheitsprobleme aufgedecken 

werden. 

Besonders hervorzuheben ist die Kombination des ABAP-Parameters 

sap_client und die Verwendung von Standardaccounts, da es sich hier um 

einen generischen Ansatz handelt und damit alle SAP Systeme auf ABAP- 

Basis betrifft, unabhängig von der verwendeten bzw. überprüften 

Applikation. Um so gravierender ist, dass auf diesem Weg weitreichende 

Systemrechte erlangt werden können und somit ein anomymer Benutzer, 

für den die Applikation bzw. das SAP-System lediglich über HTTP erreichbar 

ist nahezu oder vollständige Administrationsrechte besitzt. Dieser Angriff ist 

kein theoretisches Konstrukt, sondern ein real möglicher Angriff. 

Verschlimmert wird die Situation mit Standardaccounts durch die Tatsache, 

dass die Verwendung eines anderen Mandanten über den Parameter 

sap_client nicht immer notwendig ist und sogar die bei der Installation 

angelegten Administratorkonten unbenutzt und damit mit dem 

Standardpasswort öffentlich verfügbar sind. 

Die manuelle Überprüfung hat außerdem gezeigt, dass es einige 

konzeptionelle Schwachstellen gibt, die bei einer Überprüfung einzelner 

Webapplikationen auf Basis von SAP von Bedeutung sind wie mögliches 

Cross-Site-Scripting, Anzeige von Quelltexten und anderen Informationen 

oder Beeinflussung des Verhaltens des SAP-Systems über Veränderung von 

Parametern. Hierzu gehört auch, dass SAP trotz Verbesserung wie dem 

HTTP_Filter keinen grundsätzlichen Schutz vor von klassischen 

Webapplikationen bekannten Angriffen bieten kann. 



Dennoch hat sich die Basisinstallation des NetWeaver ohne spezielle 

Applikationen als resistenter gegenüber Angriffen gezeigt, als es bei 

klassischen Webapplikationen der Fall ist. 

Insbesondere der JAVA-Stack hat keine generischen Angriffe, die 

unabhängig von einer vom Kunden verwendeten Applikation sind, 

zugelassen. 

Bei einer vollständigen Überprüfung eines SAP Systems als Ganzes und 

nicht nur einzelner Webapplikationen ist die grösste Herausforderung das 

Auffinden tatsächlich verfügbarer Dienste. Sobald alle erreichbaren 

Webapplikationen bekannt sind, kann im Wesentlichen ein Audit wie bei 

klassischen Webapplikationen durchgeführt werden, natürlich unter 

Beachtung der SAP-Besonderheiten wie globale Parameter. 

Auf diese Weise können außerdem Fehlkonfigurationen an der 

Rechtevergabe schnell und effektiv erkannt werden. Ein untergeordneter 

Punkt hierbei ist auch die Informationsgewinnung. Teile der Applikation, 

wie z.B. durch direkten URL-Aufruf sichtbare Teile ohne 

Nutzungsberechtigung oder auch Fehlerseiten können so schon durch das 

automatische Audit durch einen Webapplikationsscanner wie WebInspect 

gefunden werden. 


Bei der klassischen Webapplikation, die als Referenz verwendet wurde, 

verlief die Überprüfung wie es im Vorfeld zu erwarten war. Das 

automatische Audit des Scanners funktionierte bis auf einige kleinere 

Schwächen problemlos und lieferte auch, abgesehen von ungewöhnlich 

vielen false-Positives, sehr gute Ergebnisse. Die manuelle Überprüfung 

vertiefte diese noch und förderte auch bedeutsame Schwachstellen zu 

Tage, die der Scanner nicht fand. Insgesamt verhielt sich die klassische 

Webapplikation wie Webapplikationen, die man auch im Internet findet und 

auch die Überprüfung war vergleichbar, sowohl in Hinblick auf den Ablauf 

als auch auf die Ergebnisse. 

Bei SAP zeigte sich zunächst, dass schon das automatische Audit nicht ohne 

Weiteres möglich ist und der Scanner zunächst darauf vorbereitet werden 

muss. Bei der daraufhin möglichen Überprüfung waren die Ergebnisse 

sowohl bei ABAP auch auch bei JAVA von einer Masse an false-Positives 

geprägt. Darüber hinaus waren verifizierbare, also echte Schwachstellen 



mit dem Scanner kaum zu finden. Eine Evaluation der laufenden Dienste 

und der dazugehörigen Rechtevergabe ist hiervon aber nicht betroffen und 

ist nur mit dem Scanner effektiv zu bewerkstelligen. 

Bei der manuellen Überprüfung sind signifikante Unterschiede zwischen 

ABAP- und JAVA-Stack festzustellen. Bei SAP mit ABAP-Stack lassen sich 

zum einen mehr Schwachstellen wie Cross-Site-Scripting finden, zum 

anderen sind hier die immer verfügbaren Parameter eine große Gefahr. 

Nicht zu vernachlässigen sind ebenso die Standardaccounts, die, teilweise 

in Kombination mit einer Parameterveränderung, einen leichten Zugang 

zum SAP-System gewähren. 

Bei SAP mit JAVA-Stack zeigen sich zunächst wenig anfälligkeiten für 

Webapplikationsangriffe. Allerdings zeigt die zusätzlich durchgeführte 

Überprüfung des heterogenen Systems, dass sich auch bei SAP auf JAVA 

Basis durchaus Schwachstellen finden, die sich bei einem reinen Basis 

System nur ansatzweise gezeigt haben. Insgesamt hat sich gezeigt, dass 

Webapplikationen auf Basis von SAP sowohl mit ABAP- als auch JAVA-Stack 

eine tendenziell höhere Resistenz gegenüber Angriffen aufweisen, aber 

dennoch ebenfalls gravierende Lücken aufweisen, die bis zu einem 

unautorisierten Zugriff auf die Datenbank oder gar Vollzugriff auf das SAP- 

System reichen können. 



4 Vergleich klassischer Webapplikationen mit SAP 

aus Verteidigersicht 

Im Folgenden soll ein Vergleich gezogen werden zwischen den 

Möglichkeiten und dem Aufwand zur Absicherung der Gefahren, die in 

Kapitel 2.3.4 aufgezeigt wurden. Das Ziel einer Absicherung ist die 

Minimierung der Gefahren und Angriffpunkte, so dass eine erhöhte 

Sicherheit im Sinne der IT-Sicherheit (vgl. Definition in Kapitel 2.2.1) 

entsteht. Da niemals eine hundertprozentige Sicherheit bestehen kann, 

muss immer zwischen dem Aufwand und dem erzielbarem 

Sicherheitsgewinn abgewogen werden. 

Bei der Absicherung eines IT-Systems genügt es nicht, sich nur auf eine 

Ebene, wie z.B. der Absicherung des Betriebssystems zu konzentrieren. 

Vielmehr muss eine ganzheitliche Betrachtung vorgenommen werden, die 

alle Komponenten mit einbezieht. Wesentliche Bereiche in Hinblick auf 

Webapplikationen sind die sichere Konfiguration des Betriebssystems, das 

auch einspielen von Patches beinhaltet, ein sicherer Aufbau und 

Konfiguration des Netzwerkes und der Komponenten des Netzwerkes, eine 

sichere Konfiguration der auf den IT-Systemen installierten Komponenten 

und Diensten sowie eine sichere Programmierung um die in Kapitel 2.3.4 

vorgestellten Gefahren zu vermeiden. 

Dieses Kapitel beschäftigt sich nicht mit Absicherungsmöglichkeiten von 

Betriebssystemen und Netzwerken, sondern mit spezifischeren 

Möglichkeiten zur Absicherung von Webapplikationen bzw. 

Webapplikationen auf Basis von SAP. Dies beinhaltet die sichere 

Konfiguration der für Webapplikationen zentralen Diensten und 

insbesondere SAP Systeme, sowie zentrale Aspekte einer sicheren 

Programmierung. Besonderen Wert legt gelegt wird auf eine auch in der 

Praxis bevorzugten, weitere Ebene, die versucht, die Webapplikationen auf 

Anwendungsschicht gegen alle Gefahren, die in Kapitel 2.3.4 beschrieben 

werden, abzusichern und somit eine zusätzliche Sicherheitsschicht darstellt, 

die den Bereichen sichere Programmierung und Konfiguration übergeordnet 

ist. 

In diesem Kapitel wird nach einer Einführung in vorgeschlagene und 

verwendete Sicherheitsarchitekturen in Hinblick auf Netzwerktopologien 

und der Erklärung der prinzipiellen Funktionsweise der dazugehörigen 

Webapplikationsfirewalls sowohl die Abischerung der Webapplikation 

cirobank als exemplarischem Beispiel von klassischen Webapplikationen als 



auch die Absicherung verschiedener SAP Komponenten behandelt und im 

Anschluss wiederum ein Vergleich aus dem Aufwand und den Ergebnissen 

gezogen. 

4.1 Sicherheitsarchitekturen 

Sicherheitsarchitektur klassische Webapplikation 

Die Sicherheitsarchitektur von klassischen Webapplikationen ist geprägt 

von der Aufteilung in Zonen für die verschiedenen Komponenten, wie sie 

sich aus den demilitarisierten Zonen für normale, über Internet erreichbare 

Applikationen, entwickelt hat. Mit fortschreitendem Bewusstsein des in 

Kapitel 2.3.2 beschriebenen Port 80 Problems erfolgt gerade zur Zeit der 

Bearbeitung dieser Diplomarbeit eine zunehmende Verbreitung von 

Application Layer Gateways bzw. in diesem Fall Webapplikationsfirewalls, 

die sich in Zukunft noch verstärken wird. 

Das Bundesamt für Sicherheit in der Informationstechnik gibt hierzu auch 

eine Empfehlung für eine Architektur (Abbildung 25: Topologiebeispiel 

Webapplikation BSI) mit mehreren Firewalls und Application Layer 

Gateways 23 , die in der Praxis jedoch nur äußerst selten zum Einsatz 

kommt. Hier werden DMZ mittels Paketfilter zwischen Internet und 

internem Netzwerk gebildet, den die verschiedenen Server stehen. Der 

Netzwerkverkehr wird in diesen DMZ so geleitet, dass diese Server 

innerhalb der DMZ jeweils über Application Layer Gateways zursätzlich 

geschützt sind. 

23 IT Grundschutzhandbuch, Massnahme 5.119, 

http://www.bsi.bund.de/gshb/deutsch/m/m05119.htm 



Abbildung 25: Topologiebeispiel Webapplikation BSI 

Das in der Praxis weit häufiger anzutreffende Szenario (Abbildung 26: 

Topologiebeispiel Webapplikation) besteht demgegenüber aus Paketfiltern 

für die Segmentierung sowie zumindest eines Application Level Gateways 

zur Absicherung der Webapplikation, in seltenen Fällen ergänzt durch ein 

Application Level Gateway zur Absicherung des Backends. Das Backend 

sollte ebenfalls in einer getrennten Zone stehen, doch befindet sich das 

Backend tatsächlich in vielen Fällen im internen Netz. 

Abbildung 26: Topologiebeispiel Webapplikation 

Die Absicherung von demilitarisierten Zonen und internen Netzwerken auf 

Paket- und Transportschicht ist inzwischen eine alltägliche Arbeit, so dass 

eine gute Absicherung auf diesen Ebenen vorausgesetzt werden kann. 



Zusätzlich sollten und werden auch in zunehmendem Maße spezielle 

Webapplikationsfirewalls eingesetzt, die dem trotz der Paketfilter 

bestehendem Port 80 Problem entgegen wirken. 

Sicherheitsarchitektur SAP 

Angelehnt an die Architektur zur Absicherung klassischer Webapplikationen 

empfiehlt SAP eine Architektur (Abbildung 27: Empfohlene Topologie SAP), 

die Webapplikationen auf Basis von SAP sicher machen soll 24 . Nachfolgend 

ist die Variante dargestellt, die die höchste Sicherheit bietet. 

Abbildung 27: Empfohlene Topologie SAP 

Diese Struktur ist grundsätzlich sinnvoll, und ist der, die bei der 

Absicherung klassischer Webapplikationen zu Grunde liegt, sehr ähnlich. 

Allerdings erweist sich die Struktur hier noch auf der Betrachtungsweise 

aus Netzwerkschicht begründet, d.h. vor Allem zur Absicherung auf Paketund 

Transportschicht geeignet. 

Für die Sicherheitsüberprüfung, wie sie diese Diplomarbeit zum Thema hat, 

ist die erste und teilweise auch die zweite Firewall bedeutungslos, da 

sämtliche Angriffe ohnehin offene Ports benutzen und auf höherer OSI- 

Ebene ansetzen. Dies bedeutet, dass alle Attacken innerhalb der ALLOW- 

Regeln der ersten Firewall stattfinden. 

Aus Gründen, die nachfolgend beschrieben werden, wird der Einsatz des 

WebDispatchers hier nicht näher betrachtet. Er wird durch dieselben 

Produkte ersetzt wie sie bei klassischen Webapplikationen zum Einsatz 

kommen, um diese auf Applikationsebene abzusichern. 

Hierdurch entfällt auch der WebDispatcher als Angriffsziel und es bleibt nur 

noch die Loadbalancing-Funktion, die spezielle Loadbalancer übernehmen 

24 

http://help.sap.com/saphelp_nw04s/helpdata/en/8d/f3da779bd02c4fa54fda5d6944f2d6/frameset.ht 

m 



können oder auch die in dieser Diplomarbeit eingesetzten 

Webapplikationsfirewalls. Somit hat auch die zweite Firewall aus Sicht der 

in dieser Diplomarbeit behandelten Thematik keine besondere Bedeutung 

mehr. 

Da der Web Application Server durchaus ein Angriffsziel ist und auch in 

reellen Szenarien als ‚Sprungbrett’ auf weitere Systeme dienen kann, ist 

eine Firewall zwischen Applikationsservern und Backendsystemen, bzw. 

allen anderen Systemen, sinnvoll. Die Besonderheit der SAP Systeme, 

gegen SQL Injection resistent zu sein, macht einen Angriff z.B. auf die 

dahinterliegende SQL-Datenbank, die sich typischerweise im internen Netz 

befindet nicht unmöglich, aber es ist weniger wahrscheinlich, dass der 

durch die dritte Firewall erlaubten SQL Ports über den normalen 

Applikationsverlauf und somit transparent verwendet werden kann. 

Allerdings bietet dies keinen hinreichenden Schutz gegen einen 

komprommitierten Applikationsserver, da von hier unter Umständen die 

Datenbank direkt angesprochen werden kann. 

Die Gründe für den zuvor erwähnten Entfall des SAP Web Dispatchers 

basieren auf folgenden Erkenntnissen: Der Zweck des WebDispatchers 

besteht aus 

Lastverteilung 

Zentraler Einstiegspunkt für alle Applikationsserver von Clientseite, 

d.h. nur eine ‚Unternehmens’-URL, hinter der verschiedene 

Applikationen und auch SAP Systeme stehen können 

Persistenz der Sitzungen 

SSL-Verschlüsselung, als in Ende zu Ende Verbindung eingegeliedert 

oder als Terminierungspunkt 

Damit verbundene optionale Wiederverschlüsselung zu eigentlichen 

SAP Applikationsservern 

Einfache Konfiguration, die mit der Einstellung nur weniger 

Parameter durchgeführt werden kann 

Als Sicherheitsfunktion eine rudimentäre URL-Filterung 

Hieraus ergeben sich unter Kenntniss der Absicherungsmöglichkeiten 

klassischer Webapplikationen verschiedene Schlussfolgerungen 

Der SAP Web Dispatcher hat nur eine geringe Funktionalität als 

Applikationsfilter 



Übliche Loadbalancingfunktionen können auch von komerziellen 

Webapplikationsfirewalls erbracht werden inklusive Peristenz der 

Sitzungen 

SSL als Ende zu Ende Integration oder Terminierungspunkt wird 

ebenfalls von allen Webapplikationsfirewalls unterstützt – Für 

Hochlastsysteme finden spezialisierte Produkte für die SSL- 

Terminierung Verwendung. 

Durch Fähigkeiten wie URL Rewriting kann auch die 

Webapplikationsfirewall oder ein Loadbalancer als zentraler 

Einstiegspunkt arbeiten. 

Da eine Webapplikationsfirewall dies und vor Allem weitreichende 

Sicherheitsfunktionen bietet, ist eine Ersetzung des WebDispatchers für in 

dieser Diplomarbeit gegebenen Rahmenbedingungen durch profesionelle 

Webapplikationsfirewalls sinnvoll. 

4.2 Web Application Firewalls 

Allgemein 

Bei Webapplikationsfirewalls handelt es sich um eine relativ neue 

Technologie, für die es vor 10 Jahren erste Produkte gab, doch die 

weitestgehend unbekannt blieben. Inzwischen gibt es eine stark steigende 

Nachfrage und wird in seltenen Fällen, wie z.B. für PCI-Konformität, 

verlangt, so dass sich der Verkauf von Webapplikationsfirewalls in den 

letzten 2 Jahren verdoppelt hat 25 [Forrester]. 

Entwickelt wurden die Webapplikationsfirewalls um vor den in Kapitel 2.3.4 

beschriebenen Angriffen zu schützen. Da Firewalls wie sie bislang 

eingesetzt werden lediglich auf Paket- und Transportschicht arbeiten, 

können sie die Gefährdungen, den Webapplikationen ausgesetzt sind, nicht 

verringern. Deshalb wurde die Idee von Application Level Gateways 

aufgegriffen und speziell für das Web-Umfeld angepasst. Die daraus 

enstandenen Webapplikationsfirewalls ergänzen die bestehenden Firewalls 

und schützen vor Angriffen auf Applikationsebene, die durch das in Kapitel 

2.3.2 beschriebene Port 80 Problem durch die Paketfilter hindurch möglich 

sind. 

25 

http://www.forrester.com/Research/Document/Excerpt/0,7211,41780,00.html 



Webapplikationsfirewalls können verschiedensten Kriterien 26 genügen, 

darunter 

Integration als Bridge oder Reverse proxy (Einbindung in OSI- 

Layer2 oder Aufsplittung der IP-Verbindung) 

SSL-Unterstützung inline oder als Terminierungspunkt, 

Unterstützung für Client-Zertifikate 

Appliance oder Softwarelösung 

Fähigkeit zum Hochverfügbarkeitscluster 

Loadbalancing, darunter verschiedene Algorithmen (z.B. Round 

Robin, weighted round Robin) 

Umschreiben von URLs und Domains (Ersetzung von URLs und 

Domainnamen bei Backendverbindung – Möglichkeit, alle Server für 

Clients im Internet als eine große Domain erscheinen zu lassen) 

Garantierung von Sitzungspersistenz ( Sitzung bleibt auch z.B. bei 

Ausfall eines Servers im HA-Systems erhalten) 

Decodierung verschiedenster Encoding types (ASCII, UTF8, etc.) 

Response Filtering (Unterdrückung von Fehlermeldungen und 

Filterung der als sensibel definierten Daten wie 

Kreditkartennummern) 

Blacklist oder Whitelistbasierter Schutz, bzw. eine Kombination 

Dynamisches- oder statisches Regelwerk (gelernte Regeln oder 

unveränderliche Regeln, die im Vorfeld von Hand eingetragen 

werden) 

Schützt Cookies, Sessions, Felder, URLs vor XSS und Derivate, 

Injection flaws, forceful browsing, etc. 

Funktion als Authentisierungsproxy 

Logging und Reportingfähigkeiten 

Da sowohl bei klassischen Webapplikationen als auch bei Webapplikationen 

auf Basis von SAP grundsätzlich dieselben Angriffsmethoden benutzt 

werden können, ist zu erwarten, dass eine Webapplikationsfirewall sowohl 

bei klassischen Webapplikationen als auch bei Webapplikationen auf Basis 

von SAP einen wirksamen Schutz bieten kann (Abbildung 28: Arbeitsweise 

WAF). Hier ist der Einsatz einer Webapplikationsfirewall schematisch 

dargestellt, weitere Netzwerkkomponenten und Segmente sind hier nicht 

berücksichtigt, da sie auf die Filterung keine Auswirkung haben. 

26 http://www.webappsec.org/projects/wafec/v1/wasc-wafec-v1.0.html 



Abbildung 28: Arbeitsweise WAF 

Einsatz der Web Application Firewalls in dieser Diplomarbeit 

Der Einsatz von Webapplikationsfirewalls ist ein Hauptmerkmal zur 

Absicherung von Webapplikationen in dieser Diplomarbeit. In der Praxis 

wird dies zunehmend eingesetzt, um wie in dieser Diplomarbeit geschehen 

auch SAP-Systeme abzusichern, obwohl die Einsatzmöglichkeiten und das 

erreichbare Schutzlevel bislang noch gar nicht bekannt waren. Diese 

Diplomarbeit soll daher auch die Sinnhaftigkeit dieser Möglichkeit 

evaluieren 

Um dies zu erreichen wurden einige Teilkomponenten der SAP Systeme 

exemplarisch abgesichert. Eine vollständige Absicherung der Basis- 

Komponenten würde den Rahmen dieser Diplomarbeit bei Weitem sprengen 

und auch kein Gewinn an Erkenntnissen bringen, da die grundsätzlich 

verwendeten Technologien in den getesteten Komponenten enthalten 

waren und somit die Eignung auch mit den getesteten Komponenten 

beurteilt werden kann. 

Bei der Konfiguration ist weder bei klassischen Webapplikationen noch bei 

SAP ein generisches Regelwerk möglich. Bei klassischen Webapplikationen 

gibt es hierfür zu viele Variationen und Technologien, während bei SAP 

schon die Möglichkeiten, die SAP selbst bietet zu komplex und verschieden 

sind, wie beispielsweise die Parameter als Teil der URL, was zur Zeit noch 

von keiner Webapplikationsfirewall auf diese Weise berücksichtigt wird. Als 

Lösung für SAP wird daher angestrebt, ein gutes Sicherheitslevel zu 

erreichen unter der Voraussetzung, dass die konkrete Implementation der 

Webapplikation auf SAP-Basis wenig Flexibilität in Hinblick auf URL, 

Parameter, Header, Methoden aufweist. 



Verwendete Produkte 

Für die zur Absicherung zu verwendenten Produkte von Webapplikationen 

kamen vor Allem in Hinblick auf die Integrationsanforderungen und das 

hohe Schadenspotential von SAP nur kommerzielle Produkte in Frage. Frei 

verfügbare Programme wie mod_security 27 bieten keine vergleichbaren 

Schutzmöglichkeiten und ebenfalls nicht die geforderten Funktionen, da 

hier Hochverfügbarkeit, Zuverlässigkeit und Performance bei allen 

Aufgaben gegeben sein muss. Ebenso ist eine professionelle Unterstützung 

für Konfiguration der Webapplikationsfirewall und im Fehlerfall 

unverzichtbar. 

Auf dem Markt sind derzeit nur weniger Anbieter, dennoch wurden für eine 

qualifiziertere Aussage über die Absicherungsmöglichkeiten 2 Produkte 

verwendet: 

Citrix NetScaler 8.0: Nachfolger der ersten verfügbaren 

Webapplikationsfirewall 28 

NetContinuum 6.0: 29 Webapplikationsfirewall mit den meisten 

Installationen in Deutschland 30 

4.3 Absicherungsmöglichkeiten klassischer 

Webapplikationen 

Konfiguration der Komponenten 

Bei klassischen Webapplikationen gibt es eine große Vielfalt an 

Komponenten und für jede Komponente eigene Richtlinien, wie sie 

abzusichern sind. Hier sind einige Einstellungen aufgeführt, die 

typischerweise bei einem Audit der bei der cirobank verwendeten 

Komponenten auffällig sind oder den besondere Beachtung geschenkt 

werden sollte. Eine Liste der erarbeiteten Konfigurationsempfehlungen sind 

in Anhang B: Konfigurationsempfehlungen und Programmierrichtlinien zu 

finden. 

Programmierrichtlinien 

Als zweite Komponente werden einige Programmierrichtlinien dargestellt, 

die für die Vermeidung von Schwachstellen in Webapplikationen wichtig 

27 http://www.modsecurity.org/ 

28 http://www.citrix.com/ 

29 Anmerkung: Das hier getestete NCOS 6.0 ist ein neues major Release und zum Zeitpunkt der 

Diplomarbeit die erste Installation dieser Version in Deutschland. 

30 http://www.barracudanetworks.com/netcontinuum/ 



sind. Es werden sowohl allgemeine, sprachenübergreifende Empfehlungen 

gegeben, als auch spezifischere, auf Schwachstellen einzelner 

Programmiersprachen gerichtete Empfehlungen. Eine detaillierte Liste 

findet sich wiederum auch hier in Anhang B: Konfigurationsempfehlungen 

und Programmierrichtlinien. 

Absicherung mittels der Web Application Firewalls 

Ein Umprogrammieren von Applikationen ist, wie die praktische Erfahrung 

zeigt, nicht immer durchführbar und mit erheblichem Aufwand verbunden. 

Gerade bei SAP, so haben auch Gespräche des Verfassers mit Entwicklern 

gezeigt, ist ein Umprogrammieren bestehender Applikationen, insbesondere 

der von SAP bereitgestellten Teile, oft problematisch. Immer häufiger 4 

wird auf den Einsatz einer Webapplikationsfirewall als eine der 

Sicherheitskomponenten gesetzt, die Fehler bei der Konfiguration der 

beteiligten Komponenten und der Programmierung auszugleichen versucht. 

Für die Bearbeitung der Diplomarbeit hat der Verfasser dieses Element als 

praktische, übergreifende Komponente exemplarisch für die Absicherung 

sowohl der klassischen Webapplikation als auch von Webapplikationen auf 

Basis von SAP verwendet um deren Eignung einer Prüfung zu unterziehen. 

Bei der klassischen Webapplikation wurden keine Probleme erwartet. Zwar 

wurde die Konfiguration einer Webapplikationsfirewall für die 

Webapplikation cirobank zum ersten Mal durchgeführt, jedoch sind die 

Webapplikationsfirewalls weit genug entwickelt, um bei den meisten RFCkonformen 

Webapplikationen mit vertretbarem Aufwand den geforderten 

Schutz erbringen zu können. 

Als ersten Schritt wurde die Webapplikation cirobank durch Citrix NetScaler 

8 gesichert, wobei der bevorzugte Lernmodus verwendet wurde. 

Im Lernmodus werden alle Seiten, Parameter, etc. der Applikation mit 

deren Länge und Art der erlaubten Zeichen gelernt und bei Bedarf diese 

Regelungen wieder angepasst. Dies kann dazu führen, dass die Regeln sehr 

zahlreich werden und der vor Allem in Deutschland geforderten 

Nachvollziehbarkeit und Wartung im Wege stehen. Daher wurden zu 

zahlreiche, detaillierte Regeln durch generalisierte Regeln ersetzt, die dann 

zwar ein theoretisch weniger hohes Sicherheitsniveau bieten, aber durch 

die praktische Prüfung mittels der Angriffe, für die die Webapplikation 

verwundbar ist, vom Verfasser als ausreichend befunden wurde. 



In einigen Fällen ist die manuelle Überarbeitung der Regeln auch 

notwendig, wie das folgende Beispiel (Abbildung 29: Anzupassende Regel) 

zeigt. Hier würde, nach Aktivierung der Regeln, jede Anfrage geblockt 

werden, weil in dem include-Parameter das Datum verwendet wird und von 

der Webapplikationsfirewall natürlich nur mit diesem Datum gelernt wurde. 

Abbildung 29: Anzupassende Regel 

Die Konfiguration der Citrix NetScaler für die Webapplikation cirobank 

verlief im Übrigen mittels des Lernmodus problemlos. 

Die Durchführung der Webapplikationsangriffe, für die sich die 

Webapplikation cirobank verwundbar gezeigt hat, wurden ausnahmslos von 

der Webapplikationsfirewall ohne weitere Anpassungen abgefangen und 

eine definierte Fehlerseite (Abbildung 30: Gelockter Angriff bei Citrix) 

angezeigt. 

Abbildung 30: Gelockter Angriff bei Citrix 



Zusammenfassend verlief die Konfiguration der Webapplikationsfirewall 

Citrix NetScaler wie vom Verfasser erwartet und auch das Schutzlevel 

ensprach den Anforderungen völlig. 

Bei der Verwendung der Webapplikationsfirewall NetContinuum 6.0 wurde 

ergänzend zu einer Absicherung durch den ebenfalls vorhandenen 

Lernmodus auch eine Absicherung durch ein statisches Regelwerk 

durchgeführt, wie es in der Praxis bislang weitaus häufiger vorkommt. 

Die Verwendung des Lernmodus ist bei NetContinuum mit Citrix zu 

vergleichen. Es wurde eine einzelne Einstellung angepasst, um die 

Interoperabilität mit der Webapplikation cirobank zu sichern. Eine solche 

Anpassung ist auch bei klassischen Webapplikationen nicht unüblich und 

führen nicht zwangsweise zu einer erhöhten Gefährdung. Im konkreten Fall 

wurde eine spezielle Prüfung für Cross Site Request Forgery bei einem 

Parameter deaktiviert, der Teil eines Ajax-Requests war. 

Die Verwendung des statischen Regelwerks wurde vom Verfasser 

absichtlich allgemeiner gehalten als das resultierende Regelwerk des 

Lernmodus. Dies spiegelt die Konfiguration wieder, wie sie bei 

Installationen im produktiven Einsatz verwendet wird. 

Eine Gegenüberstellung der gelernten, dynamischen (Abbildung 31: 

Dynamisches Regelwerk), bzw. statischen (Abbildung 32: Statisches 

Regelwerk) Regeln für die erlaubten URL-Pfade und Dateien zeigt, dass sich 

schon mit bei dieser kleinen Applikation die automatischen Regeln des 

Lernmodus teilweise deutlich von denen der statischen Konfiguration 

unterscheiden. 

Abbildung 31: Dynamisches Regelwerk 



Abbildung 32: Statisches Regelwerk 

Die Anwendung der gefunden Webapplikationsangriffe sollten zeigen, ob 

zum einen der Einsatz auch dieser Webapplikationsfirewall den 

Anforderungen genügt und außerdem, wie groß der Unterschied des 

Schutzlevels zwischen dynamischem und statischem Regelwerk bei 

klassischen Webapplikationen ist. 

Im Wesentlichen hat sich hierbei bestätigt, dass auch hier ein gutes 

Sicherheitsniveau erreicht werden kann und auch dieses Produkt für den 

Einsatz zur Absicherung einer klassischen Webapplikation geeignet ist. Mit 

nur jeweils einer Ausnahme wurden alle Angriffe sowohl mittels des 

dynamischen als auch des statischen Regelwerks geblockt (Abbildung 33: 

Geblockter Angriff bei NetContinuum) und eine Fehlerseite angezeigt, die in 

diesem Fall von der NetContinuum selbst ausgeliefert wird. 

Abbildung 33: Geblockter Angriff bei NetContinuum 

Das dynamische Regelwerk erkannte den für Parameter tampering 

anfälligen Parameter ‚cid’, mit Hilfe dessen ein Benutzer die Applikation in 

den Administrationskontext setzen kann, fälschlicherweise als 

Eingabeparameter und hat somit diesen Angriff nicht verhindert. 

Ein manuelles Anpassen der Parameterart auf ‚Read-Only’ behob dieses 

Problem, so dass ein vollständiger Schutz gegeben war und der Angriff von 

der Webapplikationsfirewall abgefangen wurde (Logfileauszug in Abbildung 

34: Geblocktes Parameter Tempering). 



Abbildung 34: Geblocktes Parameter Tempering 

Das statische Regelwerk betrachtete das manuelle Einschleusen des HTML 

Codes ">


2.2.5) sicherlich auf hohem Niveau, jedoch in Hinblick auf 

Webapplikationssicherheit mangelhaft und hauptsächlich auf 

Accountsicherheit aufgebaut. Die vorgeschlagene Sicherheitseinstellung für 

HTTP beschränkt sich für den JAVA Stack beispielsweise laut SAP 

NetWeaver Security Guide auf den Einsatz von SSL. Daher sind auch die 

hier aufgeführten Empfehlungen das Resultat aus der kritischen 

Betrachtung der Empfehlungen von Seiten SAPs und den durch den 

Verfasser im Rahmen der Durchführung dieser Diplomarbeit gewonnenen 

Erkenntnisse. 

SAP bietet eine gut konfigurierbare Passwort Policy, die u.a. 

Komplexitätsanforderungen, Gültigkeitsdauer und Accountdeaktivierung 

definiert (siehe Anhang B: Konfigurationsempfehlungen und 

Programmierrichtlinien). Diese Einstellungsmöglichkeiten sollten gemäß der 

Unternehmenspolicy gesetzt werden, z.B. Mindestlänge 8 Zeichen mit 

Gross- und Kleinbuchstaben und mindestens einem Sonderzeichen, das alle 

8 Wochen geändert werden muss. 

Ausser acht gelassen sind bisher die Standardaccounts, die sich auch bei 

prakischen Überprüfungen des Verfassers als großes Sicherheitsrisiko 

dargestellt haben. Der Account DDIC darf allerdings unter Umständen nicht 

gelöscht werden, genau so EARLYWATCH, so dass im Vorfeld eine 

Überprüfung, ob das Löschen hier möglich ist, vorgenommen werden muss. 

Als letzten, immer vorhandenen Account mit bekanntem Passwort sollte 

SAP* deaktiviert werden. Löschen ist wie in Kapitel 3.3.3 beschrieben nicht 

möglich, jedoch die Deaktivierung. 

Das zweite übliche Element bei der Absicherung durch 

Konfigurationseinstellungen ist das klare Setzen von Rollen, Gruppen und 

Userrechten, inklusive deren Zuordnung zu Gruppen/Rollen. 

Für RFC, das SAP eigene Kommunikationsprotokoll muss 

auth/rfc_authority_check aktiv sein, da sonst Berechtigungen nicht geprüft 

werden. Sogenannte Bausteine können RFC-fähig gemacht werden, womit 

sie entfernt aufgerufen werden können. Dies sollte nur für Bausteine 

geschehen, für die das notwendig ist, da fehlerhafte, über RFC aufrufbare 

Bausteine ein nicht zu unterschätzendes Risiko darstellen (siehe Anhang C: 

Sicherheit on RFC). Dasselbe gilt für das Aufrufen von RFC über SOAP, das 

ebenfalls restriktiv konfiguriert werden sollte. 



Allerdings wird im Security Guide selbst eine Einschränkung der 

Authorisationsprüfungen zu Gunsten der Performance empfohlen, was vom 

Standpunkt der Sicherheit in so allgemeiner Form nicht nachvollziehbar ist. 

Was in offiziellen Information von SAP selbst, also auch dem Security guide 

fehlt, ist das restriktive Aktivieren von über HTTP erreichbare Dienste. Dies 

wird vom Verfasser dieser Diploarbeit als eine zentrale 

Konfigurationseinstellung betrachtet, da hier das große Risiko besteht, dass 

Funktionen, die nicht notwendig sind, aber Informationen preisgeben oder 

neue Sicherheitsprobleme darstellen, aufrufbar sind. Da häufig gar nicht 

bekannt ist, welche Dienste tatsächlich aktiv sind, ist auch die korrekte 

Rechtevergabe fraglich. Das grosszügige Aktivieren von Diensten wird hier 

über die SAP GUI leider sehr einfach gemacht, da ganze Bäume mit nur 

einem Klick aktiviert werden können, wie der 2. ‚Yes’ Schalter in Abbildung 

35: Einfache Diensteaktivierung im SAP GUI zeigt. 

Abbildung 35: Einfache Diensteaktivierung im SAP GUI 

Die Empfehlung beim Portal-Umfeld des SAP JAVA Stacks fällt weniger 

umfangreich aus, da sich die Konfigurationsmöglichkeiten hauptsächlich auf 

die Rechtevergabe beschränken 9 . 

Im Vorfeld sollte jedoch darauf geachtet werden, nur benötigte 

Komponenten zu installieren, um den zukünftigen Konfigurationsaufwand 

zu minimieren. 

Auch beim JAVA Stack sollte, wie beim ABAP-Stack beschrieben, die 

Rechtevergabe von Benutzern und Rollen etc. wohldurchdacht erfolgen. 

Das zentrale Element sind allerdings die sogenannten Security Zones, die 



die Rechte, die Benutzer auf Applikationen haben, definieren. Applikationen 

müssen schon beim Deploy diesen Security Zones zugeordnet werden, 

daher ist die Planung von erforderlichen Security Zones eine der 

wichtigsten Arbeiten bei der Konfiguration eines SAP Systems mit JAVA 

Stack. Die Rechte der Benutzer, Rollen etc. werden dann ebenfalls diesen 

Security Zones zugeordnet, wodurch ein Sicherheitskonzept entsteht, in 

dem Applikationen im Idealfall nur für die Benutzer aufrufbar sind, die 

damit arbeiten müssen. 

Schon ausgehend von der Basisinstallation können noch einige Dienste 

optimiert werden, für das es auch ein eigenes Dokument von SAP gibt 33 . 

Hierbei muss allerdings auch erwähnt werden, dass eine solche optimierte 

Konfiguration Einschränkungen der Funktionalität zur Folge haben können. 

Daher gibt es gleich mehrere weitere Empfehlungen von SAP, wie Probleme 

bei Anwendung des Dokumentes behoben werden können. 

Ergänzend gibt es noch rudimentäre möglichkeiten, den Webzugriff zu 

konfigurieren; die wesentlichen Einstellungen sind hier das Deaktivieren 

von Directory Listings und das mögliche Entfernen von Links zu nicht 

öffentlichen Applikationen. 

Zusammenfassend lässt sich sagen, dass die Konfigurationsmöglichkeiten 

bei SAP, die die Sicherheit in Hinblick auf die Webapplikationen erhöhen, 

kaum vorhanden sind. Im ABAP Umfeld beschränken sich die meißten 

Informationen auf Empfehlung für die Arbeit mit der SAP GUI. Das 

Webumfeld, in das SAP immer mehr integriert wird, wird kaum oder gar 

nicht behandelt. 

Der Größte Anteil der Konfigurationsmöglichkeiten wird von Benutzer und 

Rechtemanagement bestimmt, das auch tatsächlich einen gewichtigen 

Anteil an einem so komplexen und von vielen Benutzern verwendetem 

System darstellt 34 . 

Programmieransätze 

Bei den Empfehlungen zur sicheren Programmierung gibt es große 

Unterschiede zu Empfehlungen für klassische Webapplikationen. Viele der 

Funktionen, die bei klassischen Webapplikationen erst implementiert 

33 How To... Secure Permissions for Initial Content in SAP Enterprise Portal 

34 Angemerkt sei hier nochmals die Komplexität, die sich durch alle Bereiche bei der Untersuchung 

oder Administration von SAP Systemen bemerkbar macht. Eine von SAP veröffentlichte Liste mit den 

von SAP verwendeten Ports erstreckt sich schon alleine über 14-Seiten, die die von den Systemen 

verwendeten Ports beschreibt und die sich über den beinahe gesamten Portbereich verteilen und 

gegenseitig überlagern. 



werden müssen, werden schon von dem SAP System bereitgestellt oder 

teilweise bereitgestellt. Gleichzeitig werden die von SAP bereitgestellten 

Programme, die bei Unternehmen angepasst werden, nicht vollständig 

verstanden, was ein zusätzliches Risiko darstellt. Dennoch können einige 

der Empfehlungen, wie sie bei klassischen Webapplikationen gelten, auch 

bei SAP verwendet werden, teilweise haben sie veränderter Form 

Gültigkeit. In Anhang B: Konfigurationsempfehlungen und 

Programmierrichtlinien ist eine Liste der Empfehlungen aufgeführt, wie sich 

im Laufe dieser Diplomarbeit erarbeitet werden konnte. 

Einsatz spezieller Sicherheitsprodukte 

Die exemplarische Absicherung von Webapplikationen auf Basis von SAP 

erfolgte mit denselben Webapplikationsfirewalls, die auch zur Absicherung 

der klassischen Webapplikation verwendet wurden. 

Die Konfiguration beider Webapplikationsfirewalls für Webapplikationen, die 

auf dem SAP ABAP Stack aufsetzen, konnte durch den Lernmodus sehr 

einfach erfolgen und benötigte nur sehr wenig manuelle Nacharbeit. 

Ein Grund hierfür ist, dass keine Veränderung von Clientparametern in den 

gesicherten ABAP-Applikationen stattfinden. Webapplikationen des SAP 

Systems mit ABAP Stack übertragen unter Umständen einige zusätzliche 

Informationen, wie z.B. die benutzte Sprache, in innerhalb URL. Diese 

Parameter sollte fest als Base64 String in die Regeln für den URL-Zugriff 

eingetragen werden und muss daher selbstverständlich für alle verwendete 

Parameter, die unterschiedlich sein können, z.B. verschiedene Sprachen 

unterschiedlicher Mitarbeiter, extra erfasst werden. 

Die NetContinuum hat bereits viele häufig verwendete Parameter 

hinterlegt, darunter auch Session Identifiers. Fälschlicherweise wird der 

Base64 String mit diesen Clientparametern von der Netcontinuum als 

Session Identifier betrachtet. Die Übertragung des Session Identifiers ist 

bei Webapplikationen von SAP mit ABAP Stack zwar in derselben Form 

möglich, wurde in der vorliegenden Applikation aber nicht verwendet. 

Durch die Kenntnis von bei SAP immer verfügbaren Parametern, die 

besondere Sicherheitsrelevanz besitzen, kann eine Absicherung dieser 

Sicherheitsprobleme erfolgen. Hier ist der Parameter sap-client 

hervorzuheben, dessen Absicherung unbedingt mit allen 

Webapplikationsfirewalls möglich sein muss und mit den hier getesteten 

Webapplikationsfirewalls auch möglich war. 



Dies war allerdings nicht durch lernen möglich. Dieser Parameter muss 

manuell auf einen festen Wert festlegt werden. 

Bei den äußerst wenigen Installationen von Webapplikationsfirewalls, die 

bereits zur Absicherung von SAP eingerichtet wurden, sind notwendige 

Einstellungen wie dieser Parameter bisher nicht berücksichtigt worden. 

Auch bei Portalapplikationen, also Webapplikationen auf Basis von SAP mit 

JAVA Stack, funktionierte der Lernmodus bei beiden Produkten 

überaschend gut. Dies enstprach nicht der Erwartung des Verfassers, da 

vor allem die Komplexität des SAP-Portals mit den dynamischen URLs 

typischerweise mehr Probleme bei der Definition der Regeln erwarten ließ. 

Dass eine Portalapplikation dennoch so gut abzusichern war, ließ sich auf 

mehrere Faktoren zurückführen. 

Die Portalapplikation muss gut programmiert sein und somit in 

ihrem Verhalten eindeutig und vorhersagbar 

Es dürfen nur wenig, im Idealfall keine Abhängigkeiten von anderen 

Komponenten bestehen 

Das Programm muss trotz Komplexität der Möglichkeiten in sich 

einfach sein 

Es sollte keine Nutzung von Parametern in der URL wie z.B. 

/prtmode/x innerhalb des Applikationsverlaufes stattfinden oder sich 

auf möglichst wenige solche Parameter beschränken 

Ein Ausschnitt einer typischen dynamische URL, wie sie SAP verwendet wird 

ist in Abbildung 36: SAP Portal-URL dargestellt. 

Abbildung 36: SAP Portal-URL 

Obwohl die Komplexität der Portalanwendungen überaschend wenig 

Probleme bereitet, muss bei der Konfiguration von Webapplikationsfirewalls 

dennoch auf einige Besonderheiten geachtet werden, die bei 

Webapplikationen auf Basis von SAP mit JAVA Stack häufig zu sehen sein 

werden. 

Das Regelwerk der Webapplikationsfirewalls, die in einem Lernmodus 

vorkonfiguriert werden, kann sehr schnell sehr unübersichtlich und damit 

unwartbar werden. Nachfolgend in Abbildung 37: Gelerntes Regelwerk für 

das SAP Portal sind die Regeln für den URL-Zugriff dargestellt, wie sie von 

Citrix im Verlauf der Konfiguration einer Portalapplikation gelernt wurden. 



Abbildung 37: Gelerntes Regelwerk für das SAP Portal 

Die Regeln, die bei Citrix aus Regular Expressions bestehen, sind schon für 

wenige Seiten sehr zahlreich und können bei großen Applikationen schnell 

nur noch schwer zu warten werden. Daher müssen, wie schon bei der 

klassischen Webapplikation gesehen, Regeln verallgemeinert werden. Bei 

Portalapplikationen führt dies aber mitunter *-Regeln (Vgl. Abbildung 38: 

Verallgemeinertes Regelwerk für das SAP Portal), die in jedem Fall zu 

vermeiden sind. 

Abbildung 38: Verallgemeinertes Regelwerk für das SAP Portal 

Auch bei der Netcontinuum musste das dynamische Regelwerk manuell 

angepasst werden. Dies Beschränkte sich allerdings auf die Deaktivierung 

einer speziellen Prüfung von Netcontinuum, die die Verwendung von Tilden 

in der URL zwar nicht verbietet, aber standardmäßig einen Eintrag über 

dessen Auftreten in das Logfile schreibt. Da bei Portalapplikationen alle 



Webdynpro Applikationen diese Tilde im Pfad aufweisen, würde das Logfile 

so schnell von diesen Einträgen überfüllt werden, wie es in Abbildung 39: 

Gleichartige Fehlermeldungen im Logfile geschehen ist. 

Abbildung 39: Gleichartige Fehlermeldungen im Logfile 

Insgesamt war die Absicherung der Webapplikationen auf Basis von SAP 

mit JAVA Stack mit der Netcontinuum wesentlich einfacher und daher mit 

potentiell höherem Schutzlevel. Dennoch kann hier das Fazit gezogen 

werden, dass die Absicherung von Webapplikationen auf Basis von SAP 

auch mit sehr unterschiedlichen Webapplikationsfirewalls möglich ist und 

damit einen gangbaren Weg darstellt. 

4.5 Aufwand und erzielbare Ergebnisse bei der 

Absicherung 

Die sichere Konfiguration bei Webapplikationen ist mit vertretbarem 

Aufwand möglich und wird auch durchgeführt. Im gegensatz hierzu ist bei 

SAP ein großer Aufwand mit der Konfiguration verbunden. Gründe sind vor 

Allem die Größe und Komplexität des Systems und die damit verbundene 

Rechtevergabe, auf die die Sicherheit von SAP basiert. Da bei SAP 



außerdem die Funktionalität im Vordergrund steht, ist das großzügige 

Aktivieren von Diensten verlockend, gerade wenn während der Installation 

des Systems nur begrenzt Zeit zur Verfügung steht und eine sichere 

Konfiguration der Funktionalität im Wege steht (Abbildung 40: 

Diensteabhängigkeit bei SAP). 

Abbildung 40: Diensteabhängigkeit bei SAP 

Die Möglichkeiten außerhalb der Benutzer- und Rechtekonfiguration sind 

bei SAP im Gegensatz zu klassischen Webapplikationen beschränkt und 

lassen so kaum Möglichkeiten zu einer erhöhten Sicherheit durch geänderte 

Konfigurationseinstellungen zu. 

Dennoch ist das Schutzlevel bzw. die Resistenz gegenüber 

Webapplikationsangriffen bei Webapplikationen auf Basis von SAP 

grundsätzlich höher als bei klassischen Webapplikationen, aber nicht alleine 

ausreichend. 

Eine sichere Programmierung ist sowohl bei klassischen Webapplikationen 

als auch bei Webapplikationen auf Basis von SAP wichtig. Bei einer 

manuellen Untersuchung von ABAP konnte, wie auch durch eine Web- und 

Literaturrecherche, kein generischer Angriff wie Command Injection 

gefunden werden, und auch ein Quellcodeaudit von JAVA Programmen 

zeigte keine Schwachstellen. Dennoch ist auch hier Fachkenntnis und 

Sicherheitsbewusstsein wichtig, da z.B. beim APAB Stack Bausteine für 

einen direkten Datenbankzugriff verfügbar sind und Gespräche des 

Verfassers mit SAP-Beratern gezeigt haben, dass diese aus 

Performancegründen auch gerne eingesetzt werden. Da aber gerade die 

Verwendung der richtigen Bausteine für den bei SAP gegebenen Schutz 

gegen SQL Injection sorgt, ist so ein Schutz vor SQL-Injection nicht 



garantiert. Im übrigen kann die Sprache ABAP als resistenter gegenüber 

Angriffen bezeichnet werden, da für ABAP, wie erwähnt, keine generischen 

Angriffe bekannt sind oder gefunden wurden. 

Bei der Absicherung der Webapplikationen durch Sicherheitsprodukte zeigt 

sich, dass diese auf klassische Webapplikaiton zugeschnitten sind. Es gibt 

bei SAP, sowohl beim ABAP Stack als auch beim JAVA Stack kleinere 

Hindernisse bei der Konfiguration, die bei klassischen Webapplikationen 

selten auftreten. Die Funktionalität ist sowohl für klassische 

Webapplikationen als auch für Webapplikationen auf Basis von SAP 

herstellbar, lediglich der zu betreibende Aufwand ist gegenwärtig für SAP 

basierte Webapplikationen höher. 


Aus konzeptioneller Sicht sind dich Sicherheitsarchitekturen zur 

Absicherung von klassischen Webapplikationen und Webapplikationen auf 

Basis von SAP recht ähnlich. Bei klassischen Webapplikationen hat man 

zunehmend die Schutzbedürftigkeit gerade gegenüber 

Webapplikationsangriffen erkannt und so erfahren beispielsweise 

Webapplikationsfirewalls gerade zum Zeitpunkt der Erstellung dieser 

Diplomarbeit einen beginnenden Boom. Eine Übertragung des effektiven 

Webapplikationsschutzes auf Webapplikationen auf Basis von SAP ist 

dagegen noch überwiegend unbekannt. Wie in diesem Kapitel beschrieben 

kann die von SAP empfohlene Schutzarchitektur dies nicht leisten, was zu 

der Ersetzung des von SAP empfohlenen Dispatchers durch 

Weapplikationsfirewalls in dieser Diplomarbeit führte. 

Bei der Konfiguration setzt sich dieser Eindruck fort. So finden sich bei 

klassischen Webapplikationen, wie in dieser Diplomarbeit anhand Apache 

und PHP, zahlreiche Stellschrauben, die zusätzliche Funktionen bieten oder 

deren Deaktivierung zu einer erhöhten Sicherheit führt. Bei SAP wird die 

Sicherheit hauptsächlich durch Rechtevergabe definiert und so sind nur 

wenige Einstellungen, die die zusätzlichen Funktionen zugunsten einer 

erhöhten Sicherheit verändern können verfügbar mit Ausnahme einer sehr 

komplexen Benutzerverwaltung. 

Auch wenn die Motivation und Grundsätze einer sicheren Programmierung 

generisch anwendbar sind, zeigen sich durch die grundsätzlichen 

Unterschiede zwischen klassischer Webapplikation und SAP System auch 

grundsätzliche Unterschiede bei den Programmierungsrichtlinien. 

Hauptursache hierfür ist die massive Benutzung von Bibliotheken bei SAP 



während es sich bei klassischen Webapplikationen um überwiegend von 

Grund auf selbst programmierte Applikationen handelt. Somit haben hat 

nur ein Teil der Programmierungsrichtlinien, wie sie bei klassischen 

Webapplikationen üblich sind Gültigkeit bei Webapplikationen auf Basis von 

SAP, andere sind nur eingeschränkt oder in veränderter Form anwendbar. 

Die in der Praxis auch zunehmend bedeutendere Absicherung durch 

Webapplikationsfirewalls ist sowohl bei klassischen Webapplikationen als 

auch bei Webapplikationen auf Basis von SAP möglich. Die beispielhafte 

Absicherung von Webapplikationen auf den SAP Systemen gelang sogar mit 

weniger Problemen als erwartet und ergab ebenso wie bei den klassischen 

Webapplikationen einen effektiven Schutz. Gleichzeitig war zu beobachten, 

dass die Webapplikationsfirewalls nicht spezifisch auf die Eigenheiten von 

SAP Systemen vorbereitet sind, was z.B. zu der oben erwähnten 

Überfüllung der Logfiles mit Einträgen über die völlig normale Tilde im URL 

Pfad fürhte, wie sie bei klassischen Webapplikationen nur seltenst 

vorkommt. 

Insgesamt ist die Absicherung von Webapplikationen auf Basis von SAP 

anhand der in dieser Diplomarbeit gesetzten Rahmenbedingungen mit 

einem erhöhten Aufwand möglich wie es auch für klassische 

Webapplikationen möglich ist, trotz der teilweisen deutlichen Unterschiede 

bei den Möglichkeiten der Konfiguration und Programmierung. 



5 Zusammenfassung der Ergebnisse und 

Ausblick 

Im Folgenden sind die Ergebnisse dieser Diplomarbeit nochmals kurz 

zusammengefasst und es wird versucht, diese in einen größeren 

Zusammenhang zu stellen. 

Als zweiten Teil wird außerdem versucht, eine Perspektive für die 

zukünftige Entwicklung dieses Themas zu verfassen und hierbei auf Punkte 

einzugehen, den in Zukunft erhöhte Aufmerksamkeit geschenkt werden 

sollte und welche Arbeiten mit dieser Diplomarbeit abgeschlossen sind oder 

noch weitere Forschungstätigkeit benötigen. 

5.1 Zusammenfassung der Ergebnisse 

Diese DA beschäftigte sich vor Allem mit technischen Sicherheitsaspekten 

der Sicherheit von klassischen Webapplikationen und SAP, wie sie in 

Hinblick auf die reale Durchführung von Audits und Absicherungen relevant 

sein werden. 

In Kapitel 2.2 wurden darüber hinausgehende Aspekte aufgezeigt, die in 

einer Abschätzung der Sicherheit von SAP ebenfalls eine Rolle spielen und 

die in Kapitel 3 und 4 untersuchten, technischen Aspekte beeinflussen 

können. Gerade diese weitergehenden Aspekte zeigen, dass die 

umfassende Integration von Sicherheitsgedanken in personellen und 

organisatorischen Bereichen im SAP Umfeld weniger ausgeprägt ist als bei 

klassischen Webapplikationen. Dies kann dazu führen, dass die effektive 

Sicherheit von SAP Systemen geringer ist, als sie vom technischen 

Standpunkt sein könnte. 

Bei den näher betrachteten technischen Aspekten zeigte sich dagegen, dass 

SAP grundsätzlich resistenter gegenüber Webapplikationsangriffen ist. 

Hierbei gibt allerdings große Unterschiede zwischen SAP auf ABAP oder 

JAVA Stack. Während es beim JAVA Stack selbst kaum generische 

Ansatzpunkte gibt, zeigt der ABAP Stack einige Verwundbarkeiten, die 

unabhängig von der konkreten Applikation immer bestehen und auch 

generell eine größere Anfälligkeit gegenüber Webapplikationsangriffen. 

Ergänzend lässt sich in diesem Punkt aber eine Verbesserung bei der 

neueren Version 700 gegenüber der älteren 640 erkennen. 



Bei der Absicherung von Webapplikationen auf Basis von SAP ergab sich 

zum einen, dass es gerade bei den Punkten sichere Programmierung und 

Konfiguration bei SAP weniger Möglichkeiten gibt, als sie von klassischen 

Webapplikationen bekannt sind. Die Absichrung mittels 

Webapplikationsfirewalls hingegen funktionierte überraschend gut, 

allerdings mit erhöhtem Konfigurationsaufwand. Dies führt der Verfasser 

darauf zurück, dass konkrete Webapplikationen auf Basis von SAP in den 

getesteten Fällen nur sehr wenig gebrauch von der grundsätzlich 

gegebenen Flexibilität der SAP Architektur, im Besonderen des URL- 

Aufbaus, machen. Auch hier zeigt sich, dass das im Rahmen dieser 

Diplomarbeit gewonnene Fachwissen notwendig ist um beispielsweise 

spezielle Eigenschaften wie global verfügbare Parameter zu berücksichtigen 

oder bei der Nachbearbeitung der bestehenden oder dynamischen, 

gelernten Regeln. 

5.2 Ausblick 

Wie zuvor erwähnt stellt diese Diplomarbeit die Basis für zukünftige Audits 

oder Maßnahmen zur Absicherung von Webapplikationen auf Basis von SAP 

dar. Mit Hilfe der hier gewonnen Erkenntnisse ist es möglich, sowohl ein 

qualifiziertes Audit durchzuführen, als auch eine Absicherung von SAP 

Systemen und Webapplikationen auf Basis von SAP mit Hilfe der immer 

stärker nachgefragen Webapplikationsfirewalls. 

Es blieben mit Ende dieser Diplomarbeit auch Themen, die weiterer 

Erfahrung bedürfen, insbesondere sind die Möglichkeiten, das Verhalten 

von Webapplikationen auf JAVA Stack mit Hilfe von URL-Parametern zu 

beeinflussen nicht abschließend geklärt. 

Der wichtigste Punkt wird aber sein, Erfahrungen sowohl mit dem 

Auditieren von Webapplikationen auf Basis von SAP also auch deren 

Absicherung zu sammeln. Nachdem mit dieser Diplomarbeit eine Basis für 

eine solche Arbeit gegeben ist, werden auch mit kommenden, real 

durchgeführten Arbeiten die Erfahrung zunehmen und somit auch neue 

Erkenntnisse gewonnen werden, die so zukzessive aufgebaut werden 

können. 

Eine steigende Nachfrage sowohl nach Audits als auch nach Absicherung ist 

bereits gegeben und wird sich voraussichtlich noch verstärken, da 

Gespräche mit Verantwortlichen ein steigendes Bewusstsein für die 

Problematik der Webapplikationen auf Basis von SAP gezeigt haben und der 



Frage nach der Sicherheit von Webapplikationen auf Basis von SAP häufig 

noch mittels Security by Obscurity begenet wurde. Dies kann nun durch 

konkrete und qualifiziertere Arbeiten adressiert werden als es bislang 

möglich war und somit ein verlässlicheres Sicherheitsniveau erreicht 

werden. 



6 Literaturverzeichnis 

1 Enterprise Ressource Planning, 

http://de.wikipedia.org/wiki/Enterprise_Resource_Planning 

2 What is ERP?, http://www.tech-faq.com/erp.shtml 

3 Frank Niemann, 2007: Im Markt für ERP-, CRM- und SCM-Lösungen ist 

der Mittelstand Antreiber, in Computerwoche, 

http://www.computerwoche.de/top_100/software/546025/ 

4 Architektur des SAP Web AS, in SAP-Bibliothek, 

http://help.sap.com/saphelp_nw04/helpdata/de/84/54953fc405330ee100 

00000a114084/content.htm 

5 Glossar und Begriffsdefinitionen, in Grundschutzhandbuch Bundesamt für 

Sicherheit in der Informationstechnik, Baustein 04, 

http://www.bsi.bund.de/gshb/deutsch/baust/04.htm 

6 Leitfaden IT Sicherheit – IT-Grundschutz kompakt, Bundesamt für 

Sicherheit in der Informationstechnik, 

http://www.bsi.de/gshb/Leitfaden/GS-Leitfaden.pdf 

7 Markus Herren, Informationssicherheit – eine Frage der Kultur, in 

http://www.conpro.ch/de/themen/information-security.aspx 

8 InfoSec Acceptable Use Policy, in 

http://www.sans.org/resources/policies/Acceptable_Use_Policy.pdf 

9 Web Application Security – der blinde Fleck der Internetsicherheit, in 

TecChannel, 

http://www.tecchannel.de/sicherheit/grundlagen/474056/index2.html 

10 Mario Linkies, Frank Off, Enterprise Portal, SAP Security and 

Authorizations, Galileo Press 

11 Frederic Heinemann, Christian Rau, SAP Web Application Server, Galileo 

Press 

12 Jört Altmeier, SAP-Security – Roadmap zur Umsetzung, in Security 

Manager, 

http://www.securitymanager.de/magazin/artikel_988_sapsecurity_road 

map_zu_umsetzung.html 

13 Khalid Kark, The cost of data breaches: Looking at the hard numbers, in 

http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1248216,00 

.html?track=NL-430&ad=581112USCA&asrc=EM_NLT_1164363&uid=41 

99563 

14 Andy Müller-Maguhn – Vortrag “Die Illusion IT-Sicherheit: Strategien und 

Erfahrungen“ 

15 XSS (Cross Site Scripting) Cheat Sheet, in http://ha.ckers.org/xss.html 

16 News Meldung, in http://www.heise.de/newsticker/meldung/100976 

17 Threat Classification, OS Commanding, in 

http://www.webappsec.org/projects/threat/classes/os_commanding.sht 

ml 

18 Web Application Security Statistics, in 

http://www.webappsec.org/projects/statistics/ 

20 Hypertext Transfer Protocol – HTTP/1.1, in 

http://www.w3.org/Protocols/rfc2616/rfc2616.html 



23 Integration einer Web-Anwendung mit Web-, Applikations- und 

Datenbank-Server in ein Sicherheitsgatewayin Grundschutzhandbuch 

Bundesamt in der Informationstechnik, , Massnahme 5.119, 

http://www.bsi.bund.de/gshb/deutsch/m/m05119.htm 

24 Using Multiple Network Zones, in SAP Library, 

http://help.sap.com/saphelp_nw04s/helpdata/en/8d/f3da779bd02c4fa54 

fda5d6944f2d6/frameset.htm 

25 The Web Application Firewall Forecast: 2007 to 2010, in 

http://www.forrester.com/Research/Document/Excerpt/0,7211,41780,00 

.html 

26 Web Application Firewall Evaluation Criteria, in 

http://www.webappsec.org/projects/wafec/v1/wasc-wafec-v1.0.html 

31 ABAP Security Guide, Secure Permissions for Initial Content in SAP 

32 SAP NetWeaver Server Security Guide, 

http://help.sap.com/saphelp_nw70/helpdata/en/8c/2ec59131d7f84ea51 

4a67d628925a9/content.htm 

33 SAP HowTo Guide: How To... Secure Permissions for Initial Content in 

SAP Enterprise Portal 

35 Glossar, in SAP-Bibliothek, 

http://help.sap.com/saphelp_46c/helpdata/de/35/2cd77bd7705394e100 

00009b387c12/frameset.htm 

36 Security Audits, in http://www.bitpipe.com/tlist/Security-Audits.html 

37 RFC 3548 – The Base16, Base32, and Base64 Data Encodings, in 

http://www.faqs.org/rfcs/rfc3548.html 

38 Web Application Scanner, in SecureNet, 

http://www.securenet.de/front_content.php?idcatart=93 

39 ERP, in http://lexikon.martinvogel.de/erp.html 

40 Glossary, in http://phoenix5.org/glossary/false_positive.html 

41 Glossary in SAP Info, 

http://www.sap.info/public/DE/de/glossary/de/glossaryletter/Word- 

38053d4a86b283db5_glossary/I 

42 Die SAP NetWeaver Komponenten, in 

http://www.oio.de/sap-netweaver-components.htm 

43 proof of conce, in BusinessDictionary, 

http://www.businessdictionary.com/definition/proof-of-concept.html 

44 ABAP Workbench, in SAP-Bibliothek, 

http://help.sap.com/saphelp_46c/helpdata/de/35/26b273afab52b9e100 

00009b38f974/content.htm 

45 Web Security Glossary, in http://www.webappsec.org/projects/glossary/ 



7 Glossar 

ABAP: Advanced Business Application Programming. 

Programmiersprache, die SAP zur Entwicklung von 

Anwendungsprogrammen entwickelt hat 35 

Audit: Ein (Sicherheits)audit ist eine systematische Evaluation der 

Sicherheit von IT-Systemen in einem Unternehmen durch Messen, wie gut 

es den vorgegebenen Kriterien entspricht. 36 

Angriff: Ein Angriff ist eine vorsätzliche Form der Gefährdung, nämlich eine 

unerwünschte oder unberechtigte Handlung mit dem Ziel, sich Vorteile zu 

verschaffen bzw. einen Dritten zu schädigen. Angreifer können auch im 

Auftrag von Dritten handeln, die sich Vorteile verschaffen wollen. 37 

Authentisierung: Authentisierung bezeichnet den Nachweises eines 

Kommunikationspartners, dass er tatsächlich derjenige ist, der er vorgibt 

zu sein. Dies kann unter Anderem durch Passwort-Eingabe, Chipkarte oder 

Biometrie erfolgen. 37 

Authentizität: Gewährleistung, dass ein Kommunikationspartner 

tatsächlich derjenige ist, der er vorgibt zu sein. Bei authentischen 

Informationen ist sichergestellt, dass sie von der angegebenen Quelle 

erstellt wurden. 37 

Authorisierung: Bei einer Autorisierung wird geprüft, ob eine Person, IT- 

Komponente oder Anwendung zur Durchführung einer bestimmten Aktion 

berechtigt ist. 37 

Base64: Encodierungsalgorithmus für beliebige Daten unter Verwendung 

des US-ASCII Zeichensatzes 5 

Crawl: english: krabbeln; Bezeichnet die Indizierung einer Webseite, 

wobei allen Links gefolgt wird und Buttons aktiviert werden. So erhält das 

35 

http://help.sap.com/saphelp_46c/helpdata/de/35/2cd77bd7705394e10000009b387c12/frameset.ht 

m 

36 http://www.bitpipe.com/tlist/Security-Audits.html 



Programm Wissen über den Aufbau der Site, die Funktionsweise von 

Dialogschritten und den Inhalte von Formular-Seiten. 38 

Deployment: Das gezielte Übertragen von Software and alle Zielrechner 

bzw. all an einem betrieblichen Prozess beteiligten Rechner so dass all mit 

derselben Software arbeiten. 

ERP: Enterprise Resource Planning - englisch: Planung von 

Unternehmensressourcen; ERP bezeichnet im allgemeinen 

Softwarelösungen, die den betriebswirtschaftlichen Ablauf steuern und 

auswerten (Controlling). 39 

False Positive: Ein false Positive liegt vor, wenn ein Test fälschlicherweise 

ein positives Ergenis zurückliefert. 40 

Gefahr (Bedrohung) : Eine Bedrohung ist ganz allgemein ein Umstand 

oder Ereignis, durch den oder das ein Schaden entstehen kann. 37 

Gefährdung: Eine Gefährdung ist eine Bedrohung, die konkret auf ein 

Objekt über eine Schwachstelle einwirkt. Eine Bedrohung wird somit erst 

durch eine vorhandene Schwachstelle zur Gefährdung für ein Objekt. 37 

ITIL: IT Infrastructure Library. De-facto-Standard im Bereich Service 

Management und beinhaltet eine umfassende und öffentlich verfügbare 

fachliche Dokumentation zur Planung, Erbringung und Unterstützung von 

IT-Serviceleistungen 12 . 

IT-Sicherheit: siehe Kapitel 2.2.1 

ITS: 

Internet Transaction Server: Schnittstelle zwischen dem SAP 

System und dem Internet oder Intranet 41 

Klassische Webapplikation: Bezeichnet in dieser Diplomarbeit 

Webapplikationen auf Basis von bekannten und weit verbreiteten 

Technologien und Produkten wie Apache und PHP oder Java. 

38 http://www.securenet.de/front_content.php?idcatart=93 

39 http://lexikon.martinvogel.de/erp.html 

40 http://phoenix5.org/glossary/false_positive.html 

41 http://www.sap.info/public/DE/de/glossary/de/glossaryletter/Word- 

38053d4a86b283db5_glossary/I 



Mandant: Eine für sich handelsrechtlich, organisatorisch und 

datentechnisch abgeschlossene Einheit innerhalb eines SAP-Systems mit 

getrennten Stammsätzen und einem eigenständigen Satz von Tabellen. 35 

SAP Portal: Das SAP Enterprise Portal hat die Aufgabe, einen einheitlich 

gestalteten und dem Unternehmen angepassten Zugang für alle im 

Unternehmen vorhandenen Informationen zu ermöglichen. Das Portal ist 

ein Bestandteil des SAP NetWeavers. 42 

Proof of Concept: Ein Proof of Concept ist ein Beweis, der zeigt, dass eine 

Idee, Erfindung, Technologie – oder in diesem Fall Angriff – anwendbar 

ist. 43 

SAP: 

Systeme, Anwendungen und Produkte in der Datenberarbeitung 

Transaktion: Logisch abgeschlossener Vorgang im R/3-System. Aus 

Benutzersicht stellt es eine Einheit dar, aus Programmierungssicht ist es ein 

komplexes Objekt bzw. Vorgang. 44 

Webapplikationsscanner: Ein automatiertes Sicherheitsprogramm, das 

Webapplikationen nach Verwundbarkeiten durchsucht. 45 

42 http://www.oio.de/sap-netweaver-components.htm 

43 http://www.businessdictionary.com/definition/proof-of-concept.html 

44 

http://help.sap.com/saphelp_46c/helpdata/de/35/26b273afab52b9e10000009b38f974/content.htm 

45 http://www.webappsec.org/projects/glossary/ 



8 Anhänge 

8.1 Anhang A: Beschreibung der Komponenten 

des SAP NetWeavers 

People integration: Zeigt Personen nur die richtigen und wesentlichen 

Informationen, die aus verschiedenen Quellen gewonnen werden können, 

wie Data Warehouse, Web, Desktops etc. und bietet ausserdem die 

Möglichkeit, diese Daten unter einer einheitlichen Oberfläche darzustellen. 

Zentrale Funktionen sind das Portal mit personalisiertem und 

rollenbasierten Zugriff, Collaboration mit Groupware und Teamräumen etc. 

und Multi Channel Access, der den Zugriff über die verschiedensten 

Endgeräte ermöglicht. Das Portal ist inzwischen für einige Anwendungen 

notwendig, wie z.B. Guided Procedures oder Visual Composer und soll auch 

in Zukunft als zentraler Einstiegspunkt für alle SAP Applikationen dienen. 

Information Integration: Führt alle Daten eines Unternehmens 

zusammen, gewährleistet deren Integrität und sogt so auch für eine 

Harmonisierung der Datenbestände und deren garantierten Zugriff 

unabhängig von ihrm Speicherort. 

Die Zentralen Funktionen bei der Information Integration sind im SAP 

Umfeld häufig benannte Funktionen. Zum einen die Business Intelligence, 

die für die Informationsaufbereitung sorgt und so Entscheidungen 

erleichtert und ausserdem die Erstellung von Berichten unterstützt. Des 

weiteren gehört zur Information Integration das Knowledge Management, 

die den Zugriff auf verteilte Informationen, die Suche darin, Klassifikation, 

Versionierung etc. übernimmt. Als letzter Baustein der Information 

Integration steht das Master Data Management, das für die Datenhaltung 

und deren Verfügbarkeit sorgt und üblicherweise die zentrale Datenhaltung 

der SAP Landschaft darstellt. Bei Master Data Management handelt es sich 

um ein zugekauftes Produkt, das nicht vollständig in die SAP Architektur 

integriert ist. Da es sich in nahezu allen Bereichen von den typischen SAP 

Produkten unterscheidet wird bei Überprüfungen nicht betrachtet. 

Process integration: Sorgt für die Integration von heterogenen 

Komponenten in einem Geschäftsprozess. Kernpunkt ist SAP XI, das den 

XML basierten Austausch von Informationen zwischen SAP Komponenten 



und Komponenten von Drittherstellern oder Nicht-SAP-Systemen 

ermöglicht. 

Schlüsselbereiche hier ist der Integration Broker, der für die 

Kommunikation unterschiedlichster Systeme mittels XML/SOAP sorgt, zum 

anderen das Business Process Management, das Geschäftsproze, 

Intergrationsprozesse und Workflow steuert. 

Application Plattform: Unterstützung von sowohl ABAP als auch dem 

neueren Java-Stack ein einer einheitlichen Umgebung und kann über eine 

flexible Gesamtarchitektur auf unterschiedliche Bedürfnisse angepasst 

werden. 

Über allen Bereichen bietet die NetWeaver Architektur ein Life Cycle 

Management an, das Werkzeuge und Möglichkeiten über das Design, 

Entwicklung, Test und Betrieb der Lösungen beinhaltet. 

Mittels des Composite Application Framework stellt Werkzeuge, 

Methoden und Prozesse bereit um Applikation zu entwicklen, deren Teile 

aus verschiedenen Bereichen kommen können. 



8.2 Anhang B: Konfigurationsempfehlungen und 

Programmierrichtlinien 

Die in diesem Kapitel beschriebenen Empfehlungen basieren auf internen 

Unterlagen und Erfahrungen des Verfassers 

Konfigurationseinstellungen bei Webserver Apache 

Directory-Direktive: Die Option „Indexes“ sollte vermieden werden, 

da sonst bei Fehlen einer Index-Datei ein Directory-Listing mit 

eventuell sensiblen Informationen angezeigt wird. Die Option 

„FollowSymLinks“ erlaubt unter Umständen den Zugriff auf sensible 

Informationen, sollten diese unter dem Webroot Verzeichnis auf 

Dateisystemebene verlinkt sein. 

UserDir: Die „UserDir“ Option sollte deaktiviert werden, da es 

möglich ist, hierüber gültige Systembenutzer in Erfahrung zu 

bringen. 

ServerTokens und ServerSignature: Beide Optionen geben die 

Version des Webservers preis und sollten auf „Prod“ bzw. „Off“ 

gestellt werden. 

Standardverzeichnisse: Der Zugang zu Standardverzeichnissen 

sollte unterbunden werden, sofern diese nicht explizit notwendig 

sind 

Keine Verwendung von Standardfehlerseiten, da diese unter 

Umständen sensible Informationen preisgeben können 

HTTP-Methoden sollten eingeschränkt werden, üblicherweise 

genügen GET und POST 

Zugriff auf den Webserver sollte von Systemseite nur den 

Administratoren möglich sein 

Nicht öffentliche Bereiche müssen geschützt werden 

Konfiurationseinstellungen bei PHP 

Aktivierung der Härtungsoptionen „safe_mode“ oder „open_basedir“ 

Ausgabe der PHP-Version: Sollte durch die Einstellung expose_php= 

Off deaktiviert werden. 

Register_globals: Sollte deaktiviert werden um einige der 

einfachsten und bekanntesten Angriffe auf PHP erlaubt, wie das 

setzen von internen Variablenwerten 



Programmierrichtlinien für klassische Webapplikationen 

Bibliotheksfunktionen sollten der Erstellung eigener Funktionen 

bevorzugt werden, da eigene Funktionen häufiger Fehler aufweisen. 

Möglichst keine Shellaufrufe. Beispielsweise sollte php mail() anstatt 

sendmail Verwendung finden 

Bei HTTP Methoden ist POST dem GET vorzuziehen, so werden 

ebefalls keine sensiblen Daten im Serverlog erfasst 

Prüfung auf ungültige Zeichen: In URL-Parameter, HTTP GET und 

HTTP POST Parameter inklusive Hidden-Fields, Cookies, sowie 

anderen verarbeiteten Daten 

Bei Prüfung von Parametern, URLs etc. ist Whitelisting dem 

Blacklisting vorzuziehen 

Sonderzeichen müssen encodiert werden (escape), insbesondere 

die, die vom Browser interpretiert werden, z.B. sollte mit &lt, 

&gt encodiert werden 

Prüfung der Gültigkeit von Parametern nach Kontext, so wird u.a. 

verhindert dass, wie bei der cirobank, bei Eingabe einer anderen 

Benutzer-ID die Applikation vom Benutzer- in den 

Administrationskontext wechselt 

Bei Navigation über mehrere Seiten müssen alle Parameter bei 

jedem Schritt geprüft werden 

Bei Implementierung einer Uploadfunktionalität müssen Dateitypen 

beschränkt werden. Außerdem muss die Prüfung des Dateityps 

anhand des „Magic Bytes“ und nicht anhand der Dateiextension 

durchgeführt werden. Des Weiteren ist eine Ablage außerhalb des 

Serverroots zu empfehlen sofern die Dateien nicht mehr aufgerufen 

werden müssen. 

Authentifizierung z.B. mit Captchas um automatisierte Eingaben zu 

vermeiden 

Entfernung von Kommentaren aus dem Quelltext 

Entfernen von Backupdateien in einer Produktivumgebung 

Starke SessionID und begrenzte Gültigkeit der SessionID 

Bei Wechsel von Bereichen unterschiedlicher Authorisierung muss 

die SessionID geändert werden 

Sensible Informationen dürfen nicht auf dem Client gespeichert 

werden, ebenso dürfen sensible Aktionen wie eine Eingabeprüfung 

nicht auf Client ausführt werden 

Fehlerseiten dürfen keine Applikationslogik preisgeben 



Fehlerseiten dürfen keine Hinweise auf die verwendete Software 

oder auf Versionen geben 

Log und Konfigurationsdaten müssen sich außerhalb des Serverroots 

befinden 

SSL bevorzugt gegenüber Klartext einsetzen. Hierbei sollte auf eine 

starke Verschlüsselung geachtet werden, da sonst die Sicherheit von 

SSL ausgehebelt werden kann 

Verwendung von prepared Statements für SQL-Befehle 

Passwortpolicy bei SAP 

login/password_downwards_compatibility: Nicht im Security Guide 

enthalten, konfiguriert aber die Abwärtskompatibilität für Systeme < 

NetWeaver640 – hier sind nur 8 Grossbuchstaben für das Passwort 

signifikant 

login/fails_to_user_lock: Anzahl der falschen Passworteingaben, 

nach denen der Account deaktiviert wird. 

login/failed_user_auto_unlock: Zeitdauer, nach dem ein 

deaktivierter Account wieder aktiv wird, z.B. ein Tag 

login/min_password_lng: Minimale Länge des Passwortes 

login/min_password_letters: Minimale Anzahl der Buchstaben 

login/min_password_digits: Minimale Anzahl der Zahlen 

login/min_password_specials:Minimale Anzahl der Sonderzeichen 

login/min_password_lowercase: Minimale Anzahl der 

Kleinbuchstaben 

login/min_password_uppercase: Minimale Anzahl der 

Grossbuchstaben 

login/min_password_diff: Minimale Anzahl der Buchstaben, die sich 

vom alten Passwort unterscheiden müssen 

login/password_max_idle_productive: Zeitdauer, nach der ein 

unbenutzes Passwort verfällt 

login/password_max_idle_initial: Zeitdauer, nach der ein initiales 

Passwort verfällt 

login/password_expiration_time: Zeitdauer, die ein Passwort gültig 

ist 



Programmierrichtlinien für SAP 

Die empfohlene Benutzung von Bibliotheksfunktionen ist gerade bei 

SAP häufig der Fall, da viel Funktionalität schon bei SAP enthalten 

ist und im Wesentlichen Anpassungen vorgenommen werden. 

Nicht benötigte Funktionen in den Bausteinen, die angepasst oder 

benutzt werden, sollten deaktiviert werden 

Keine Bausteine erstellen oder verwenden, die einen direkten Zugriff 

auf das Betriebssystem oder die Datenbank erlauben 

Die Ein- bzw. Ausgabeprüfung sollte SAP übernehmen, leider ist 

diese wie gezeigt nicht vollständig, so dass entweder sichergestellt 

sein muss, dass eine andere Komponente wie eine 

Webapplikationsfirewall die Prüfung übernimmt, oder die Prüfungen 

von SAP ergänzt werden. Dies gilt auch für das Escapen von 

Sonderzeichen 

Bei Prüfung von Parametern, URLs etc. ist Whitelisting dem 

Blacklisting vorzuziehen 

Authorisierung, Authentifizierung sollte dem SAP-System überlassen 

werden 

Sensible Informationen sollten nicht auf dem Client gespeichert 

werden, sowie sensible Aktionen nicht auf dem Client ausgeführt 

werden. Anzumerken ist hier, dass bei Portalapplikationen sehr viel 

Clientaktivität stattfindet, aber eine Analyse dennoch keine 

Schwachstellen aufgedeckt hat und die von SAP gelieferte 

Clientseitigen Skripte somit als sicher eingestuft werden können. 

Fehlerseiten dürfen keine Applikationslogik preisgeben. Das SAP 

System selbst gibt standardmäßig immer noch Versionsangaben mit 

an, je nach Fehlermeldung auch detailliertere Informationen 

SSL bevorzugt gegenüber Klartext einsetzen. Hierbei sollte auf eine 

starke Verschlüsselung geachtet werden, da sonst die Sicherheit von 

SSL ausgehebelt werden kann 

Bei HTTP Methoden ist POST dem GET vorzuziehen, so werden 

ebenfalls keine sensiblen Daten in Logs erfasst 



8.3 Anhang C: Sicherheit on RFC 

Auch bei RFCs gibt es, wie bei den URLs im SAP-Webumfeld, sehr viele 

mögliche Dienste, die erreichbar sein können. Auch hier ist allerdings eine 

Auflistung möglich. Mit Hilfe dieser bekannten RFCs ist es nun möglich, ein 

C-Programm zu schreiben, mit dessen Hilfe die Verfügbarkeit der Dienste 

überprüft wird. Eine Brutefoce-Methode für alle möglichen Kombinationen 

ohne Liste ist nicht möglich, da die Namen der RFCs aus allen Buchstaben 

des Alphabets als auch die Zeichen „/“ und „_“ zur Verfügung bestehen 

können. Für eine Suche nach allen RFCs, deren Namen maximal 20 Zeichen 

besitzen müsste man also 28 20 = 87732524600823436081182539776 

Kombinationen testen. 

Von den standardmäßig verfügbaren RFCs, die ohne Anmeldung erreichbar 

sind, sind folgende erwähnenswert: 

sapinfo 

Zur Informationsgewinnung; die Rückgabe besteht aus folgenden 

Informationen: 

Tabelle1: Ausgabe sap_info 

SAP System Information 

----------------------------------------------- 

Destination 

sapn4s_N4S_01 

Host 

sapn4s 

System ID 

N4S 

Database 

N4S 

DB host 

sapn4s 

DB system 

ADABAS D 

SAP release 700 

SAP kernel release 700 

RFC Protokoll 011 

Characters 

4103 (UNICODE PCS=2) 

Integers 

LIT 

Floating P. 

IE3 

SAP machine id 390 

Timezone 

3600 (Daylight saving time) 



rfc_put_codepage 

Diese Funktion setzt die Codepage anhand von in bestimmten internen 

Tabellen vermerkten Index. Während die Ausführung dieser Funktion bei 

Kernelversion 640 (NW4) keine sinvollen Ergebnisse bringt, zeigt ein Blick 

in den ABAP-Quellcode dieser Funktion bei Kernelversion 700 (NW4s), dass 

sämtliche Codezeilen auskommentiert sind und mit dem Aufruf dieser 

Funktion somit keine Aktion verbunden ist. 

Das Problem in Version 640 ist der in der Funktion Parameter PATHNAME. 

Bei dieser Funktion ist ausser Rückmeldungen über Fehler keine Rückgabe 

vorgesehen. So führt ein Aufruf mit den Parametern 

FROMPAGE = 0400 

TOPAGE = 1152 

PATHNAME = %%%123 

in einem speziell hierfür geschriebenen C-Programms zu in Abbildung 1 zu 

sehenden Ausgabe: 

Abbildung 1: Ausgabe mit zufälligem Path-Parameter 

Die Funktion wurde also offensichtlich ohne Fehler ausgeführt. 

Ein Blick in /usr/sap/NW4/DVEBMGS00/work zeigt jedoch wie in Abbildung 

2 zu sehen: 

Abbildung 2: Auswirkung im Dateisystem 



Abbildung 3: Detailansicht neuer Datei 

Wie auf diesen Bildern zu erkennen ist, hat diese Funktion eine Datei 

angelegt, die den Namen PATHNAME des RFC-Parameters erhält. 

Die Detailansicht der Datei zeigt, dass sie etwa 1Kilobyte groß ist und unter 

dem SAP Systemaccount „nw4adm“ der Gruppe „sapsys“ angelegt wurde. 

Sofern bei dem SAP System nicht explizit der Audit log aktiviert wurde und 

auch hier die Protokollierung aller RFC-Aufrufe mitverfolgt wird, ist ein 

Aufruf dieser Funktion praktisch unsichtbar. So ist es möglich, mit einem 

automatisierten Aufruf dieser Funktion mit alterierenden PATHNAME-Strings 

die vorhandenen Inodes oder Festplattenplatz anonym zu füllen, und so die 

Funktionsfähigkeit des SAP-Systems einzuschränken oder es sogar 

unverfügbar zu machen. 

Die Funktion erlaubt es ebenfalls, selektiv Dateien zu überschreiben. 

Gezeigt hier anhand des Befehls „stopsap“, der für das korrekte 

herunterfahren des SAP-Systems verantwortlich ist. 

In Abbildung 4 ist die Datei „/usr/sap/NW4/SYS/exe/run/stopsap“ vor dem 

Aufruf des RFCs rfc_put_codepage 

Abbildung 4: Originales stopsap 

Ein Aufruf des RFCs mit PATHNAME = ../../SYS/exe/run/stopsap 

führt zu in Abbildung 5 zu sehenden Ausgabe bei den Dateidetails: 

Abbildung 5: Überschriebenes stopsap 

Der Inhalt 0x00 bis 0xFF der neuen Datei ist durch den Angreifer nicht 

beeinflussbar. 

Da die Datei mit der Berechtigung „nw4adm“ geschrieben wird, können 

beliebige Dateien, auf die SAP Schreibrechte hat, anonym überschrieben 

werden. Dazu gehören z.B. alle ausführbaren Dateien des SAP-Systems, 

Logdateien und die Konfiguration.

Sicherheit von SAP in Bezug auf neue Technologien

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?