Herzlichen Glückwunsch zum Geburtstag SQL-Injection, der Fehler, der nicht ausgemerzt werden kann
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.
Es ist der 22. Geburtstag von SQL Injection, und obwohl diese Schwachstelle alt genug ist, um zu trinken, lassen wir sie über uns ergehen, anstatt sie für immer zu beseitigen.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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.
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.
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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.
Inhaltsübersicht
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Quests: Branchenführendes Lernen, damit die Entwickler immer einen Schritt voraus sind und Risiken minimiert werden.
Quests ist eine learning platform , die Entwicklern hilft, Software-Sicherheitsrisiken zu verringern, indem sie ihre Fähigkeiten zur sicheren Programmierung verbessern. Mit kuratierten Lernpfaden, praktischen Herausforderungen und interaktiven Aktivitäten befähigt sie Entwickler, Schwachstellen zu erkennen und zu vermeiden.
Ressourcen für den Einstieg
Das Jahrzehnt der Defenders: Secure Code Warrior Zehnte Runde
Secure Code WarriorDas Gründungsteam von SCW ist zusammengeblieben und hat das Schiff ein ganzes Jahrzehnt lang durch alle Lektionen, Triumphe und Rückschläge gesteuert. Wir vergrößern uns und sind bereit für unser nächstes Kapitel, SCW 2.0, als führendes Unternehmen im Risikomanagement für Entwickler.
10 wichtige Vorhersagen: Secure Code Warrior über den Einfluss von KI und Secure-by-Design im Jahr 2025
Unternehmen stehen vor schwierigen Entscheidungen über den Einsatz von KI, um die langfristige Produktivität, Nachhaltigkeit und den Sicherheits-ROI zu unterstützen. In den letzten Jahren ist uns klar geworden, dass KI die Rolle des Entwicklers niemals vollständig ersetzen wird. Von KI + Entwicklerpartnerschaften bis hin zum zunehmenden Druck (und der Verwirrung) rund um die Secure-by-Design-Erwartungen - lassen Sie uns einen genaueren Blick darauf werfen, was wir im nächsten Jahr erwarten können.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
