Alles Gute zum Geburtstag, SQL-Injection – der Fehler, der einfach nicht totzukriegen ist

Eine Version dieses Artikels erschien ursprünglich bei Help Net Security. Er wurde aktualisiert und hier erneut veröffentlicht.

‍

Wenn Sie in einer praktischen Rolle in der Cybersicherheit tätig sind – einer, die ein gewisses Verständnis für Code erfordert –, ist die Wahrscheinlichkeit groß, dass Sie sich schon oft mit SQL-Injection auseinandersetzen mussten. Es handelt sich um eine weit verbreitete Schwachstelle, die unsere Software trotz der Tatsache, dass ihre recht einfache Lösung nur wenige Wochen nach ihrer ersten Entdeckung bekannt war, weiterhin plagt und Angreifern ein kleines Zeitfenster bietet, falls sie vor der Bereitstellung nicht erkannt wird.

Am 13. Dezember 2020 feierte SQL-Injection seinen 22. Geburtstag. Obwohl diese Schwachstelle alt genug ist, um Alkohol zu trinken, lassen wir uns immer noch von ihr in die Enge treiben, anstatt sie ein für alle Mal auszumerzen. Im August dieses Jahres gab die Freepik Company bekannt, dass sie Opfer eines SQL-Injection-Fehlers geworden ist, der die Konten von 8,3 Millionen Nutzern gefährdete. Während einige von ihnen Drittanbieter-Logins (z. B. Google, Facebook) nutzten, wurden bei einigen Millionen Nutzern unverschlüsselte Passwörter zusammen mit ihren Benutzernamen offengelegt. Leider sind die Folgen dieser Vorfälle für sie und viele andere ein riesiges Ärgernis, und der Wiederaufbau des Vertrauens bei der Nutzerbasis ist ein langwieriger Prozess.

Während wir diesen Meilenstein mit einem Problem „feiern“, das als Altlast gilt, lassen Sie uns das Ganze kurz analysieren. Warum taucht es immer wieder auf, warum ist es so gefährlich, dass es seit Jahren unangefochten an der Spitze der OWASP Top 10 steht, und warum schafft es die relativ einfache Lösung nicht in die allgemeinen Standards für die Softwareentwicklung?

Warum ist SQL-Injection im Jahr 2021 immer noch relevant?

Ein kurzer Blick auf einen kürzlich bekannt gewordenen, hochkarätigen Vorfall, den verheerenden Cyberangriff auf FireEye, offenbart ein erschreckendes Maß an Raffinesse: Es handelte sich um einen hochgradig koordinierten Angriff eines Nationalstaates, bei dem eine Vielzahl fortschrittlicher Techniken zum Einsatz kam, die speziell auf den Raubzug bei FireEye zugeschnitten zu sein schienen. In einer Stellungnahme sagte FireEye-CEO Kevin Mandia:

„Die Angreifer haben ihre erstklassigen Fähigkeiten speziell darauf ausgerichtet, FireEye anzugreifen. Sie sind in operativer Sicherheit hochgradig geschult und gingen diszipliniert und fokussiert vor... sie nutzten eine neuartige Kombination von Techniken, die wir oder unsere Partner in der Vergangenheit noch nicht gesehen haben.“

Das ist ein Albtraumszenario für jeden CISO. Wenn so etwas bei FireEye passieren kann, verdeutlicht das, wie verwundbar viele Unternehmen tatsächlich sind.

… nur ist es für das durchschnittliche Unternehmen sogar noch schlimmer. FireEye ist eines der renommiertesten Cybersicherheitsunternehmen der Welt, und der erfolgreiche Angriff erforderte kriminelle Superhirne, die bei einer koordinierten Großaktion alles aufboten, was sie hatten. Für viele Unternehmen könnte ein lukrativer Datendiebstahl jedoch schon durch die Ausnutzung eines einfachen Fehlers möglich sein – und zwar ziemlich schnell, ganz ohne Superhirn. SQL-Injection ist ein klassisches Beispiel für Letzteres und wird immer noch von Skript-Kiddies genutzt, die im Dark Web das schnelle Geld machen wollen.

Im Mai 2020 wurde ein Mann wegen Kreditkartenbetrugs und Hacking-Delikten angeklagt, als bei ihm digitale Datenträger mit Hunderttausenden aktiven Kreditkartennummern gefunden wurden. Er hatte sie alle mithilfe von SQL-Injection-Techniken erbeutet – in einer Operation, die viele Unternehmen und Millionen ihrer Kunden betraf.

Als Branche verbessern wir uns ständig, aber SQL-Injection bleibt eine erhebliche Bedrohung, die weit mehr als nur veraltete oder ungepatchte Systeme betrifft.

Warum Entwickler es am Leben erhalten (und warum es nicht ihre Schuld ist)

Wir sagen immer wieder, dass SQL-Injection einfach zu beheben ist und Code so geschrieben werden sollte, dass er gar nicht erst entsteht. Wie bei den meisten Dingen ist es nur dann einfach, wenn man gelernt hat, wie es richtig geht.

Genau hier gerät der Prozess der Softwareentwicklung ins Stocken. Entwickler machen dieselben Fehler, was dazu führt, dass wiederkehrende Schwachstellen wie SQL-Injection in eine Codebasis gelangen. Das sollte jedoch nicht überraschen. Die meisten Ingenieure schließen ihr Studium ab, ohne viel über sicheres Programmieren gelernt zu haben, wenn überhaupt. Die meisten internen Schulungen sind unzureichend, insbesondere in einem Umfeld, in dem Sicherheit in ihrer Rolle nicht als geschäftliche Priorität angesehen wird.

Wir geben Entwicklern weder einen Grund, sich um Sicherheit zu kümmern, noch eine solide Grundlage, um ein besseres Sicherheitsbewusstsein zu entwickeln. Schlechte Programmiermuster halten Fehler wie SQL-Injection am Leben. Wir müssen das Sicherheitsbewusstsein der Entwickler stärker fördern und ihnen die Zeit geben, qualitativ hochwertigen und sicheren Code zu schreiben. Sichere Programmiermuster zu schreiben kann zwar länger dauern, aber die investierte Zeit schafft Effizienzen, die später im Prozess von unschätzbarem Wert sind.

Wird es jemals eine Beerdigung für SQL-Injection geben?

Die Metapher einer Beerdigung ist etwas makaber, aber unsere sensiblen Daten wären tatsächlich sicherer, wenn SQL-Injection ein für alle Mal beerdigt würde. Ich bin jedoch sehr zuversichtlich, dass wir noch einige Geburtstage feiern werden, bevor es so weit ist, denn die Kultur rund um präventive Sicherheit und die Betonung von sicherem Programmieren hat sich einfach noch nicht weit genug entwickelt, um den Sarg endgültig zu schließen.

Neuere, sicherere Programmiersprachen wie Rust tragen dazu bei, einige der altbekannten Fehler durch die Nutzung sicherer Funktionen auszumerzen. Dennoch gibt es eine enorme Menge an Legacy-Software, älteren Systemen und Bibliotheken, die weiterhin im Einsatz bleiben und potenziell anfällig sind.

Die gemeinsame Verantwortung für Sicherheit im Entwicklungsprozess (Stichwort: DevSecOps) ist entscheidend, wenn wir „einfache“ Exploits endgültig unterbinden wollen. Entwickler müssen von Anfang an eingebunden und dabei unterstützt werden, Verantwortung für ihren Beitrag zu sicherem und besserem Code zu übernehmen.

Wie sollten Entwickler bei der Behebung einer SQL-Injection-Schwachstelle in ihrem Code vorgehen?

Wir haben einen umfassenden Leitfaden für Entwickler zusammengestellt, die lernen möchten, wie man SQL-Injections erkennt und behebt. Mit einer spielerischen Challenge in der Programmiersprache ihrer Wahl (sogar COBOL!) bietet dies eine hervorragende Grundlage, die jedem Entwickler hilft, sichereren und qualitativ hochwertigeren Code zu schreiben.