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 . 앱 보안 관리자, 개발자, 최고정보보안책임자(CISO) 또는 보안 관련 업무를 담당하는 분이라면 누구든, 저희는 귀사가 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기
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 . 앱 보안 관리자, 개발자, 최고정보보안책임자(CISO) 또는 보안 관련 업무를 담당하는 분이라면 누구든, 저희는 귀사가 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
보고서 보기데모 예약하기
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 . 앱 보안 관리자, 개발자, 최고정보보안책임자(CISO) 또는 보안 관련 업무를 담당하는 분이라면 누구든, 저희는 귀사가 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기다운로드시작을 위한 자료
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.
