Feliz cumpleaños, la inyección de SQL, el error que no se puede solucionar

Eine Version dieses Artikels erschien ursprünglich in Hilfe Netzsicherheit. Er wurde aktualisiert und hier syndiziert.

‍

Wenn Sie in einer praktischen Cybersecurity-Rolle sind - eine, die eine gewisse Vertrautheit mit Code erfordert - stehen die Chancen gut, dass Sie über SQL-Injection nachdenken mussten... immer und immer wieder. Es ist eine weit verbreitete Schwachstelle, die trotz der Kenntnis ihrer recht einfachen Abhilfe innerhalb weniger Wochen nach der ersten Entdeckung weiterhin unsere Software plagt und Möchtegern-Angreifern ein kleines Zeitfenster bietet, wenn sie vor der Bereitstellung unentdeckt bleibt.

Der 13. Dezember 2020 markiert den 22. Geburtstag von SQL Injection, und obwohl diese Schwachstelle alt genug ist, um sie zu trinken, lassen wir sie über uns ergehen, anstatt sie für immer zu zerquetschen. Im August dieses Jahres gab die Firma Freepik bekannt, dass sie Opfer eines SQL-Injection-Fehlers geworden war, der die Konten von 8,3 Millionen Benutzern kompromittierte. Während einige von ihnen Logins von Drittanbietern (z. B. Google, Facebook) nutzten, wurden bei einigen Millionen unverschlüsselte Passwörter zusammen mit ihrem Benutzernamen offengelegt. Zum Leidwesen dieser und vieler anderer Nutzer bereiten die Folgen dieser Vorfälle großes Kopfzerbrechen, und es ist ein langfristiger Prozess, das Vertrauen der Nutzer wiederherzustellen.

Während wir diesen Meilenstein mit einem Problem "feiern", das als altbekannt gilt, lassen Sie uns das Problem einen Moment lang sezieren. Warum taucht es immer wieder auf, warum ist es immer noch so gefährlich, dass es seit Jahren an der Spitze der OWASP Top 10 steht, und warum schafft es seine relativ einfache Behebung nicht in die allgemeinen Benchmark-Standards für die Softwareentwicklung?

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

Ein kurzer Blick auf die jüngste hochkarätige Sicherheitsverletzung, den verheerenden Cyberangriff auf FireEye, offenbart ein erstaunliches Maß an Raffinesse: Es handelte sich um einen hochgradig koordinierten, nationalstaatlichen Angriff, bei dem eine breite Palette fortschrittlicher Techniken zum Einsatz kam, die anscheinend für einen FireEye-Raub maßgeschneidert wurden.In einer Erklärung sagte FireEye-CEO Kevin Mandia

"Die Angreifer haben ihre Weltklasse-Fähigkeiten speziell auf FireEyezugeschnitten und angegriffen. Sie sind hochgradig in operativer Sicherheit geschult und haben diszipliniert und fokussiert agiert ... sie verwendeten eine neuartige Kombination von Techniken, die wir oder unsere Partner in der Vergangenheit nicht gesehen haben.”

Das ist ein Alptraum für jeden CISO, und wenn so etwas FireEye passieren kann, dann relativiert das, wie verwundbar viele Unternehmen wirklich sind.

... außer, dass es noch schlimmere Nachrichten für die durchschnittliche Organisation sind. FireEye ist eine der renommiertesten Cybersecurity-Firmen der Welt, und der erfolgreiche Angriff auf sie erforderte, dass Gauner auf Mastermind-Niveau alles, was sie hatten, in eine koordinierte, groß angelegte Ausführung stecken. Für viele Unternehmen könnte ein lukrativer Datenverlust durch das Ausnutzen eines einfachen Fehlers möglich sein, und zwar ziemlich schnell, ohne dass ein Superhirn benötigt wird. Und SQL-Injection ist ein gängiges Beispiel für Letzteres, das immer noch von Skript-Kiddies ausgenutzt wird, die im Dark Web das schnelle Geld machen wollen.

Im Mai 2020 wurde ein Mann wegen Kreditkartenhandels und Hacking-Delikten angeklagt, als man bei ihm digitale Medien mit Hunderttausenden von aktiven Kreditkartennummern fand. Er sammelte sie alle mit SQL-Injection-Techniken, in einer Operation, die viele Unternehmen und Millionen ihrer Kunden kompromittierte.

Als Branche verbessern wir uns ständig, aber SQL-Injection ist immer noch eine erhebliche Bedrohung und betrifft weit mehr als veraltete oder ungepatchte Systeme.

Warum die 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 sie gar nicht erst eingeführt wird. Wie die meisten Dinge ist es nur dann einfach, wenn man gelernt hat, wie man es richtig macht.

Hier beginnt das Rad im Softwareentwicklungsprozess zu wackeln. Die Entwickler machen immer wieder die gleichen Fehler, was dazu führt, dass immer wieder Schwachstellen wie SQL-Injection in eine Codebasis eingeschleust werden. Dies sollte jedoch nicht überraschen. Die meisten Ingenieure schließen ihr Studium ab, ohne viel über sichere Codierung gelernt zu haben, wenn überhaupt etwas. Die meisten Schulungen am Arbeitsplatz sind unzureichend, insbesondere in einer Umgebung, in der Sicherheit nicht als geschäftliche Priorität in ihrer Rolle gesehen wird.

Wir geben Entwicklern weder einen Grund, sich um Sicherheit zu kümmern, noch eine starke Plattform, um sicherheitsbewusster zu werden. Schlechte Codierungsmuster halten Bugs wie SQL-Injection am Leben und wir müssen mehr Wert auf das Sicherheitsbewusstsein der Entwickler legen und ihnen die Zeit geben, einen höheren Standard an sicherem, qualitativ hochwertigem Code zu schreiben. Das Schreiben von sicheren Codierungsmustern kann länger dauern, aber die dafür aufgewendete Zeit schafft Effizienzgewinne, die später im Prozess von unschätzbarem Wert sind.

Wird es jemals ein SQL-Injection-Begräbnis geben?

Eine Beerdigungsmetapher ist ein wenig morbide, aber wirklich, unsere sensiblen Daten wären sicherer, wenn SQL-Injection für immer zur Ruhe gelegt würde. Ich bin jedoch sehr zuversichtlich, dass wir noch ein paar Geburtstage feiern werden, bevor es so weit ist, denn die Kultur rund um präventive Sicherheit und die Betonung von sicherem Coding hat sich einfach nicht genug entwickelt, um den Sarg zuzunageln.

Neuere, sicherere Sprachen wie Rust helfen dabei, einige der Fehler auszumerzen, mit denen wir uns lange Zeit herumgeschlagen haben, indem sie sicherere Funktionen verwenden, aber es gibt eine enorme Menge an Legacy-Software, älteren Systemen und Bibliotheken, die weiterhin im Einsatz bleiben und potenziell angreifbar sind.

Die gemeinsame Verantwortung für die Sicherheit im Entwicklungsprozess (hallo, DevSecOps) wird entscheidend sein, wenn wir wollen, dass "einfache" Exploits für immer ausgeschaltet werden. Entwickler müssen von Anfang an mit auf die Reise genommen werden und dabei unterstützt werden, die Verantwortung für ihren Teil bei der Erstellung von sicherem, besserem Code zu übernehmen.

Wie sollten Entwickler vorgehen, um einen SQL-Injection-Bug in ihrem Code zu beheben?

Wir haben einen umfassenden Leitfaden für Entwickler zusammengestellt, die lernen wollen, wie man SQL-Injection erkennt und behebt. Komplett mit einer spielerischen Herausforderung in der Programmiersprache ihrer Wahl (sogar COBOL!), bietet dies einige großartige grundlegende Lerninhalte, die jedem Entwickler helfen werden, sichereren, qualitativ hochwertigeren Code zu erstellen.