Alles Gute zum Geburtstag SQL Injection, der Fehler, der nicht behoben werden kann
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.
Es ist 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.
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior 您的Secure Code Warrior 帮助您在整个软件开发周期中保障代码安全，并建立将网络安全置于首位的企业文化。无论您是应用安全经理、开发人员、首席信息安全官，还是其他从事安全工作的人员，我们都能协助您的企业降低不安全代码带来的风险。
预约演示
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in 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 verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit 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 an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
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.
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.
请点击下方链接下载该资源的PDF文件。
Secure Code Warrior 您的Secure Code Warrior 帮助您在整个软件开发周期中保障代码安全，并建立将网络安全置于首位的企业文化。无论您是应用安全经理、开发人员、首席信息安全官，还是其他从事安全工作的人员，我们都能协助您的企业降低不安全代码带来的风险。
查看报告预约演示
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in 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 verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit 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 an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
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.
目录
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior 您的Secure Code Warrior 帮助您在整个软件开发周期中保障代码安全，并建立将网络安全置于首位的企业文化。无论您是应用安全经理、开发人员、首席信息安全官，还是其他从事安全工作的人员，我们都能协助您的企业降低不安全代码带来的风险。
预约演示下载入门资源
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText 应用程序安全性的强大功能 + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
