Die gefährlichsten Webanwendungsrisiken im Überblick

Open Web Application Security Project: Top 10 Schwachstellen
Kommentare

Das Open Web Application Security Project hat die Ausgabe 2013 der Top 10 mit den gefährlichsten Schwachstellen in Webanwendungen veröffentlicht. In diesem Artikel werden die Plätze 1 bis 5 vorgestellt, die Plätze 6 bis 10 folgen in Kürze.

Eine Übersicht über die aktuellen OWASP Top 10 sowie die Änderungen im Vergleich zum 2010 veröffentlichten Vorgänger finden Sie in Tabelle 1. Die Reihenfolge der Schwachstellen ergibt sich aus vier Faktoren:

  1. Die Wahrscheinlichkeit dafür, dass eine Webanwendung die Schwachstelle enthält (Prevalence).
  2. Die Wahrscheinlichkeit dafür, dass ein Angreifer die Schwachstelle entdeckt (Detectability).
  3. Die Wahrscheinlichkeit dafür, dass ein Angreifer die Schwachstelle erfolgreich ausnutzt (Exploitability).
  4. Die typischen Folgen eines Angriffs (Impact).

Ein kleiner Test

Bevor ich auf die Top 10 eingehe, möchte ich Sie um einen kleinen Test bitten. Sofern Sie für eine Webanwendung verantwortlich sind – egal ob als Entwickler, Admin, Projektleiter oder was auch immer – geben Sie bitte mal die beiden folgenden Strings in die Suchfunktion Ihrer Webanwendung ein: irgend’was und irgendwas“ <script>alert(1);</script>.

Wenn im ersten Fall eine SQL-Fehlermeldung ausgegeben wird, stehen die Chancen gut, dass Ihre Anwendung eine SQL-Injection-Schwachstelle enthält. Herzlichen Glückwunsch, Sie haben eine der gefährlichsten aller Schwachstellen gefunden: Sämtliche Injection-Schwachstellen stehen auf Platz 1 der Top 10.

Und wenn im zweiten Fall eine Alertbox mit einer 1 darin aufgeht, haben Sie eine XSS-Schwachstelle gefunden. Die steht zwar „nur“ auf dem dritten Platz, ist aber gefährlich genug. Immerhin kann ein Angreifer darüber zum Beispiel die Session-IDs der Benutzer ausspähen. Und meistens gibt es noch weitere Schwachstellen, wenn schon dieser simple Test funktioniert. XSS in der Suchfunktion ist ein Klassiker – eigentlich dürfte es so was gar nicht mehr geben, trotzdem treten diese Low hanging fruit-Schwachstellen immer wieder auf.

Sie haben weder SQL Injection noch XSS gefunden? Dann versuchen Sie doch mal ihr Glück mit Platz 2 der Top 10: Schwachstellen in der Authentifizierung. Können Sie sich mit dem Benutzernamen und Passwort irgendwas‘ OR ‚1‘=’1′ — anmelden? Dann gratuliere ich Ihnen zu ihrer ersten Schwachstelle vom Platz 3 der Top 10! Und die ist gleichzeitig eine SQL-Injection-Schwachstelle, steht also zusätzlich auf Platz 1. Zwei Schwachstellen auf einen Streich, das lohnt sich doch!

Aber genug gelästert, kommen wir zu den Fakten – den ersten fünf der OWASP Top 10 aus dem Jahr 2013.

Tabelle 1: Die OWASP Top 10, Ausgabe 2013

OWASP Top 10 im Security-Workshop in PHP User und PHP Magazin

Viele Schwachstellen aus den OWASP Top 10 wurden im Rahmen meiner Security-Workshops im PHP User und PHP Magazin ausführlich behandelt. Von der Ursache der Schwachstellen über die möglichen Folgen eines Angriffs bis zu Schutz- und Gegenmaßnahmen wird alles abgedeckt. Für die in diesem Artikel behandelten ersten fünf Plätze der Top 10 sind folgende Workshop-Folgen relevant:

A1: Injection
• SQL Injection: „… und die Datenbank gehorcht dem Angreifer“, in PHP User 2.2010 • SMTP Header Injection: „Die Sache mit den Headern – Auch Zeilenumbrüche können gefährlich sein“, in PHP Magazin 3.2011 • OS Command Injection: „Das kann schnell schief gehen! – Aufrufe externer Programme“, in PHP Magazin 2.2011
A2: Broken Authentication and Session Management
• „Schwachstellen in der Authentifizierung erkennen und vermeiden“, in PHP Magazin 5.2010 • „Session Hijacking, Session Fixation, Session Futsch“, in PHP Magazin 5.2011
A3: Cross-site Scripting (XSS)
• „Cross-site Scripting – Angreifers Leatherman“, in PHP User 1.2010
A4: Insecure Direct Object References
• „Zugriffsfehler aller Arten – 3 der 10 gefährlichsten Schwachstellen auf der Spur“, in PHP Magazin 4.2011
A5: Security Misconfiguration
• „Konfigurierte (Un-)Sicherheit – Die Auswirkungen der Apache-Konfiguration auf die Sicherheit der Webanwendung“, in PHP Magazin 6.2012

A1: Injection

Bei der auf Platz 1 stehenden Injection denken die meisten von Ihnen sicher zuerst an die oben schon erwähnte SQL Injection. Es gibt aber viele weitere Injection-Schwachstellen, zum Beispiel:

  • OS Command Injection – das Einschleusen von Systembefehlen in Aufrufe externer Programme
  • SMTP Header Injection – das Einschleusen von E-Mail-Befehlen beim Senden einer E-Mail
  • LDAP Injection – das Einschleusen von LDAP-Anweisungen in LDAP-Abfragen
  • NoSQL Injection – das Einschleusen von JavaScript-Befehlen in NoSQL-Abfragen
  • Xpath Injection oder XML Injection – das Einschleusen von Xpath-Anweisungen in Abfragen für XML-Daten

Die Folgen eines Angriffs sind meist mehr oder weniger fatal. Bei der SQL Injection denkt man meist zuerst an das Ausspähen von Daten, und es gab in letzter Zeit bekanntlich reichlich Datenlecks, die zumindest teilweise die Folge von SQL-Injection-Angriffen waren. Mindestens genau so schlimm ist es aber, wenn eine Webanwendung über SQL Injection mit Code zur Verbreitung von Drive-by-Infektionen präpariert wird. Vom klassischen Umgehen der Authentifizierung durch das „Passwort“ irgendwas‘ OR ‚1‘=’1′ — ganz zu schweigen.

Bei der OS Command Injection hat der Angreifer meist sofort die vollständige Kontrolle über die Webanwendung, auf den Server kann er meist nur mit den reduzierten Rechten des Webservers zugreifen. Sollte es auf dem Server eine Privilegieneskalationsschwachstelle geben, ist der Angreifer aber nur einen Schritt vom Erlangen höherer Rechte entfernt. Und im Allgemeinen bedeutet das, dass er Administratorrechte erhält und damit die vollständige Kontrolle über den Server erlangt.

Eine SMTP Header Injection wird meist zum Versenden von Spams ausgenutzt, die LDAP-, NoSQL- und Xpath-/XML-Injection-Schwachstellen zum Ausspähen oder auch Manipulieren von Daten.

Injection-Schwachstellen verhindern

Der beste Schutz vor Injection-Schwachstellen ist die Verwendung eines API, das die Benutzereingaben von den Befehlen und Abfragen trennt. Entweder indem der entsprechende Interpreter gar nicht verwendet wird oder indem parametrisierte Aufrufe möglich sind. Werden die parametrisierten Aufrufe durchgehend genutzt, ist eventuell eingeschleuster Schadcode wirkungslos.

Am bekanntesten dürften in diesem Zusammenhang die Prepared Statements für SQL mit parametrisierten Aufrufen sein. Im Fall von PHP gibt es dazu eine gute Nachricht: Das klassische MySQL-API, das keine Prepared Statements unterstützt, gilt seit PHP 5.5 als veraltet. Wenn die Anwendungen nun sowieso an ein neues API angepasst werden müssen, können sie dabei auch gleich auf Prepared Statements mit parametrisierten Aufrufen umgestellt werden, was ihrer Sicherheit sehr zugute kommt (Eilers, Carsten: „PHP-Sicherheit von PHP 4.x bis PHP 5.5“, in PHP Magazin 5.2013).

Gibt es kein entsprechendes API, müssen die jeweiligen kritischen Sonderzeichen wie zum Beispiel das Hochkomma in Parametern für SQL-Abfragen passend escaped werden. Das ist in vielen Fällen zum Beispiel mit dem OWASP-Enterprise-Security-API möglich, sofern die genutzte Programmiersprache und/oder das verwendete Framework nicht selbst entsprechende Funktionen bereitstellen.

Zu guter Letzt ist es oft auch möglich, die Benutzereingaben mit einer Whiteliste zulässiger Eingaben abzugleichen, in harmlose Typen (beispielsweise Zahlenwerte) umzuwandeln oder mit Hilfe regulärer Ausdrücke auf Korrektheit zu prüfen (zum Beispiel bei E-Mail-Adressen oder Domainnamen).

Aufmacherbild: Abstract pollen in vector von Shutterstock / Urheberrecht: Svinkin [ header = Seite 2: A2: Broken Authentication and Session Management ]

A2: Broken Authentication and Session Management

Schwachstellen in der Authentifizierung und dem Session Management stehen auf Platz 2 der Top 10 2013. Sie haben gegenüber der Ausgabe von 2010 ihren Platz mit dem Cross-site Scripting getauscht, das sich nun auf Platz 3 befindet.

Im Grunde sind in diesem Punkt alle Schwachstellen und Angriffe zusammengefasst, über die ein Angreifer sich Zugriff auf ein Benutzerkonto verschaffen kann. Dafür gibt es mehrere Möglichkeiten: Schwachstellen in der Authentifizierung können dazu führen, dass sich ein Angreifer ohne gültige Zugangsdaten als Benutzer anmelden kann, oder dass ein bereits angemeldeter Benutzer höhere Rechte erlangen kann. Bei Schwachstellen im Session Management kann ein Angreifer entweder die laufende Session eines angemeldeten Benutzer übernehmen (Session Hijacking) oder eine eigene Session von einem Benutzer authentifizieren lassen (Session Fixation).

Dabei ist die Bandbreite möglicher Schwachstellen und Angriffe groß. Ein Klassiker ist der oben schon erwähnte SQL-Injection-Angriff über Benutzername und Passwort. Dann gibt es immer wieder Logikfehler (Beispiel 1, Beispiel 2, Beispiel 3, Beispiel 4), die entweder die Authentifizierung komplett aushebeln oder angemeldeten Benutzern das Erlangen höherer Benutzerrechte erlauben. Sehr verbreitet ist auch die unsichere Verwendung von Cookies (Beispiel 1, Beispiel 2, Beispiel 3) oder SSL/TLS, sodass Session-Cookies ausgespäht und laufende Sessions übernommen werden können. Oder wie wäre es mit im URL übertragenen Session-IDs, verbunden mit einer sehr langen Session-Lebensdauer und ohne weitere Schutzmaßnahmen? Veröffentlicht der Benutzer dann einen Link samt Session-ID zum Beispiel auf Twitter, ist jeder, der den Link klickt, sofort und ohne weitere Aktion als dieser Benutzer angemeldet.

Ebenfalls zur Kategorie A2 gehören unsicher gespeicherte Passwörter. Zugangsdaten werden zwar zum Beispiel über SQL Injection ausgespäht, sind die ausgespähten Passwörter dann aber unverschlüsselt oder nur als einfacher Hashwert gespeichert, hat der Angreifer leichtes Spiel: Er kann sich sofort oder nach Knacken der Hashwerte als Benutzer anmelden.

Und zu guter Letzt gibt es dann noch die Klassiker Brute Force und Wörterbuchangriff: Ist die Anzahl der möglichen Login-Versuche nicht begrenzt, probiert ein Angreifer einfach alle möglichen und unmöglichen Werte aus, bis er irgendwann eine gültige Kombination von Benutzername und Passwort gefunden hat. Verrät die Anwendung dann auch noch, ob Benutzername oder Passwort falsch sind, hat der Angreifer es noch leichter: Erst sucht er einen vorhandenen Benutzernamen, danach das dazu passende Passwort.

Authentifizierung und Session Management absichern

Mögliche Schutz- und Gegenmaßnahmen lassen sich in diesem Fall nicht in ein paar Sätzen zusammenfassen. Eigentlich kann ich Ihnen nur einen einfachen Rat geben: „Achten Sie darauf, dass die Authentifizierung und das Session Management sicher implementiert sind“. Und der ist nicht besonders hilfreich, richtig?

Dass ihre Anwendung keine anderen Schwachstellen haben darf, dürfte auch selbstverständlich sein. Insbesondere natürlich keine SQL-Injection-Schwachstellen, über die sich die Authentifizierung umgehen oder Zugangsdaten ausspähen lassen, oder XSS-Schwachstellen, über die sich Session-Identifier kopieren lassen.

Passwörter müssen immer als gesalzener Hashwert gespeichert werden. Noch besser ist die Verwendung eine speziell für die Speicherung von Passwörtern konzipierte Hashfunktion, die das Brechen des Hash deutlich erschwert. In PHP wurde mit Version 5.5 ein neues API zur Sicherung von Passwörtern implementiert [6].

Und zu guter Letzt muss die Anzahl möglicher Login-Versuche beschränkt werden, und die Anwendung darf nirgends verraten, ob ein Benutzername existiert oder nicht. Mit anderen Worten: Geben Sie insbesondere bei einem fehlgeschlagenen Login-Versuch eine allgemeine Information wie „Benutzername und/oder Passwort falsch“ aus. Eine Meldung wie „Das Passwort ist falsch“ verrät einem Angreifer, dass er einen gültigen Benutzernamen gefunden hat, er muss nun also nur noch alle möglichen Passwörter ausprobieren.

A3: Cross-site Scripting (XSS)

Cross-site Scripting, der Klassiker unter den Webschwachstellen, darf natürlich in den OWASP Top 10 nicht fehlen. Wie oben schon erwähnt dieses Jahr auf Platz 3, statt auf Platz 2.

Eigentlich sollte man annehmen, dass es 2013 keine XSS-Schwachstellen mehr gibt. Eigentlich sollte jeder Webentwickler wissen, was XSS ist, und wie er diese Schwachstellen verhindert. Eigentlich, denn XSS ist im Grunde so alt wie das Web. Uneigentlich gibt es auch 2013 noch XSS-Schwachstellen. Entweder, weil ein Entwickler wirklich keine Ahnung von Sicherheit hat und selbst den Klassiker der Websicherheit nicht kennt, oder, und das viel öfter, weil Flüchtigkeitsfehler gemacht und zum Beispiel eigentlich vorhandene Schutzfunktionen für einen oder einige wenige Parameter nicht genutzt werden.

Daher hier noch mal zu Erinnerung: Das grundlegendes Problem bei XSS-Schwachstellen ist die ungeprüfte Übernahme von Benutzereingaben in die Ausgabe. Ein Angreifer kann das ausnutzen, um eigenen HTML- und JavaScript-Code im Webbrowser eines Benutzers auszuführen, was weitreichende Folgen haben kann: Von der Manipulation der angezeigten Informationen über das Ausspähen sensitiver Informationen wie zum Beispiel der Session-Identifier bis zur Ausnutzung weiterer Schwachstellen zur Ausführung beliebigen Codes im Rahmen einer Drive-by-Infektion ist alles möglich.

XSS tritt in drei Formen auf: Beim DOM-basierten oder lokalen XSS wird der Schadcode durch eine Schwachstelle im clientseitigen Scriptcode eingeschleust – eine JavaScript-Funktion gibt die übergebenen Daten also ungeprüft und ungefiltert aus. Für den Angriff muss das Opfer einen präparierten Link anklicken, der den Schadcode enthält. Da es sich dabei um eine Schwachstelle im clientseitigen Code handelt, muss sie auch dort behoben werden. Die Webanwendung auf dem Server bekommt den Schadcode unter Umständen gar nicht zu sehen.

Beim reflektierten XSS wird der Schadcode an die Webanwendung gesendet und von dieser an den Client zurückgeschickt. Für den Angriff muss das Opfer einen präparierten Link anklicken oder ein präpariertes Formular abschicken, in dem der Schadcode enthalten ist. Da der Schadcode den Weg über den Server nimmt, kann er auch auf dem Server entdeckt und ausgefiltert werden.

Beim auch als JavaScript Injection bezeichneten persistenten XSS wird der Schadcode zum Beispiel in einem Gästebucheintrag auf dem Server gespeichert. Danach wird er bei jedem Aufruf der betroffenen Seite ausgeliefert. Es muss also kein bestimmter URL angeklickt oder ein präpariertes Formular abgeschickt werden, es reicht, wenn ein Benutzer während der normalen Benutzung der Webanwendung die entsprechende Seite erreicht.

XSS verhindern

Damit kein Schadcode eingeschleust werden kann, müssen Sie die Benutzereingaben prüfen und/oder filtern. Wenn überhaupt kein vom Benutzer eingegebener HTML-Code erlaubt ist, ist das sehr einfach: Möglicherweise eingegebener HTML-Code kann generell gelöscht werden, in PHP zum Beispiel mit dem Befehl striptags(). Dabei evtl. erhalten gebliebene Reste von Tags können durch die Umwandlung von < und > in ihre HTML-Entities &lt; und &gt; unbrauchbar gemacht werden.

Komplizierter wird es, wenn bestimmte HTML-Tags erlaubt sind. Dann müssen Sie die Eingabe mit einer Liste zulässiger Tags vergleichen und alle unerwünschten Tags löschen oder unbrauchbar machen. Achten Sie dabei besonders auf unerwünschte Attribute wie onerror oder onmouseover in erwünschten Tags.

Weitere Informationen zum Schutz vor XSS finden Sie zum Beispiel im „XSS (Cross-site Scripting) Prevention Cheat Sheet“ und „DOM based XSS Prevention Cheat Sheet“ des OWASP.

[ header = Seite 3: A4: Insecure Direct Object References ]

A4: Insecure Direct Object References

Auf Platz 4 stehen wie schon 2010 die Insecure Direct Object References. „Unsichere direkte Objektreferenzen“ klingt erst mal sehr abstrakt. Und das ist es auch, da es eine Vielzahl möglicher Angriffe und Schwachstellen umfassen muss: Alle, bei denen unsicher auf irgendetwas zugegriffen wird. Ob das nun ein Datenbankeintrag, eine Datei oder was auch immer ist, ist dabei egal.

Immer, wenn auf bestimmte Objekte nur bestimmte Benutzer zugreifen dürfen, die Anwendung aber direkt auf die Objekte zugreift, besteht die Gefahr eines in diese Kategorie fallenden Angriffs bzw. einer entsprechenden Schwachstelle. Das klingt immer noch abstrakt, lässt sich aber an einem einfachen Beispiel leicht erklären. Das Beispiel entspricht dem von OWASP genutzten Beispiel:

String query = "SELECT * FROM benutzertabelle WHERE benutzerid = ?";
PreparedStatement pstmt = connection.prepareStatement(query, ...);
pstmt.setString( 1, request.getParameter("id"));
ResultSet results = pstmt.executeQuery( );

Ein Angreifer kann beim Aufruf dieses Skripts eine beliebige fremde Benutzer-ID übergeben und auf das zugehörige Benutzerkonto zugreifen:

htt p://webanwendung.example /benutzerinfo?benutzerid=[irgend eine ID]

Unsichere Zugriffe verhindern

Die Schwachstelle im Beispiel kann man auf den ersten Blick ganz einfach dadurch verhindern, dass man den Zugriff auf das Skript erst erlaubt, nachdem der Benutzer sich authentifiziert hat. Leider stimmt das nicht, denn auch dann kann der Benutzer noch fremde Benutzer-IDs eingeben und auf die entsprechenden Daten zugreifen. Das Skript muss also so geändert werden, dass es jedem Benutzer nur den Zugriff auf die zu seiner ID gehörenden Daten erlaubt. Da die Benutzer-ID des jeweiligen Benutzers der Webanwendung bekannt ist, ist ihre Angabe durch den Benutzer an dieser Stelle völlig überflüssig. Statt sie als Benutzereingabe zu erhalten, kann das Skript auch einfach beim Aufruf die Daten des aktuellen Benutzers ausgeben. Allgemein gibt es für diese Kategorie zwei Möglichkeiten, wie es zur Schwachstelle kommen kann:

  1. Bei direkten Referenzen auf nicht allgemein zugängliche Ressourcen prüft die Anwendung die Autorisierung des Benutzers gar nicht oder nicht ausreichend.
  2. Bei indirekten Referenzen wird bei der Umsetzung (Mapping) in die entsprechenden direkten Referenzen nicht darauf geachtet, nur Umsetzungen für die Ressourcen frei zu geben, für die der aktuelle Benutzer die nötigen Zugriffsrechte hat.

Die Schutzmaßnahmen ergeben sich eigentlich direkt aus diesen Fehlerquellen:

  • Statt direkter Referenzen sollten Sie indirekte Referenzen verwenden, und zwar individuell für jeden Benutzer bzw. jede Session. Beim Mapping der direkten auf die indirekten Referenzen müssen die aktuellen Zugriffsrechte des Benutzers berücksichtigt werden. Dadurch wird zum einen verhindert, dass ein Angreifer direkten Zugriff auf Ressourcen erhält, zum anderen, dass ein Benutzer auf für ihn eigentlich nicht zugängliche Ressourcen zugreifen kann.
  • Sind direkte Referenzen nötig, muss vor jedem Zugriff auf ein Objekt die Autorisierung des aktuellen Benutzers geprüft werden.

A5: Security Misconfiguration

Auf Platz 5 stehen 2013 sicherheitsrelevante Konfigurationsfehler. Eine Kategorie, die 2010 noch auf Platz 6 zu finden war. Die 2010 noch auf Platz 5 zu findende Cross-site Request Forgery ist abgestiegen auf Platz 8.

Unter Security Misconfiguration fallen zum einen tatsächliche Konfigurationsfehler, zum Beispiel wenn nicht benötigte Funktionen des Webservers nicht ausgeschaltet oder Default-Zugangsdaten nicht geändert werden. Zum anderen finden Sie hier auch Probleme wie die Verwendung veralteter Programm- und Systemversionen mit bekannten Schwachstellen oder an die Benutzer ausgegebene ausführliche Fehlermeldungen. Also im Grunde alle die Schwachstellen, die nicht schon bei der Entwicklung der Webanwendung entstehen, sondern erst bei ihrem Betrieb dazu kommen.

Sichere Konfiguration sicherstellen

Um eine sichere Konfiguration sicherzustellen, sind mehrere Schritte nötig:

  1. Zuerst müssen Sie einen reproduzierbaren Härtungsprozess für System und Anwendungen entwickeln. Und der sollte so weit wie möglich automatisiert werden, da sie ihn immer wieder benötigen. Installieren Sie nur die benötigte Software, deaktivieren Sie alle nicht benötigten Funktionen, löschen Sie Demoanwendungen und Default-Zugangsdaten und dergleichen mehr.
  2. Verwenden Sie für Entwicklungs-, Test- und Produktivsysteme identische Konfigurationen. Erstens ist es generell ärgerlich, wenn etwas auf dem sicher konfigurierten Produktivsystem nicht läuft, was auf dem unsicheren Testsystem problemlos funktionierte. Zweitens kommt es, vor allem unter Zeitdruck, schnell zu gefährlichen Konfigurationsänderungen am Produktivsystem, frei nach dem Motto „Passen wir halt das Produktivsystem ans Testsystem an, dann läuft das schließlich“. Natürlich beseitigt diese Konfigurationsänderung das aktuelle Problem, aber meist fangen die eigentlichen Probleme damit erst an.
  3. Implementieren Sie einen Prozess, um alle Komponenten auf dem aktuellen Stand zu halten. Zumindest sicherheitsrelevante Updates und Patches müssen zügig installiert werden. Mit der Installation neuer Features, vor allem wenn sie sowieso nicht genutzt werden, kann man ruhig etwas warten, Schwachstellen müssen aber so schnell wie möglich behoben werden. Stellen Sie sicher, dass wirklich alle Komponenten berücksichtigt werden. Vor allem Bibliotheken werden dabei schnell übersehen, insbesondere, wenn sie von anderen Komponenten mitinstalliert werden.
  4. Prüfen Sie die Systeme mithilfe eines Scanners regelmäßig auf möglicherweise vergessene Patches oder unsichere Konfigurationen.

Fazit

Welches Fazit soll man hier ziehen? Dass 2013 noch fast die gleichen Schwachstellen wie 2010 existieren? Zufällig kann ich sogar sagen, dass es im Grunde die gleichen Schwachstellen wie 2003 sind – wenn man mal von Feinheiten wie der damals noch weitgehend bedeutungslosen XML Injection absieht.

Damit bliebe als Fazit eigentlich nur: „Die Entwickler haben nichts gelernt“ – aber damit täte man ihnen in den allermeisten Fällen Unrecht. Insgesamt hat sich die Sicherheitssituation durchaus verbessert, aber sehen wir es doch mal realistisch: Welche weiteren Schwachstellen gibt es denn für Webanwendungen überhaupt noch? Schon beim Aufstellen einer Top 20 müsste man wahrscheinlich einige der Top 10 aufspalten, um überhaupt genug Kandidaten zu bekommen.

Die OWASP Top 10 sind die zehn häufigsten und gefährlichsten Schwachstellen im Jahr 2013. Punkt. Aus. Ende. Und ganz egal, was die Entwickler auch machen, bei der nächsten Top-Ten-Liste, egal in wie vielen Jahren sie veröffentlicht wird, werden wir es wieder mit den gleichen Schwachstellen zu tun haben. Einfach, weil die Auswahl möglicher Schwachstellen nicht besonders groß ist und zum Beispiel eine OS Command Injection schwerlich von einer gefährlicheren Schwachstelle getoppt werden kann. Schlimmer als beliebige Befehle ausführen, kann ein Angriff einfach nicht werden. Was sollte die Injection-Schwachstellen also von Platz 1 verdrängen?

Was sich ändert, ist die Anzahl der Schwachstellen. In diesem Sinne: Machen Sie ruhig so weiter wie bisher: Dezimieren Sie weiter die Anzahl der Schwachstellen, an deren Gefährlichkeit können Sie sowieso nichts ändern. Das müssen Sie auch gar nicht, denn das Ziel muss ja immer lauten, keine Schwachstellen in der Webanwendung zu haben. Egal, wie schwerwiegend oder harmlos: Jede Schwachstelle ist eine zu viel.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -