Uberblick Websecurity - Albert-Ludwigs-Universität Freiburg

Angriffe auf die Internetprotokollfamilie und IP-Sicherheit 

Thema: Überblick Websecurity 

Jennifer Nist 

nistj@informatik.uni-freiburg.de 

Proseminar am Lehrstuhl für Kommunikationssystem 

Albert-Ludwigs-Universität Freiburg 

Zusammenfassung Die Sicherheit von Webanwendungen ist nicht einfach zu garantieren. 

Oftmals ist sie auch gar nicht, wenig oder mäßig vorhanden. Es folgt ein Überblick, wie einfach 

es Angreifer oft haben, die Schwachstellen verschiedener Webanwendungen auszunutzen, 

und welche Auswirkungen dies haben kann. 

1 Einleitung 

Der Grund für jede Sicherheitslücke sind menschliche Fehler. Sicherheitslücken werden oft zufällig 

entdeckt oder vorsätzlich gesucht und ausgenutzt. Einige wollen auf Sicherheitslücken aufmerksam 

machen, wie z.B. der deutsche Chaos Computer Club (CCC). Auf einen anonymen Hinweis hin 

überprüften sie 2011 die Webserver der Bundesfinanzagentur, welche online den Handel mit Staatsanleihen 

anbot. Dabei wurden gravierende Sicherheitslücken, von denen auch das Internet-Banking 

der Bundesfinanzagentur betroffen war, entdeckt. 

[1] 

2 Übersicht 

Im folgenden werden 4 der 10 häufigsten Sicherheitsrisiken für Webanwendungen erläutert. Diese 

wurden von der OWASP (The Open Web Application Security Project) zusammengestellt und 

bewertet. 

2.1 Unsichere direkte Objektreferenzen (Insecure Direct Object References) 

In Webanwendungen werden häufig Objektreferenzen verwendet. Dies sind Zeiger, beispielsweise 

eine URL, die auf Objekte, zum Beispiel auf Dateien, Verzeichnisse oder Datenbankeinträge, verweisen. 

Wenn diese Referenzen von einem Angreifer so manipulierbar sind, dass dieser unautorisiert 

auf Dateien und Inhalte zugreifen kann, so ist diese Objektreferenz unsicher. 

Beispiel 

Das Online-Interface einer Bank ist für jeden sichtbar. Registrierte Benutzer können, zusammen 

mit ihren Zugangsdaten, noch auf weitere Seiten, wie zum Beispiel Kontoübersicht, Kontobewegungen 

oder Aufträge zugreifen. 

Die URL eines eingeloggten Benutzers könnte lauten: 

https://www.online-bank.de/user?acc=4507 

Wenn nun die Anwendung nicht prüft, ob der Nutzer für den Zugriff auf ein Objekt autorisiert ist, 

so ist es möglich, durch Ausprobieren zu versuchen, Zugang zu anderen Konten zu erhalten. 

Die URL könnte wie folgt verändert werden: 

https://www.online-bank.de/user?acc=4508 

Der Angreifer würde dadurch unautorisiert Zugriff auf die Daten eines anderen Kontoinhabers 

erhalten.

2 Jennifer Nist 

Wie kann man sich vor diesem Angriff schützen? 

Für jede direkte Referenz, auf die ein Benutzer zugreifen könnte, muss von der Anwendung geprüft 

werden, ob dieser autorisiert ist, auf das entsprechende Objekt der Referenz zuzugreifen. 

Eine andere Möglichkeit besteht darin, stattdessen indirekte Objektreferenzen zu verwenden. Dabei 

ist, zum Beispiel in einer Datenbankanwendung, nicht der echte Datenbankindex die Referenz 

für das Objekt, sondern ein Schlüssel, zum Beispiel eine Folge von Ziffern. Ein System für die 

Zuteilung solcher Schlüsselwörter wäre zum Beispiel die für den Nutzer verfügbaren Objekte zu 

nummerieren oder ihnen eine beliebige Zahl zuzuordnen. Die Anwendung ist für die Zuordnung 

der indirekten Objektreferenzen (die Nummern) den echten Datenbankschlüsseln zuständig. 

In einem anderen Beispiel möchte die Webanwendung dem autorisierten Benutzer eine Datei zum 

Download zur Verfügung stellen. Angenommen, der verwendete Link zeigt direkt auf den Speicherort 

der Datei. 

http://www.beispiel.de/verzeichnis/datei.pdf 

Dann kann die Autorisierung nicht selbst durch die Webanwendung geprüft werden. Dies kann 

durch Absicherung durch .htaccess (eine serverseitige Technik zum Zugriffsschutz ganzer Verzeichnisse) 

realisiert werden oder durch die Verwendung einer indirekten URL. Eine solche URL könnte 

auf ein Skript zeigen, welches einen Parameter entgegen nimmt, der die zu downloadende Datei 

definiert und die Autorisierung für diese Datei überprüft. 

 

Ein solcher Aufruf sähe nun folgendermaßen aus: 

http://www.beispiel.de/download.php?file=datei.pdf 

Nur bei Bestehen dieser Prüfung wird der Inhalt der angefragten Datei dem Benutzer zurück 

gegeben. Kenntnis über den genauen Speicherort der Datei wird der Benutzer nie erhalten. 

[2] [3] [4] 

2.2 Sicherheitsrelevante Fehlkonfiguration (Security Misconfiguration) 

Bei jeder Webanwendung sollten die Entwickler und die Administratoren eng zusammenarbeiten, 

denn bei jeder Ebene der Webanwendung kann es durch Versäumnisse und Fehler zu sicherheitsrelevanter 

Fehlkonfiguration kommen. Die Ebenen einer Webanwendung sind: die physikalische 

Ebene (Personen mit Zugang zum Server), das Betriebssystem (z.B. Ubuntu), eine Datenbank 

(z.B. MySQL), einen Interpreter (z.B. PHP), der Webserver (z.B. Apache), ein Framework (z.B. 

Ruby on Rails) und die Applikation (z.B. TYPO3). Jede dieser Ebenen könnte durch Fehlkonfiguration 

Sicherheitslücken aufweisen. 

Beispiel 

In einem vorstellbaren Angriffsszenario wurde in der Anwendung ein Sicherheitslücke entdeckt und 

ein Update veröffentlicht um den Fehler zu beheben. Solange das Update jedoch noch nicht eingespielt 

wurde, könnten Angreifer diese Sicherheitslücke ausnutzen. 

Ein anderer häufiger Fehler ist es, ein automatisch installiertes Standard-Konto, zum Beispiel des 

Administrators, nicht zu ändern. Angreifer könnten dies entdecken und sich dadurch Zugang zum 

System verschaffen.

Angriffe auf die Internetprotokollfamilie und IP-Sicherheit (Praxis-Proseminar - WS12/13) 3 


Ein wichtiger Prozess um die Sicherheit zu erhöhen, ist das sogenannte ” 

Härten“. Darunter versteht 

man verschiedene Methoden, die es einem Angreifer erschweren, Sicherheitslücken zu finden. Die 

Ziele und deren Umsetzung sind dabei folgende: 

• Man sollte einem Angreifer möglichst wenige Ziele für eine Attacke bieten, wie zum Beispiel 

indem man nicht benötigte Software oder deren Komponenten deaktiviert oder entfernt und 

nicht benötigte Benutzerkonten löscht. Wichtig ist es auch, die Kommunikation (zum Beispiel 

Datenübertragung) grundsätzlich zu verschlüsseln. 

• Wenn einem Angreifer die Attacke gelungen ist, sollte er keine nützlichen Werkzeuge, oder 

vollen Zugriff auf das System zur Verfügung haben. Wichtig hierfür ist zum Beispiel, dass die 

Benutzerkonten, die zur Ausführung von Serverprozessen verwendet werden, nur die notwendigen 

Rechte haben. Außerdem sollten die Rechte des Dateisystems gut durchdacht sein. 

• Der Härtungsprozess sollte wiederholbar und zum Beispiel durch Skripte automatisiert sein. 

Wenn möglich sollte dabei die Komplexität und damit der Wartungsaufwand minimiert werden. 

Durch diese Maßnahmen kann man die Wahrscheinlichkeit von Fehlkonfigurationen senken. 

Außerdem ist es wichtig ausgereifte Software mit gutem und schnellem Support für Fixes zu verwenden. 

Ebenso sollte man bekannt gewordene Sicherheitsprobleme so schnell wie möglich beheben 

und das zugehörige Update installieren, sobald es zur Verfügung steht. Nicht zu unterschätzen ist 

die menschliche Ebene. Es sollte mit Bedacht ausgesucht werden, wem physikalischer Zugang zum 

Server gewährt wird. Webanwendungen müssen regelmäßig auf Fehlkonfigurationen oder fehlende 

Updates kontrolliert werden. 

[5] [6] [7] 

2.3 Mangelhafter URL-Zugriffsschutz (Failure to Restrict URL Access) 

Zugriffsberechtigungen sollten klar definiert sein. Dennoch ist der Zugriff auf URLs nicht immer 

verlässlich abgesichert. 

Es kommt vor, dass die Entwickler keine notwendige Prüfung der Rechte implementieren oder 

lediglich jedem Benutzer nur die Links, Navigationselemente oder Buttons anzeigen, für die er berechtigt 

ist, auf diese zuzugreifen. Es wird davon aus gegangen, dass der Benutzer nur die Verweise 

nutzt, für die er autorisiert ist. Da diese Adressen dennoch existieren und beim direkten Aufruf 

auf die vermeintlich geschützten URLs keine Prüfung der Zugriffsberechtigung stattfindet, könnte 

jeder auf diese zugreifen. 

Im Gegensatz zu den unsicheren direkten Objektreferenzen ist es möglich, direkt auf die Inhalte 

zuzugreifen und dabei die Authentifizierung zu umgehen. 

Beispiel 

Wenn eine Webanwendung nur beim Zugriff auf ihre Login-Seite, zum Beispiel http://beispiel.de/login/, 

die Authentifizierung des Benutzers überprüft, jedoch nicht auf ihren Unterseiten, ist auf diese ein 

unerlaubter Zugriff möglich. Das könnte diese Subseite sein: 

http://www.beispiel.de/login/info.php 

Diese URL könnte möglicherweise erraten oder von einem unvorsichtigen Kollegen als Link verschickt 

worden sein. 

Es könnte auch sein, dass ein angemeldeter Benutzer auf eine URL zugreifen kann, die normalerweise 

administrative Rechte erfordert. In diesem Fall könnte die URL den Benutzer auf andere 

mangelhaft geschützte administrative Seiten führen. Auch in diesem Fall könnte die URL erraten 

worden sein: 

http://www.beispiel.de/login/admin info.php 


Um den URL-Zugriffsschutz zu sichern, muss jede einzelne Seite prüfen, ob es für den Zugriff auf 

diese erforderlich ist, sich anzumelden (Prüfung der Authentifizierung), und ob der (angemeldete) 

Benutzer die notwendigen Rechte hat (Prüfung der Autorisierung). Dabei ist es von Vorteil die


Authentifizierung und die Autorisierung rollenbasiert zu gestalten, um den Verwaltungsaufwand 

möglichst klein zu halten. Eine mögliche Rollenverteilung wäre dabei zum Beispiel ” 

Gast“(keine, 

oder nur Leserechte), ” 

registrierter Benutzer“(Lese- und Schreibrechte) und ” 

Administratoren“(alle 

Rechte: lesen, schreiben, löschen... usw.). Bei der Authentifizierung wird die Identität des Nutzers 

festgestellt. Bei der Autorisation wird die Berechtigung für bestimmte Aktionen überprüft und 

festgelegt. Abbildung 1 veranschaulicht die Beziehung zwischen Authentifikation und Autorisierung 

in Anwendungen. 

Abbildung 1. Beziehung zwischen Authentifikation und Autorisation in Anwendungen: 

[8] 

Eine Möglichkeit diesen Schutz zu implementieren wäre es, die Überprüfung serverseitig im Source- 

Code jeder Datei zu definieren. So könnte der Entwickler der Anwendung zum Beispiel eine Funktion 

check permissions() implementieren, die jeden Zugriff auf diese PHP-Datei zuerst auf Zugriffsberechtigung 

überprüft: 

 

[9] [10] 

2.4 Cross-Site Scripting (XSS) 

XSS-Angriffe sind nur in dynamischen Webanwendungen möglich. Eine Webanwendung ist dynamisch, 

wenn diese auf Interaktion des Benutzers reagiert. Eine Schwachstelle entsteht, wenn die 

Anwendung nicht vertrauenswürdige Daten vom Benutzer entgegen nimmt und ihm diese zurück 

gibt, jedoch nicht ausreichend validiert, zum Beispiel nicht auf unerwünschte Eingaben überprüft. 

Diese sind oft Metazeichen. Diese Metazeichen stehen innerhalb eines bestimmten Kontextes, zum 

Beispiel in einem HTML-Quellcode, nicht für sich selbst, sondern haben eine besondere Bedeutung. 

Sie könnten daher dazu führen, dass die (eventuell bösartige) Eingabe eines Benutzers nicht als 

reiner Text interpretiert wird, sondern als aktiver Inhalt, der möglicherweise ausführbar ist. 

Beispiel für Metazeichen: 

Der Text ” 

“besteht in der Zusammensetzung aus zwei spitzen 

Klammern und Attributen. Jedoch steht die Zeichenfolge im Kontext einer HTML-Seite für den 

Beginn eines ausführbaren Inhaltes der Sprache JavaScript. Der darauf folgende Text wird solange 

als JavaScript interpretiert, bis der Abschnitt durch das Tag geschlossen wird. Wenn 

die Benutzereingaben nicht auf solche Metazeichen hin überprüft werden, ist es für den Angreifer 

möglich, nahezu beliebigen Schadcode auszuführen.


Es gibt drei verschiedene Typen von XSS-Schwachstellen: nicht-persistent bzw. reflektiert, persistent 

und DOM-basiert. 

Reflektiert: Bei einem reflektierten XSS-Angriff wird das Skript, welches Schadcode enthält, nach 

einer Benutzereingabe direkt vom Server zurück gesendet (reflektiert). Da das Skript von einem 

bekannten und ” 

sicheren“Server kommt, führt der Browser des Benutzers das Skript aus. 

Beispiel 

Eine Website hat eine Suchfunktion. Der gesuchte Begriff wird dabei in der Ergebnisliste nochmals 

ausgegeben (Reflektion des Servers). Die Anfrage an den Server könnte dabei zum Beispiel so aussehen: 

http://beispiel.de/index.php?suche=Suchbegriff 

Die Zeichenkette ” 

Suchbegriff“wird vom Webserver ungeprüft in den Quelltext der Ausgabe eingebaut. 

Jedoch könnte anstatt eines Suchbegriffes beispielsweise auch folgende Zeichenkette eingegeben 

werden: 

http://beispiel.de/index.php?suche=alert(“XSS“) 

Dieser Code wird nun unverändert in den Quellcode der Seite integriert und ausgeführt. Sofern die 

Anwendung den Angriff nicht erkennt, könnte beliebiger Schadcode eingeschleust werden. Versendet 

man diese URL zu der vermeintlich harmlosen Suchanfrage, so glaubt sich der Empfänger in 

Sicherheit, da er eine vertrauenswürdige URL aufruft, diese jedoch durch die XSS-Schwachstelle 

der Webanwendung Schadcode ausführt. 

Persistent: Eine persistente XSS-Schwachstelle könnte zum Beispiel in einem Gästebuch vorhanden 

sein. Jeder Eintrag in das Gästebuch wird vom Server zwischengespeichert, zum Beispiel in 

einer Datenbank. Fügt nun ein Angreifer Schadcode in seinen Gästebucheintrag ein, speichert das 

Gästebuch diesen in der Datenbank. Dadurch wird jeder zum Opfer, der auf diese gespeicherte 

Information zugreift. Denn jeder Besucher, der diese Seite aufruft, um das Gästebuch zu lesen, 

würde das Skript mit dem Schadcode auf seinem Computer ausführen. 

Beispiel 

 

a l e r t (” A n g r i f f ! ! ” ) ; 

 

Diese Eingabe könnte zum Beispiel in einem Gästebuch, bei unzureichender Prüfung auf Sonderzeichen, 

dazu führen, dass eine Meldung mit dem Text ” 

Angriff!!“im Browser erscheint. In einem 

anderen Fall könnte das Skript auch unsichtbar sein und Malware enthalten oder den Benutzer auf 

eine Phishing-Site umleiten. 

Der Angreifer könnte auch durch ein im Hintergrund laufendes Skript sich die Session-ID des 

Benutzers schicken lassen und damit die aktuelle Session übernehmen und so Zugriff auf das Benutzerkonto 

des Benutzers erlangen. 

Ein weiteres Beispiel für eine persistente XSS-Schwachstelle ist in Abbildung 2 zu sehen. 

• Der Angreifer schleust ein Skript ein. Dieses wird von der serverseitigen Prüfung nicht erkannt 

und vom Webserver in die Datenbank geschrieben. 

• Sobald ein Benutzer die betreffende Seite aufruft, wird das Skript lokal ausgeführt. Es leitet 

den Benutzer auf eine zuvor vom Angreifer manipulierte oder erstellte Seite um, ohne dass 

dieser etwas davon merkt. 

• Der Angreifer könnte auf dieser Seite zum Beispiel eine Fehlermeldung anzeigen lassen, die 

eine erneute Anmeldung des Benutzers auf der Seite www.betreiber.de, oder der Eingabe der 

Bankdaten, erfordert. So könnte das Skript jede Eingabe des Benutzers an den Angreifer weiterleiten.


Abbildung 2. Beispiel einer persistenten XSS-Schwachstelle: 

[11] 

Dom-basiert: DOM steht für Document Object Model und ist eine Schnittstelle zur browserunabhängigen 

Interpretation von HTML- und XML-Daten. Diese erfolgt benutzerseitig durch den 

Webbrowser. Der DOM-basierte XSS-Angriff nutzt, im Gegensatz zu den beiden anderen XSS- 

Angriffen, welche sich auf die serverseitige Erzeugung von dynamischen Webseiten stützten, die 

benutzerseitige Interpretation von Benutzereingaben. 

Beispiel 

Ein Benutzer macht eine Eingabe in eine Webanwendung. Diese Eingabe wird benutzerseitig durch 

eine Skriptsprache, wie etwa JavaScript, aus der URL als Argument ausgelesen: 

http://beispiel.de/datei.html?arg=Argument 

Dieses Argument wird in das betreffende HTML-Dokument eingefügt. Wenn dies ungeprüft geschieht, 

so kann die aufrufende URL manipuliert und an potentielle Opfer als harmloser Link 

verschickt werden. 

http://beispiel.de/datei.html?arg=alert(“XSS“) 


Grundsätzlich sind Benutzereingaben nie vertrauenswürdig. Daher sollte jede Eingabe serverseitig 

geprüft werden. Dabei ist es meistens von Vorteil Whitelist zu benutzen. Bei dieser Methode werden 

nur solche Eingaben zugelassen, die auf der Liste stehen. Eine andere Methode ist die eine Blacklist 

zu führen. Dabei werden, im Gegensatz zu der Whitelist, die Eingaben die auf der Liste stehen 

nicht zugelassen. Eine Blacklist ist sinnvoller, wenn die Anzahl der erlaubten Eingaben zu hoch ist 

um sie auf eine Liste einzutragen. Jedoch sind Whitelists theoretisch die sicherere Wahl, da ständig 

neuere und komplexere Angriffsmethoden entwickelt werden, die zuvor noch nicht absehbar waren. 

Möchte der Benutzer nun ein Code-Beispiel in das Gästebuch schreiben, müssen Metazeichen als 

solche maskiert (escaped) und damit als normale Zeichen markiert werden. Bei der Maskierung 

wird dem Metazeichen ein bestimmtes Zeichen voran gestellt oder es komplett ersetzt, damit der 

Interpreter dies als eine Zeichenrepräsentation erkennt und nicht als Metazeichen interpretiert. 

Beispielsweise ersetzt man beim escapen von HTML-Code das Metazeichen ” 


bevor sie akzeptiert wird. 

Eine recht zuverlässige Möglichkeit, sich als Benutzer vor XSS-Angriffen zu schützen, ist es, die 

JavaScript-Unterstützung im Browser zu deaktivieren. Allerdings schützt dies nur gegen XSS- 

Angriffe, die auch mit JavaScript arbeiten. 

[12] [13] 

3 Schlussbemerkung 

Einer der wichtigsten Leitsätze, die Entwickler berücksichtigen sollten, wenn sie Web-Anwendungen 

vor Angriffen schützen möchten, lautet: ” 

Traue NIE Benutzereingaben.“Denn wenn es die Möglichkeit 

für eine bösartige Eingabe gibt, sollte davon ausgegangen werden, dass es geschieht. 

Für Anwender gilt es wachsam zu sein und persönliche Daten nicht blind Preis zu geben. Wenn 

eine Anwendung zum Beispiel plötzlich nach der Kreditkartennummer fragt, sollte der Nutzer misstrauisch 

werden. 

Für beide, Anwender und Entwickler, bedeutet das, immer die aktuellste Software zu verwenden 

und über die neuesten Techniken der Angreifer informiert zu sein. Ist eine Sicherheitslücke schon 

lange bekannt und behoben, sollte der Patch auch installiert werden. Nur wer seine Software auf 

dem neuesten Stand hält und sich regelmäßig über neue Angriffstechniken informiert, kann sich 

gegen diese schützen. 

In Zukunft werden die Angriffe auf Webanwendungen und auch deren Absicherung immer aufwändiger 

werden. Die Schwachstellen können in Unmengen von Code versteckt sein, was die Suche nach 

ihnen und deren Prävention komplex und zeitaufwändig gestaltet. Selbst wenn eine Anwendung 

nach dem neuesten Stand der Technik sicher ist, könnte ein Angreifer schon einen neuen Weg 

gefunden haben einen Angriff durchzuführen. 

Literatur 

1. CCC: Chaos computer club weist auf ernste sicherheitslücken bei der bundesfinanzagentur hin. WWW- 

Dokument, http://www.ccc.de/de/updates/2011/bundesfinanzagentur (2011) [Online, letzter Aufruf 

10.02.2013]. 

2. OWASP: Owasp top 10 - 2010. PDF-Dokument, pp. 6,10, https://www.owasp.org/images/b/b8/ 

OWASPTop10_DE_Version_1_0.pdf (2010) [Online, letzter Aufruf 10.02.2013]. 

3. Jellinek, B.: Unsichere direkte objektreferenzen. WWW-Dokument, http://web-development. 

github.com/security/a4-referenz/ (2012) [Online, letzter Aufruf 10.02.2013]. 

4. AQUANTM: Web application security (teil 4). WWW-Dokument, http://www.aquantum.de/2011/ 

01/24/web-application-security-teil-4/ (2011) [Online, letzter Aufruf 10.02.2013]. 



6. Jellinek, B.: Sicherheitsrelevante fehlkonfiguration. WWW-Dokument, http://web-development. 

github.com/security/a6-konfiguration/ (2012) [Online, letzter Aufruf 10.02.2013]. 

7. Wikipedia: Härten (computer). WWW-Dokument, http://de.wikipedia.org/wiki/H%C3%A4rten_ 

%28Computer%29 (2013) [Online, letzter Aufruf 10.02.2013]. 

8. koirala, S.: Authentication and authorization. WWW-Grafik, http://www.codeproject. 

com/Articles/98950/ASP-NET-authentication-and-authorization (2010) [Online, letzter Aufruf 

10.02.2013]. 



10. Jellinek, B.: Mangelhafter url-zugriffsschutz. WWW-Dokument, http://web-development.github. 

com/security/a8-url/ (2012) [Online, letzter Aufruf 10.02.2013]. 

11. Wikipedia: Cross-site-scripting). WWW-Dokument, http://de.wikipedia.org/wiki/ 

Cross-Site-Scripting (2013) [Online, letzter Aufruf 10.02.2013]. 



13. Wirtschaftsinformatik, W.F.S.: Sicherheit von webanwendungen. WWW-Grafik, http:// 

wiki.fh-stralsund.de/index.php/Sicherheit_von_Webanwendungen (2009) [Online, letzter Aufruf 

10.02.2013].

Uberblick Websecurity - Albert-Ludwigs-Universität Freiburg

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?