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

Eine Version dieses Artikels erschien ursprünglich in Hilfe | Net Security. Es wurde hier aktualisiert und syndiziert.

‍

Wenn Sie in einer praktischen Rolle im Bereich Cybersicherheit tätig sind — eine Rolle, die eine gewisse Vertrautheit mit Code erfordert — stehen die Chancen gut, dass Sie über SQL-Injection nachdenken mussten... immer und immer wieder. Es handelt sich um eine weit verbreitete Sicherheitslücke, die, obwohl wir wissen, dass sie innerhalb weniger Wochen nach der ersten Entdeckung relativ einfach behoben werden kann, unsere Software weiterhin plagt und potenziellen Angreifern ein kleines Zeitfenster bietet, wenn sie vor der Bereitstellung unentdeckt bleibt.

Am 13. Dezember 2020 jährte sich der 22. Geburtstag von SQL Injection, und obwohl diese Sicherheitslücke alt genug ist, um sie zu trinken, lassen wir uns von ihr überwältigen, anstatt sie endgültig zu zerquetschen. Im August dieses Jahres gab Freepik Company bekannt, dass sie ist einem SQL-Injection-Fehler zum Opfer gefallen das kompromittierte die Konten von 8,3 Millionen Nutzern. Während einige von ihnen Drittanbieter-Logins nutzten (z. B. Google, Facebook), waren bei einigen Millionen unverschlüsselte Passwörter zusammen mit ihrem Nutzernamen offengelegt worden. Leider bereiten ihnen und vielen anderen die Folgen dieser Vorfälle große Kopfschmerzen, und der Wiederaufbau des Vertrauens in die Nutzerbasis ist ein langfristiger Prozess.

Wir „feiern“ diesen Meilenstein zwar mit einem Thema, das als Altlast angesehen wird, aber lassen Sie uns ihn für einen Moment analysieren. Warum taucht es immer wieder auf, warum ist es immer noch so gefährlich, dass es seit Jahren nicht mehr von der Spitze der OWASP Top 10 herausgekommen ist, und warum schafft es seine relativ einfache Lösung nicht in die allgemeinen Benchmark-Standards für Softwareentwicklung?

Warum ist SQL Injection 2021 immer noch relevant?

Ein kurzer Blick auf einen kürzlich aufsehenerregenden Verstoß, den verheerender Cyberangriff auf FireEye, zeigt ein erstaunliches Maß an Raffinesse: Es war ein hochkoordinierter, nationalstaatlicher Angriff, bei dem eine Vielzahl fortschrittlicher Techniken zum Einsatz kam, die für einen FireEye-Überfall maßgeschneidert zu sein schienen. In einer Erklärung sagte Kevin Mandia, CEO von FireEye:

“Die Angreifer haben ihre erstklassigen Fähigkeiten speziell auf Ziele zugeschnitten und Attacke FireEye. Sie sind in Sachen Betriebssicherheit bestens geschult und werden mit Disziplin und Konzentration ausgeführt... sie verwendeten eine neuartige Kombination von Techniken, die wir oder unsere Partner in der Vergangenheit nicht kannten.“

Das ist ein Albtrauminhalt für jeden CISO, und wenn FireEye so etwas passieren kann, dann wird dadurch ins rechte Licht gerückt, wie verwundbar viele Unternehmen wirklich sind.

... außer, es ist sogar schlechter Neuigkeiten für ein durchschnittliches Unternehmen. FireEye ist eines der bekanntesten Cybersicherheitsunternehmen der Welt, und für den erfolgreichen Angriff auf das Unternehmen waren Gauner auf Mastermind-Ebene gefragt, die alles, was sie hatten, in einer koordinierten, groß angelegten Ausführung warfen. Für viele Unternehmen könnte eine lukrative Datenschutzverletzung möglich sein, indem sie einen einfachen Bug ziemlich schnell ausnutzen, ohne dass ein Mastermind erforderlich ist. Und SQL-Injection ist ein gängiges Beispiel für Letzteres. Es wird immer noch von Script-Kiddies genutzt, die im Dark Web schnell Geld verdienen wollen.

Im Mai 2020, ein Mann wurde wegen Kreditkartenhandels und Hackerdelikten angeklagt, als bei ihm digitale Medien gefunden wurden, auf denen Hunderttausende von aktiven Kreditkartennummern gespeichert waren. Er sammelte sie alle mithilfe von SQL-Injection-Techniken ab, ein Vorgang, der viele Unternehmen und Millionen ihrer Kunden gefährdete.

Als Branche sind wir sind Es verbessert sich ständig, aber SQL-Injection ist immer noch eine erhebliche Bedrohung und betrifft weit mehr als ältere oder ungepatchte Systeme.

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 überhaupt nicht eingeführt wird. Wie bei den meisten Dingen ist es nur einfach, wenn Ihnen beigebracht wurde, wie man es richtig macht.

Hier beginnt das Rad im Softwareentwicklungsprozess zu wackeln. Entwickler machen dieselben Fehler, was zu wiederkehrenden Sicherheitslücken wie der Infiltrierung einer Codebasis durch SQL-Injection führt. Dies sollte jedoch keine Überraschung sein. Die meisten Ingenieure schließen ihr Studium ab, ohne viel über sicheres Programmieren gelernt zu haben, wenn überhaupt. Die meisten Schulungen am Arbeitsplatz sind unzureichend, insbesondere in einem Umfeld, in dem Sicherheit in ihrer Rolle nicht als Geschäftspriorität angesehen wird.

Wir geben Entwicklern keinen Grund, sich Gedanken über Sicherheit zu machen, und auch keine starke Plattform, auf der sie anfangen können, sicherheitsbewusster zu werden. Schlechte Codierungsmuster halten Bugs wie die 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 damit verbrachte Zeit führt zu Effizienzgewinnen, die sich später im Prozess von unschätzbarem Wert erweisen.

Wird es jemals eine SQL-Injection-Beerdigung geben?

Eine Begräbnismetapher ist ein bisschen morbid, aber in Wirklichkeit wären unsere sensiblen Daten sicherer, wenn die SQL-Injektion endgültig zum Erliegen käme. Ich bin jedoch sehr zuversichtlich, dass wir noch ein paar Geburtstage feiern werden, bevor es soweit ist, denn die Kultur rund um präventive Sicherheit und die Betonung der sicheren Codierung hat sich einfach nicht genug weiterentwickelt, um den Sarg zugenageln zu können.

Neuere, robustere Sprachen wie Rust tragen dazu bei, einige der Bugs zu beseitigen, mit denen wir uns seit langem befassen, indem sie sicherere Funktionen verwenden, aber es gibt eine enorme Menge an veralteter Software, älteren Systemen und Bibliotheken, die weiterhin verwendet werden und potenziell anfällig sein werden.

Die gemeinsame Verantwortung für die Sicherheit im Entwicklungsprozess (hallo, DevSecOps) wird entscheidend sein, wenn wir wollen, dass „einfache“ Exploits endgültig abgeschaltet werden. Entwickler müssen von Anfang an mit auf die Reise genommen und dabei unterstützt werden, Verantwortung für ihren Beitrag zur Erstellung von sichererem und besserem Code zu übernehmen.

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

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