valerybrozhinsky - stock.adobe.c
Was wirklich hinter der Bedrohung durch SQL Injection steckt
SQL Injection ist eine der größten Gefahren, wenn es um die Sicherheit von Webanwendungen geht. Entsprechende Aufmerksamkeit sollten Unternehmen dieser Angriffsmöglichkeit widmen.
Wie gehen Sie eigentlich mit dem Thema SQL Injection und der dadurch entstehenden Gefahr für Ihre Webapplikationen um? Testen Sie Ihre Anwendungen wirklich ausreichend und aus allen denkbaren Angriffswinkeln?
Viele IT-Profis haben im Laufe der Zeit schon einige SQL-Injection-Schwachstellen in ihren Umgebungen entdeckt und danach Gegenmaßnahmen ergriffen. Anderen ist aber noch nicht einmal bewusst, dass es diese Lücken überhaupt gibt. Eine weitere Gruppe von Anwendern hat ein falsches Verständnis von Sicherheit, weil ihre Schwachstellenscanner eine Handvoll Sicherheitslücken entdeckt haben. Aber ist das alles?
In welcher Situation Sie auch immer sind, SQL Injection ist mit Sicherheit eine der gefährlichsten Bedrohungen im Web. Durch diese Lücken gelangen nicht nur sensible Informationen aus Ihren Datenbanken in die falschen Hände, sie gefährden auch Ihr gesamtes Geschäft, wenn sie nicht schnellstmöglich geschlossen werden.
Datendiebstahl dank SQL Injection
Sicherheitsstudien haben bereits mehrfach belegt, dass Angriffe via SQL Injection nicht nur zu den bedeutendsten Schwachstellen im Web gehören, sondern dass sie auch der wichtigste Vektor für darauffolgende Datendiebstähle sind. In meiner täglichen Arbeit als Sicherheitsspezialist begegnen sie mir sehr häufig. Von jeweils etwa zehn Anwendungen, die ich teste, finde ich in zwei oder drei von ihnen mindestens eine SQL-Injection-Schwachstelle. Das mag auf den ersten Blick nicht als viel erscheinen, aber wenn es um diese Angriffe geht und weil ja auch die Zeit den Kriminellen in die Hände spielt, sollten Sie sich lieber nicht zu sehr auf diese vermeintlich niedrigen Zahlen stützen.
SQL-Injection-Schwachstellen treten an vielen Stellen auf. So stößt man auf sie Anwendungen, die zum Beispiel von den wichtigsten, direkt mit dem Internet verbundenen Business-Applikationen reichen, bis zum Web-Interface eines internen Management-Systems für VoIP-Anrufe (Voice over IP). Man könnte es auch so sehen: Sobald eine Anwendung komplex genug ist, ihre Daten in einer Datenbank zu verwalten, ist sie bereits ein lohnendes Ziel für Angriffe. Das bedeutet, dass alle datenbankgestützten Systeme von IoT-Devices (Internet of Things), über CMS (Content Management System) bis zu ERP-Anwendungen (Enterprise Resource Planning) das Opfer einer erfolgreichen SQL-Injection-Attacke werden können.
Wie SQL-Injection-Schwachstellen entstehen
SQL-Injection-Schwachstellen entstehen meist wegen einem der folgenden Probleme:
- Wegen dem verbreiteten Mangel an sicheren Methoden beim Entwickeln von Anwendungen. Beispiele für diese sicheren Methoden sind Input Validierung und der Einsatz von vordefinierten Prozessen.
- Wegen nicht ausreichenden oder sogar gar nicht durchgeführten Schwachstellen- und Penetrationstests.
- Und wegen einem Mangel an Verständnis in der Geschäftsführung für die Probleme. Oder aber auch nur, weil die IT-Mitarbeiter die Risiken durch SQL Injection nicht ausreichend im Unternehmen kommuniziert haben.
Anders als bei manchen anderen Schwachstellen sind SQL-Injection-Lücken sofort ein schlechtes Zeichen, wo auch immer sie anzutreffen sind. Ohne eine gründliche Analyse der Zusammenhänge und der Bedeutung eines durch SQL-Injection gefährdeten Systems, können Sie sich sehr sicher sein, dass dort bald schlimme Dinge passieren werden.
Das trifft sogar auf Anwendungen zu, die auf den ersten Blick nur gute Eigenschaften haben. Nicht nur ist es dann möglich, dass Fremde auf Einträge in Ihren Datenbanken zugreifen können oder dass eine komplette Datenbank gelöscht wird. SQL-Injection-Attacken können auch deutlich weiterreichende Folgen haben, wenn sie einem Angreifer etwa den vollen Zugriff auf betroffene Systeme aus der Ferne erlauben. SQL-Injection-Schwachstellen können also dazu führen, dass ein Angreifer sich zunächst in einem einzelnen System in einem Teil eines Firmennetzes festsetzt und von dort aus weiter in die jeweilige Umgebung eindringt.
Abbildung 1: Der Webschwachstellenscanner Netsparker kann SQL-Injection-Sicherheitslücken finden und demonstrieren, wie dazu passende Exploits funktionieren.
Der wichtigste Aspekt beim Umgang mit einer SQL-Schwachstelle ist, sie erst einmal aufzudecken. Das erfordert gut geplante und gründlich durchgeführte Schwachstellen- und Penetrationtests sowie dazu geeignete Werkzeuge. Abbildung 1 zeigt, wie das Tool Netsparker SQL-Injection-Schwachstellen findet und wie es ihre Auswirkungen demonstriert.
Abbildung 2 zeigt, dass der Acunetix Web Vulnerability Scanner mehrere Seiten und Parameter mit SQL-Injection-Schwachstellen gefunden hat. Auf dem Markt gibt es noch viele weitere Scanner für Webschwachstellen und zur Analyse des Quellcodes, mit denen sich ebenfalls SQL-Injection-Lücken entdecken lassen.
Im Großen und Ganzen habe ich bei ihrer Anwendung aber herausgefunden, dass man dabei immer nur genau das bekommt, für das man auch wirklich bereit ist, zu zahlen.
Abgesehen von diesem Punkt sollten Sie unbedingt mehrere Webschwachstellenscanner einsetzen. Das lässt sich einfach nicht vermeiden. Und wenn auch Quellcode untersucht werden soll, dann sollten Sie auch hier ebenfalls auf mehrere Analyzer setzen. Mit praktisch einhundert Prozent Wahrscheinlichkeit kann nämlich kein einzelnes Tool alle Schwachstellen aufspüren, die Sie kennen sollten. Dazu zählen natürlich auch SQL-Injection-Sicherheitslücken. Wenn Sie eine dieser Schwachstellen gefunden haben und sie nun ausgiebiger testen wollen, dann gibt es zu diesem Zweck auch mehrere kostenlose Programme wie den SQL Power Injector, sqlmap und die Firefox-Erweiterung SQL Inject Me.
Aber egal, welche Tools Sie einsetzen, sollten Sie Ihre Tests darüber hinaus einmal als externer Nutzer ohne Authentifizierung und zudem als eingeloggter interner Anwender durchführen. SQL-Injection-Angriffe können durch bekannte, aber böswillige Nutzer oder durch externe Cyberkriminelle ausgeführt werden, die Nutzerdaten gestohlen haben.
Die OWASP Top 10 ist eine Liste aktueller Sicherheitsrisiken, die für viele IT-Abteilungen eine unschätzbare Hilfe ist. Sie ist eine der wichtigsten Quellen im Bereich Application Security ist, die für den gesamten Lebenszyklus von Anwendungen eine Bedeutung hat. Nützlich sind außerdem die Standards des NIST (National Institute of Standards and Technology), die Frameworks ISO/IEC 2700X und andere Quellen, die in der Praxis genutzt werden können. Handlungsempfehlungen entwickelt in Deutschland auch das Cyber-Abwehrzentrum (Cyber-AZ) des Bundesamts für Sicherheit in der Informationstechnik (BSI). Dort können sich zum Beispiel alle Bundesbehörden miteinander austauschen, die sich mit dem Thema IT-Sicherheit befassen. Dazu kommen weitere Initiativen des BSI wie das IT-Lagezentrum und das IT-Krisenreaktionszentrum, die sich ebenfalls mit den strategischen Zielen Prävention, Detektion und Reaktion befassen.
Zusätzlich zu dem dadurch vermittelten Wissen benötigen IT-Abteilungen jedoch auch viel Disziplin, um bestehende Schwachstellen wie SQL Injection in ihren Systemen auch wirklich zu finden und um sie schnellstmöglich zu beheben – bevor sie gegen das jeweilige Unternehmen eingesetzt werden können. Das Wesentliche ist dabei aber, zu verinnerlichen, dass alle Websysteme, seien es externe Entwicklungsumgebungen oder interne Server, regelmäßig auf SQL-Injection-Schwachstellen getestet werden müssen. Es ist absolut nicht möglich, etwas abzusichern, das man nicht ausreichend kennt.
Vorsichtsmaßnahmen treffen
Wenn Sie SQL Injection nicht mit in Ihre Überlegungen einbeziehen, dann können Sie auch nicht feststellen, ob das Thema für Sie ein Problem darstellt oder nicht. Das Prekäre an dieser Situation ist, dass Sie es möglicherweise erst dann erfahren, wenn jemand anderes eine Lücke in Ihren Systemen gefunden hat und sie nun zu seinem Vorteil ausnutzt. Erst dann haben Sie Gelegenheit, sich um die Schwachstelle zu kümmern. Eine Reaktion unter Stress und Druck ist aber niemals eine gute Idee. Seien Sie deswegen bereits im Vorfeld aktiv. Wenn Sie selbst nicht für das Entwickeln der Webanwendungen oder für die Security-Tests verantwortlich sind, dann sprechen Sie zumindest die Zuständigen in Ihrem Unternehmen darauf an und erkundigen Sie sich, welche Schritte sie eingeleitet haben, um die Risiken zu senken.
Wenn Sie zudem die Entwicklung Ihrer Webapplikationen und das Hosting auslagern, dann vertrauen Sie niemals darauf, dass der Anbieter in jedem Fall sicheren Code produziert und dass er auch wirklich alle notwendigen Schritte unternimmt, um das Risiko einer SQL Injection zu minimieren.
Ein typisches Beispiel habe ich erst vor kurzem erlebt: Ich arbeitete mit einer Firma zusammen, die ihre Marketing-Webseite von einem darauf spezialisierten Anbieter aktualisieren ließ. Als ich die neue Seite testete, entdeckte ich jedoch mehrere SQL-Injection-Schwachstellen, von denen der Anbieter nicht nur nichts wusste, sondern die er auch nicht beheben konnte. Mein Kunde entschied sich daraufhin für einen anderen Anbieter. Wenn Sie in einer vergleichbaren Situation sind, sollten Sie denselben Weg wählen.
Der wichtigste Punkt beim Umgang mit SQL-Injection-Schwachstellen ist, dass Sie absolut niemals die Sicherheit Ihrer Webanwendungen außer Acht lassen dürfen. In Anbetracht der vermutlich hohen Zahl an Webdiensten, die Sie nutzen, und zudem dem, was für Ihr Unternehmen als Gesamtes auf dem Spiel steht, sollten Sie sich sobald wie möglich mit dem Thema beschäftigen. Sorgen Sie auch dafür, dass Sie regelmäßige Checks einplanen und Verbesserungen durchführen. Kleine, aber unerbittlich durchgeführte Schritte sind der Schlüssel zum Erfolg. Es wird zwar nicht immer möglich sein, auch wirklich alle SQL-Injection-Schwachstellen zu beheben, aber Sie können einiges unternehmen, um die gefundenen Lücken schnell und effektiv zu schließen.
Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!
