NoSQL-Datenbanken werden immer beliebter. Es ist schwer, ihre Geschwindigkeit und Leichtigkeit im Umgang mit unstrukturierten Daten zu verleugnen, besonders wenn Entwicklerteams mit zunehmend agilen Methoden arbeiten.

Es dauert seine Zeit, bis Entwickler Schwachstellen und andere Herausforderungen in neuen Technologien ausmerzen können. Erst nachdem sie eine Zeit lang in Produktionsanwendungen eingesetzt wurde, beginnen Probleme an die Oberfläche zu sprudeln.

NoSQL-Datenbanken sind ähnlich. Es gibt wichtige Risiken, die Entwickler kennen sollten, damit sie ihre Anwendungen sicher halten können. Ein solches Risiko ist NoSQL-Injection.

Lassen Sie uns einen Blick darauf werfen, was NoSQL-Injection ist, welchen Schaden sie verursachen kann und wie man sie behebt:

NoSQL-Injektion verstehen

NoSQL-Injection wird durch viele der gleichen Injektionsschwachstellen wie XML- oder SQL-Injection verursacht.

NoSQL-Injection erlaubt es Angreifern, beliebige Befehle in eine NoSQL-Abfrage zu platzieren. Dadurch können sie Daten stehlen und sogar Änderungen an der Datenbank vornehmen, wenn ihre Berechtigungen hoch genug sind.

Wenn eine Anwendung benutzergesteuerte Daten direkt in einen NoSQL-Abfrageausdruck setzt, nehmen diese Ausdrücke oft Funktionen an oder haben eingebaute Operatoren, die manipuliert werden können, um Daten zu stehlen oder zu verändern. Und wenn so etwas in böswilliger Absicht ausgeführt wird, kann das schlimme Folgen haben.

MongoDB-Datenbanken sind eine der beliebtesten Spielwiesen, um diese Sicherheitslücke auszunutzen. "$ne: ""'ist der Operator, der in der SQL-Welt 1=1 entspricht. Ein Angreifer könnte also beispielsweise die Zeichen "$ne: ""' in die Felder für den Benutzernamen und das Passwort einer Benutzeroberfläche eingeben. Wenn der Code anfällig für NoSQL-Injection ist, sucht die Datenbank nach allen Datensätzen, bei denen Benutzername und Passwort nicht gleich einem leeren String sind. Mit anderen Worten: alle. Igitt.

Wenn diese Datenbank unverschlüsselt ist, könnte der Angreifer die Benutzernamen und Kennwörter jedes einzelnen Benutzers darin stehlen. Dazu gehören auch die Benutzernamen und Passwörter der Administratoren, wodurch sie einen All-Access-Pass für die gesamte Datenbank erhalten.

Angreifer versuchen oft, Werte einzuschleusen, die immer wahr sind. Ein weiterer häufiger Angriff besteht darin, bösartigen Code in Eigenschaften zu injizieren, die auf Funktionen gesetzt sind.

MongoDB verwendet z. B. eine Find-Funktion, die ein Objekt mit einer Eigenschaft namens $where annimmt. Die Eigenschaft "$where" wird auf eine Funktion gesetzt, die als wahr oder falsch ausgewertet werden soll. Wenn diese Funktion in irgendeiner Weise durch Benutzereingaben geändert wird, lauert dort wahrscheinlich eine NoSQL-Injektion.

Für einen schön detaillierten Blick auf die Feinheiten der NoSQL-Injektion, schauen Sie sich diesen InfoQ-Artikel an.

Wissen, warum NoSQL Injection gefährlich ist

NoSQL-Injection ist vor allem deshalb so gefährlich, weil sie noch nicht die Aufmerksamkeit der Sicherheitsgemeinde erhalten hat, die sie verdient.

Die Auswirkungen von NoSQL-Injection sind ähnlich wie bei der traditionellen SQL-Injection. Daten können gestohlen oder geändert werden, Konten können durch Datendiebstahl kompromittiert werden und, vielleicht am bösartigsten, Daten können komplett gelöscht werden, wenn ein Löschbefehl erfolgreich erteilt wird.

Die Quintessenz ist, dass MongoDB und andere NoSQL-Datenbank-Engines anfällig für Angriffe sind. "Kein SQL" bedeutet nicht, dass es keine Injektionen gibt.
Glücklicherweise nehmen einige in der Community dies zur Kenntnis und sprechen es aus. Mehr Entwickler müssen sich selbst weiterbilden, damit sie ihre Anwendungen vor wenig bekannten Bösewichten schützen können, die zu großen Kopfschmerzen führen können, wenn sie ausgenutzt werden.

NoSQL-Injection besiegen

NoSQL-Injection kann schwer zu besiegen sein. Leider gibt es nicht die Möglichkeit von parametrisierten Abfragen wie bei SQL-Injection. Es ist jedoch nicht unmöglich. Es gibt ein paar Optionen, die Ihnen helfen können:

• Fuzzers können als eine Methode zum Aufspüren von Schwachstellen verwendet werden. Obwohl, wie es bei vielen Dingen im Leben der Fall ist, kann der einfachste Ansatz der effektivste sein. Hier ist das gute alte Code-Review Ihr stärkster Verbündeter.
• Suchen Sie bei der Überprüfung des Codes nach möglichen Stellen, an denen Benutzereingaben den Wert eines Ausdrucks setzen oder eine Funktion ändern könnten. Lassen Sie nicht zu, dass Benutzereingaben Ihre Abfragen ändern.
• Vergewissern Sie sich, dass die Benutzereingabe in ihre richtige Klasse umgewandelt wird. Wenn es eine Zahl ist, wandeln Sie sie in eine Zahl um, wenn es eine Zeichenkette ist, wandeln Sie sie in eine Zeichenkette um und so weiter.
• Verwenden Sie niemals $where oder ähnliche eval-Funktionen zusammen mit Benutzereingaben. In den meisten Fällen können Sie das Problem umgehen, indem Sie das Datenmodell oder Schema ändern.
• Versuchen Sie, Mongoose als Ihren MongoDB-Treiber zu verwenden. Mongoose ermöglicht es Ihnen, ein Schema für Ihre NoSQL-Datenbank zu definieren. Wenn Sie Mongoose mitteilen, dass Ihre Eingaben Zeichenketten sind, werden diese in Zeichenketten umgewandelt. Alle Objekte, die von einem Angreifer übergeben werden, werden also nicht als Objekte, sondern als Strings behandelt.
• Härten Sie Ihre DB! Legen Sie Benutzerkonten mit geringen Rechten an, maximieren Sie die Ausführungszeit für Abfragen und befolgen Sie stets die für Ihr Unternehmen geltenden bewährten Sicherheitsverfahren.

Ein Nachteil der Benutzerfreundlichkeit von NoSQL-Datenbanken ist die Tendenz von Entwicklern, sie einfach aufzustellen und zu benutzen, ohne an die Sicherheit zu denken.

Es ist wichtig, dass Sie sich die Zeit nehmen, um zu lernen, wie man eine NoSQL-Datenbank sicher aufbaut und sich vor NoSQL-Injections schützt.

Die MongoDB Enterprise Edition verfügt beispielsweise über erweiterte Funktionen zur Zugriffskontrolle. Die Durchsetzung von "Least Privilege" kann eine gute Defense in Depth (DiD)-Strategie sein, für den Fall, dass jemand eine Schwachstelle in Ihrer Anwendung findet.

Zusammenfassend lässt sich sagen, was wir haben:

• Bereinigen Sie Ihre Eingaben, bevor Sie sie in einem NoSQL-Abfrageausdruck verwenden
• Verwenden Sie Treiber, die Ihnen helfen, wie Mongoose
• Durchführung von Code-Reviews, die speziell die Verwendung von Eingabedaten in Abfragen untersuchen
• Verwenden Sie Fuzzers und Scanner, um Schwachstellen in Ihrem Code zu finden.

NoSQL ist nicht No Injections

NoSQL-Datenbanken erfreuen sich aufgrund ihrer skalierbaren Funktionen und der Geschwindigkeit der Einrichtung schnell wachsender Beliebtheit. Die Neuheit der Technologie kann Entwickler dazu verleiten, NoSQL-Datenbanken zu verwenden, ohne sich Gedanken über deren Absicherung zu machen.

NoSQL-Datenbanken können für Injection-Attacken genauso anfällig sein wie SQL-Datenbanken, also handeln Sie mit Vorsicht und achten Sie auf Ihre Abfragen. Wenn Sie mehr erfahren möchten, sehen Sie sich unsere Lernressourcen an oder testen Sie Ihre Kenntnisse mit unserer kostenlosen Demo.

Bereiten Sie sich im Voraus vor und Sie müssen sich keine Sorgen mehr über NoSQL-Injections in Ihren Anwendungen machen. Zu einfach!

Denken Sie, Sie sind bereit, NoSQL-Injektionen sofort zu lokalisieren, zu identifizieren und zu beheben? Betreten Sie die sichere Code-Arena, Krieger:

Und das ist ein Wrap für 2018! Dies wird unser letzter Beitrag für dieses Jahr sein, aber wir werden am 10. Januar 2019 mit dem nächsten Coders Conquer Security Guide zurück sein. Bis bald!

Im Gegensatz zu Angriffen, die direkt auf Website- oder Anwendungsbetreiber abzielen, besteht das Ziel vieler Cross-Site Request Forgery (CSRF)-Angriffe darin, Geld, Waren oder Anmeldedaten direkt von einem Benutzer zu stehlen. Das bedeutet nicht, dass Website-Betreiber CSRF-Code-Schwachstellen ignorieren sollten, da der Ersatz der gestohlenen Gelder im Falle eines rein monetären Angriffs letztlich in der Verantwortung der Hosting-Site mit dem unsicheren Code liegen kann. Und wenn der angegriffene Benutzer stattdessen seine Anmeldedaten verliert oder sein Passwort unwissentlich ändert, kann ein Krimineller mit der gestohlenen Identität Schaden anrichten, insbesondere wenn das Opfer privilegierten Zugang hat.

CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, es müssen viele Dinge zugunsten des Angreifers kaputt gehen, damit sie funktionieren. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff einem Hacker direkt Geld überweisen oder ihn in die Lage versetzen kann, sich ungestraft auf einer Website zu bewegen. Wenn alles nach dem Willen des Hackers läuft, weiß der betroffene Benutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.

Die gute Nachricht ist, dass, da so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe von großartigen Abwehrtechniken gibt, die sie in ihren Bahnen stoppen können.

Zu diesem Zweck werden wir drei Schlüsselaspekte von CSRF-Angriffen diskutieren:

• Wie sie funktionieren
• Warum sie so gefährlich sind
• Wie Sie Abwehrmaßnahmen ergreifen können, um sie kalt zu stoppen.

Wie funktionieren CSRF-Angriffe?

Da erfolgreiche CSRF-Angriffe die Möglichkeit haben, Geld, Waren oder Anmeldeinformationen von gezielten Benutzern direkt zu stehlen, sind sie trotz des hohen Aufwands, der für ihre Erstellung betrieben werden muss, sehr beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie im Laufe der Jahre eine Vielzahl von Namen und Bezeichnungen erhalten. Sie hören vielleicht, dass CSRF-Angriffe als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentationen gerne als One-Click-Attacken. Aber es sind alles CSRF-Attacken, und die Techniken, um sie abzuwehren, sind identisch.

Ein CSRF-Angriff kann passieren, wenn ein Benutzer auf einer Website angemeldet ist, um Geschäfte zu tätigen oder seine Arbeit zu erledigen. Der Schlüssel ist, dass der Benutzer angemeldet und aktiv bei einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail gestartet. Oftmals verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu verleiten, auf einen Link in einer E-Mail zu klicken, der sie auf eine kompromittierte Website mit dem Angriffsskript führt.

Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, normalerweise etwas Bösartiges wie das Ändern des Kennworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, denkt die Website, dass die Befehle vom autorisierten Benutzer erteilt werden. Warum sollte sie auch nicht? Der Benutzer hat sich bereits authentifiziert und alle Passwörter angegeben, die für den Zugriff auf die Site erforderlich sind. Möglicherweise befindet er sich sogar innerhalb eines Geofence-Bereichs und sitzt ordnungsgemäß an seinem Büroterminal. Wenn er sein Passwort ändern oder Geld überweisen möchte, gibt es keinen Grund, nicht zu glauben, dass er es ist, der die Anfrage stellt.

Wenn man die Elemente des Angriffs aufschlüsselt, wird klar, warum es für den Angreifer so schwierig ist, diesen Angriff auszuführen. Zunächst einmal muss der Benutzer aktiv bei der Website, auf der der Angriff stattfindet, authentifiziert sein. Wenn eine E-Mail mit einem Angriffsskript eintrifft, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.

Der Angreifer ist außerdem gezwungen, eine Menge Aufklärungsarbeit auf der anvisierten Website zu leisten, um zu wissen, welche Skripte diese Website akzeptiert. Angreifer können den Bildschirm des Opfers nicht sehen, und jede Rückmeldung von der Website geht an das Opfer, nicht an den Angreifer. Solange der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, wie z. B. Geld, das plötzlich auf dem Konto des Opfers auftaucht, wird er nicht einmal sofort wissen, ob er erfolgreich war.

Unter den schwierigen, aber nicht unmöglichen Parametern, dass der Benutzer zum Zeitpunkt des Angriffs eingeloggt sein muss und dass er weiß, welche Skripte die angegriffene Website akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website unterschiedlich ist.

Angenommen, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, etwa so:

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

Dieser Code würde eine Anfrage zur Überweisung von 100 $ an einen Benutzer namens NancySmith12 senden.

Wenn der anvisierte Benutzer jedoch eine E-Mail erhält, die vielleicht als von einem Kollegen stammend getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

Wenn der anvisierte Benutzer auf den Social-Engineering-Link hereinfiel und ihn anklickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000 US-Dollar an das Konto von ShadyLady15 zu senden.

Das Skript könnte sogar in einem unsichtbaren Bild versteckt werden, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, etwa so:

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

Das Ergebnis ist das gleiche. ShadyLady15 erhält 100.000 $, ohne dass jemand den Angriff entdeckt.

Warum ist CSRF so gefährlich?

CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es liegen nur wenige Schritte zwischen den Angreifern und dem Geld des Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und die Benutzer werden um Geld für die Entschlüsselung der Daten erpresst. Bei einer CSRF-Attacke sind es sogar noch weniger Schritte. Wenn sie funktionieren, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.

Über direkte Angriffe auf das Geld eines Opfers oder die Finanzen eines Unternehmens hinaus können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mit gültigen Benutzern zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte mithilfe eines CSRF-Exploits das Passwort eines Administrators ändern. Er könnte dieses Passwort sofort verwenden, um Daten zu stehlen, Löcher in der Netzwerkverteidigung zu öffnen oder Backdoors zu installieren.

Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad auch Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker wie ein Lottogewinn sein, unabhängig von ihrem eigentlichen Ziel. Bei einem Angriff auf ein Netzwerk würde fast jede andere Art von Angriff monatelange, niedrige und langsame Erkundung erfordern und versuchen, unter dem Radar des SIEM- und Cybersecurity-Personals zu bleiben. Im Gegensatz dazu kann ein einziger CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain überspringen und lässt sie sehr nah an ihrem ultimativen Ziel beginnen.

Wie kann ich CSRF-Attacken stoppen?

Anders als bei den meisten Schwachstellen liegt der Fehler bei CSRF-Angriffen nicht wirklich beim Code, sondern bei einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht will und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.

Eine der besten Methoden besteht darin, dass die Entwickler ein CSRF-Token zur Identität eines Benutzers hinzufügen, wenn eine neue Sitzung erzeugt wird. Es sollte aus einer Zeichenfolge aus eindeutigen und zufälligen Zeichen bestehen und für den Benutzer unsichtbar sein. Als Nächstes fügen Sie die CSRF-Token-Anforderung als verstecktes Feld zu Formularen hinzu, die vom Server geprüft werden, sobald eine neue Anforderung übermittelt wird. Angreifer, die Anfragen über den Browser eines Benutzers übermitteln, werden nicht einmal von dem versteckten Token-Feld wissen, geschweige denn in der Lage sein, herauszufinden, was es ist, sodass alle ihre Anfragen fehlschlagen werden.

Eine noch einfachere Methode, die nicht viel Programmieraufwand erfordert, ist das Hinzufügen einer Captcha-Abfrage zu allen sensiblen Daten, wie z. B. Anfragen zur Änderung von Passwörtern oder Überweisungsaufträgen. Das kann so einfach sein wie die Aufforderung an einen Benutzer, auf eine Schaltfläche zu klicken, um zu bestätigen, dass der Anfragende kein Roboter ist, oder in diesem Fall ein CSRF-Skript. Angreifer werden nicht in der Lage sein, eine Antwort auf die Herausforderung zu skripten, und Benutzer, die plötzlich eine CAPTCHA-Herausforderung erhalten, ohne vorher etwas zu tun, wie z. B. eine Überweisungsanforderung zu stellen, werden wissen, dass etwas nicht stimmt. Alternativ kann die Generierung eines Einmal-Passworts mit einem Token eines Drittanbieters, z. B. einem Smartphone, verwendet werden, je nachdem, wie sehr eine Organisation die Arbeit im Namen der Sicherheit verlangsamen möchte.

Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome, auch wenn sie nicht hundertprozentig sicher sind, Beschränkungen in der Same-Origin-Policy, um Anfragen von anderen als dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, können Sie eine weitere Ebene der CSRF-Sicherheit einbauen, ohne die Entwicklungsteams zu belasten.

Die Tür für CSRF zuschlagen

Mit einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie ganz aussterben, aber wir hoffen, Sie haben gelernt, warum sie so hartnäckig sind und wie Sie sie für immer aus Ihrem Netzwerk blockieren können.

Für weitere Informationen können Sie einen Blick auf das OWASP Cross-Site Request Forgery Prevention Cheat Sheet werfen, das als lebendes Dokument dient, das diese Schwachstelle in ihrer Entwicklung aufzeichnet. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele andere Bedrohungen abwehren können, indem Sie den Secure Code Warrior Blog.

Glauben Sie, dass Sie bereit sind, Ihr neues Verteidigungswissen auf die Probe zu stellen? Spielen Sie noch heute mit der kostenlosen Demo der Plattform Secure Code Warrior herum.

Cross-Site-Scripting (XSS) ist seit den frühen 2000er Jahren ein Ärgernis für Sicherheitsexperten, und leider gehört es auch nach Jahrzehnten noch zu den häufigsten Bedrohungen auf Code-Ebene. Diese Art von Software-Schwachstelle hat uns schon viel zu lange geplagt, und eine aktuelle Warnung der CISA - als Teil ihrer Secure-by-Design-Bewegung - versucht, sie ein für alle Mal zu beseitigen. Die CISA befindet sich auf einer globalen Mission zur Beseitigung von Schwachstellenklassen im großen Maßstab, und dieses Augenmerk auf die entwicklergesteuerte Sicherheit kann wirklich etwas bewirken, aber dazu bedarf es des Engagements von intelligenten Unternehmen, die ihre Entwickler für den Erfolg in Sachen Sicherheit fit machen.

Was genau ist XSS?

Webbrowser sind vielleicht unser Tor zu all den tollen Dingen im Internet, aber leider gibt es nicht nur gute Nachrichten. Das inhärente Verhalten von Webbrowsern kann ein Katalysator für Sicherheitsschwachstellen sein. Zu Beginn vertrauten die Browser in der Regel auf das Markup, das sie sahen, und führten es ohne zu hinterfragen aus. Das ist alles schön und gut, bis diese Funktionalität für unappetitliche Zwecke ausgenutzt wird... und natürlich haben Angreifer schließlich Wege gefunden, diese Tendenz für ihre bösen Zwecke auszunutzen.

Cross-Site Scripting nutzt das Vertrauen der Browser und die Unwissenheit der Benutzer, um Daten zu stehlen, Konten zu übernehmen und Websites zu verunstalten; es ist eine Schwachstelle, die sehr schnell sehr hässlich werden kann.

Werfen wir einen Blick darauf, wie XSS funktioniert, welchen Schaden es anrichten kann und wie man es verhindern kann:

Wie funktioniert XSS?

XSS tritt auf, wenn nicht vertrauenswürdige Eingaben (oft Daten) als Ausgabe auf einer Seite gerendert werden, aber als ausführbarer Code fehlinterpretiert werden. Ein Angreifer kann bösartigen ausführbaren Code (HTML-Tags, JavaScript usw.) innerhalb eines Eingabeparameters platzieren, der - wenn er an den Browser zurückgegeben wird - dann ausgeführt wird, anstatt als Daten angezeigt zu werden.

Wie bereits erwähnt, trat die Schwachstelle aufgrund des grundlegenden Funktionsverhaltens von Browsern auf, bei dem es schwierig ist, Daten von ausführbarem Code zu unterscheiden. Das Funktionsmodell des Webs ist wie folgt:

1. Benutzer besucht eine Web-Seite
2. Die Seite teilt dem Browser mit, welche Dateien geladen und was ausgeführt werden soll
3. Der Browser führt aus, was auf der Seite steht, ohne Fragen zu stellen

Diese Funktionalität hat zu einigen der großartigsten, interaktiven Erfahrungen geführt, die wir im Web genießen. Die Kehrseite der Medaille ist, dass sie auch zu kostspieligen Exploits und Schwachstellen geführt hat.

Wenn Angreifer ihr bösartiges Skript zu einer anfälligen Website hinzufügen, wird es ohne Hinterfragen ausgeführt. Es gibt weder eine tiefere Untersuchung noch Maßnahmen zur Erkennung.

Es gibt drei Arten von XSS:

• Gespeicherte XSS
• Reflektiertes XSS
• DOM XSS

Stored XSS tritt auf, wenn ein Angreifer das bösartige Skript dauerhaft in einem Datenfeld der Anwendung speichern kann (z. B. in einem Feld, das die Mobiltelefonnummer des Benutzers speichert). Dieses skizzenhafte Skript wird dann jedes Mal an den Browser des Benutzers gesendet, wenn dieses Datenfeld in der Anwendung angezeigt wird.

Diese Art von Angriff wird häufig auf Forenseiten oder Kommentarmaschinen beobachtet. Ein Angreifer gibt das bösartige Skript in einen Kommentar ein, und bam - jeder Benutzer, der diesen Kommentar aufruft, führt das Skript unwissentlich aus.

Reflektiertes XSS tritt auf, wenn Benutzereingaben unverändert an den Browser des Benutzers zurückgesendet werden. Ein Beispiel ist ein Suchfeld, das dem Benutzer beim Abrufen der Suchergebnisse anzeigt: "Sie haben gesucht nach ...".

Nun stellen Sie sich vor, dass die Suche funktioniert, indem der Suchbegriff als Abfrageparameter in die URL eingefügt wird. Ein bösartiger Angreifer könnte dem Opfer einen Link mit einem bösartigen Skript senden, das in eben diesen Parametern eingebettet ist, und ehrlich gesagt würden die meisten Webbenutzer dies kaum bemerken.

Das Opfer klickt auf den Link und wird auf eine Phishing-Seite umgeleitet, wo es unwissentlich sein Passwort für die Seite eingibt. Ohne es zu merken, hat ein Angreifer gerade den Schlüssel zu seinem Konto gestohlen.

DOM XSS ist eine relativ neue Variante dieser Sicherheitslücke. Sie nutzt die komplexen Template-Strukturen, die in vielen UI-Frameworks wie Angular und React zu finden sind.

Diese Templates ermöglichen dynamische Inhalte und reichhaltige UI-Anwendungen. Bei unsachgemäßer Verwendung können sie zur Ausführung von XSS-Angriffen verwendet werden.

So, da haben Sie es. Sie haben den Umfang von XSS in einer Nussschale bekommen. Lassen Sie uns nun tiefer eintauchen, wie es destruktiv eingesetzt werden kann.

Warum ist XSS so gefährlich?

XSS kann dazu verwendet werden, Benutzer auf bösartige Seiten umzuleiten, Cookies zu stehlen und Jagd auf Sitzungsdaten zu machen. Grundsätzlich gilt: Alles, was JavaScript kann, können auch XSS-Angriffe.

Hier sind drei Beispiele für XSS-Angriffe:

1. Yahoo-E-Mail-Benutzern wurden 2015 ihre Sitzungscookies per XSS gestohlen.
2. Der Samy-Wurm wurde über eine XSS-Schwachstelle in MySpace verbreitet. Er ist nach wie vor die sich am schnellsten verbreitende Malware aller Zeiten, die in nur 20 Stunden eine Million Benutzer befallen hat.
3. eBay erlaubte die Einbindung von bösartigen Skripten in Produktbeschreibungen. Dies führte zu XSS-Angriffen gegen eBay-Benutzer.

XSS-Angriffe sind täuschend einfach und sehr schwerwiegend. Sie können zum Diebstahl von Sitzungen, Benutzeranmeldeinformationen oder sensiblen Daten führen. Reputationsschäden und Umsatzeinbußen sind die größten Fallstricke dieser Angriffe. Selbst die bloße Verunstaltung einer Website kann zu unerwünschten Konsequenzen für ein Unternehmen führen.

XSS kann jedoch von einem versierten Sicherheitskämpfer wie Ihnen besiegt werden. Die Lösung ist nicht kompliziert und die Industrie hat einen langen, langen Weg zurückgelegt, seit XSS zu einem häufig genutzten Exploit wurde.

Sie können XSS besiegen.

Der Schlüssel zum Besiegen von XSS ist das Verständnis des Kontexts. Genauer gesagt, der Kontext, in dem Ihre Benutzereingaben an den Client zurückgesendet werden, und wo sie zurückgesendet werden. Innerhalb des HTML-Codes oder innerhalb eines JavaScript-Snippets.

Wenn die Benutzereingabe nicht an den Browser zurückgesendet werden muss, umso besser. Aber wenn doch, sollte sie oft HTML-kodiert sein. Die HTML-Kodierung der Ausgabe weist den Browser an, den Inhalt so zu rendern, wie er ist, und ihn nicht auszuführen.

Die Validierung von Eingaben ist ebenfalls wichtig. Validierung und Whitelisting sind jedoch keine narrensicheren Lösungen. Die Kodierung geht ein paar Schritte weiter und verhindert, dass der Browser ein bösartiges Skript ausführt. Was auch immer mit Validierungs- und Whitelisting-Strategien nicht abgefangen wird, wird durch Kodierung aufgefangen.

Viele Frameworks kodieren die HTML-Ausgabe inzwischen automatisch.
Angular, ASP.NET MVC und React.js sind Frameworks, bei denen standardmäßig HTML-Kodierung verwendet wird. Sie müssen diesen Frameworks ausdrücklich sagen, dass sie nicht kodieren sollen, indem Sie eine spezielle Methode aufrufen.

Die meisten anderen Frameworks (z.B. Django und Spring) haben Standardbibliotheken für die XSS-Prävention, die Sie einfach in Ihren Code einbauen können.

Die größte Herausforderung besteht darin, sich beizubringen, alle Wege zu analysieren, auf denen Benutzereingaben in ein System gelangen können, damit Sie die Augen danach offen halten können. Abfrageparameter können Angriffe tragen, ebenso wie Postparameter. Verfolgen Sie den Datenfluss in Ihrer Anwendung und vertrauen Sie keinen Daten, die von außen kommen.

Denken Sie wie eine Grenzpatrouille. Halten Sie jedes Stück Daten an, inspizieren Sie es und lassen Sie es nicht herein, wenn es bösartig aussieht. Verschlüsseln Sie dann beim Rendern, um sicherzustellen, dass die übersehenen bösartigen Daten trotzdem keine Probleme verursachen.

Führen Sie diese Strategien aus, und Ihre Benutzer werden vor Angriffen über XSS sicher sein. Werfen Sie einen Blick auf das OWASP Cheat Sheet für noch mehr Tipps, um Ihre Daten unter Kontrolle zu halten.

Verhindern Sie XSS und verbessern Sie Ihre Sicherheitsfähigkeiten.

XSS befindet sich auf Platz sieben der OWASP Top 10 Liste 2017 der Web-Sicherheitsrisiken. Es gibt sie schon eine Weile, aber sie können immer noch auftreten und Probleme mit Ihrer Anwendung verursachen, wenn Sie nicht aufpassen.

Schulungen sind für Entwickler sehr wichtig, um eine sicherheitsorientierte Denkweise zu entwickeln, während sie Code erstellen. Und dieses Training ist immer dann am effektivsten, wenn es reale Anwendungen simuliert, und zwar in den Sprachen, die Entwickler aktiv verwenden. Schauen Sie sich in diesem Sinne unsere Lernressourcen an, um mehr über XSS zu erfahren. Danach können Sie mit dem Training und der Praxis beginnen, die zu Ihrer Beherrschung führen.

Glauben Sie, dass Sie bereit sind, XSS-Schwachstellen sofort zu finden und zu beheben? Fordern Sie sich selbst heraus auf der Plattform Secure Code Warrior .

Vereinfacht ausgedrückt ist SQL (oder Structured Query Language) die Sprache, die für die Kommunikation mit relationalen Datenbanken verwendet wird; es ist die Abfragesprache, die von Entwicklern, Datenbankadministratoren und Anwendungen verwendet wird, um die riesigen Datenmengen zu verwalten , die jeden Tag erzeugt werden.

Unsere Daten werden schnell zu einem der wertvollsten Güter der Welt... und wenn etwas wertvoll ist, wollen Bösewichte es zu ihrem Vorteil in die Finger bekommen.

Angreifer nutzen SQL-Injection - eine der ältesten(seit 1998!) und lästigsten Datenschwachstellen, die es gibt - um sensible Informationen zu stehlen und zu verändern, die in Millionen von Datenbanken auf der ganzen Welt vorhanden sind. Es ist heimtückisch, und Entwickler müssen SQL-Injection verstehen (und wissen, wie man sich dagegen verteidigt), wenn wir unsere Daten sicher halten wollen.

Zu diesem Zweck werden wir drei Hauptaspekte der SQL-Injektion besprechen:

• Wie es funktioniert
• Warum es so gefährlich ist
• Wie man sich dagegen verteidigt

SQL-Injektion verstehen

SQL-Injection kann mit einem Wort verstanden werden: Kontext.

Innerhalb einer Anwendung existieren zwei Kontexte: einer für Daten, der andere für Code. Der Code-Kontext sagt dem Computer, was er ausführen soll und trennt ihn von den zu verarbeitenden Daten.

SQL-Injection tritt auf, wenn ein Angreifer Daten eingibt, die vom SQL-Interpreter fälschlicherweise als Code behandelt werden.

Ein Beispiel ist ein Eingabefeld auf einer Website, in das ein Angreifer ''' OR 1=1" eingibt und das an das Ende einer SQL-Abfrage angehängt wird. Wenn diese Abfrage ausgeführt wird, gibt sie für jede Zeile in der Datenbank "true" zurück. Das heißt, es werden alle Datensätze aus der abgefragten Tabelle zurückgegeben.

Die Auswirkungen einer SQL-Injection können katastrophal sein. Wenn dies auf einer Anmeldeseite geschieht, könnte sie alle Benutzerdatensätze zurückgeben, möglicherweise einschließlich Benutzernamen und Kennwörtern. Wenn eine einfache Abfrage zum Herausnehmen von Daten erfolgreich ist, dann würden auch Abfragen zum Ändern von Daten erfolgreich sein.

Lassen Sie uns einen Blick auf verwundbaren Code werfen, damit Sie sehen können, wie eine SQL-Injection-Schwachstelle in Fleisch und Blut aussieht.

Sehen Sie sich diesen Code an:

String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
   Statement statement = connection.createStatement( ... );
   ResultSet results = statement.executeQuery( query );
}

Der Code hier fügt die Parameterinformationen vom Client einfach an das Ende der SQL-Abfrage an, ohne sie zu validieren. Wenn dies geschieht, kann ein Angreifer Code in ein Eingabefeld oder URL-Parameter eingeben und dieser wird ausgeführt.

Der springende Punkt ist nicht, dass Angreifer nur ''' OR 1=1" zu jeder SELECT-Abfrage hinzufügen können, sondern dass ein Angreifer jede Art von SQL-Abfrage (INSERT, UPDATE, DELETE, DROP usw.) manipulieren und mit allem erweitern kann, was die Datenbank unterstützt. Es gibt großartige Ressourcen und Tools im öffentlichen Bereich, die zeigen, was möglich ist.

Wir werden bald lernen, wie man dieses Problem beheben kann. Zuerst wollen wir verstehen, wie viel Schaden angerichtet werden kann.

Warum SQL-Injection so gefährlich ist

Hier sind nur drei Beispiele für Sicherheitsverletzungen, die durch SQL-Injection verursacht wurden:

• Die Website des Illinois Board of Election wurde aufgrund von SQL-Injection-Schwachstellen angegriffen. Die Angreifer stahlen die persönlichen Daten von 200.000 US-Bürgern. Die Art der gefundenen Schwachstelle bedeutete, dass die Angreifer die Daten auch hätten ändern können, was sie jedoch nicht taten.
• Hetzner, ein südafrikanisches Website-Hosting-Unternehmen, wurde in Höhe von 40.000 Kundendatensätzen angegriffen. Eine SQL-Injection-Schwachstelle führte zum möglichen Diebstahl jedes Kundendatensatzes in ihrer Datenbank.
• Ein katholischer Finanzdienstleister in Minnesota, USA, wurde mittels SQL-Injection angegriffen. Kontodaten, einschließlich Kontonummern, von fast 130.000 Kunden wurden gestohlen.

Sensible Daten können verwendet werden, um Konten zu übernehmen, Passwörter zurückzusetzen, Geld zu stehlen oder Betrug zu begehen.

Selbst Informationen, die nicht als sensibel oder persönlich identifizierbar gelten, können für andere Angriffe verwendet werden. Adressdaten oder die letzten vier Ziffern Ihrer staatlichen Identifikationsnummer können verwendet werden, um sich gegenüber Unternehmen als Sie auszugeben oder Ihr Passwort zurückzusetzen.

Wenn ein Angriff erfolgreich ist, können Kunden das Vertrauen in das Unternehmen verlieren. Die Behebung von Schäden an Systemen oder behördlichen Geldstrafen kann Millionen von Dollar kosten.

Aber so muss es für Sie nicht enden.

SQL-Injektion besiegen

SQL-Injection kann vereitelt werden, indem Sie Teile Ihrer Anwendung eindeutig kennzeichnen, so dass der Computer weiß, ob ein bestimmter Teil Daten oder auszuführender Code ist. Dies kann durch parametrisierte Abfragen geschehen.

Wenn SQL-Abfragen Parameter verwenden, verwendet der SQL-Interpreter den Parameter nur als Daten. Er führt ihn nicht als Code aus.

Zum Beispiel wird ein Angriff wie ''' OR 1=1" nicht funktionieren. Die Datenbank wird nach der Zeichenfolge "OR 1=1" suchen und sie nicht in der Datenbank finden. Sie wird einfach mit den Schultern zucken und sagen: "Tut mir leid, ich kann das nicht für Sie finden."

Ein Beispiel für eine parametrisierte Abfrage in Java sieht so aus:

Die meisten Entwicklungsframeworks bieten eingebaute Schutzmechanismen gegen SQL-Injection.

Objektrelationale Mapper (ORMs), wie z. B. Entity Framework in der .NET-Familie, parametrisieren Abfragen standardmäßig. Dadurch wird SQL-Injection ohne jeglichen Aufwand Ihrerseits verhindert.

Sie müssen jedoch wissen, wie Ihr spezifisches ORM funktioniert. Zum Beispiel kann Hibernate, ein beliebtes ORM in der Java-Welt, bei falscher Verwendung dennoch anfällig für SQL-Injection sein.

Die Parametrisierung von Abfragen ist die erste und beste Verteidigung, aber es gibt noch andere. Stored Procedures unterstützen ebenfalls SQL-Parameter und können verwendet werden, um SQL-Injection zu verhindern. Denken Sie daran, dass die gespeicherten Prozeduren ebenfalls korrekt aufgebaut sein müssen, damit dies funktioniert.

// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );

Validieren und bereinigen Sie immer Ihre Eingaben. Da einige Zeichen, wie z. B. "OR 1=1", von einem legitimen Benutzer Ihrer Anwendung nicht eingegeben werden, ist es nicht notwendig, sie zuzulassen. Sie können dem Benutzer eine Fehlermeldung anzeigen oder sie aus der Eingabe entfernen, bevor sie verarbeitet werden.

Verlassen Sie sich also nicht allein auf die Validierung und Desinfizierung, um sich zu schützen. Clevere Menschen haben Wege gefunden, sie zu umgehen. Das sind gute Defense in Depth (DiD)-Strategien, aber die Parametrisierung ist der todsichere Weg, um alle Basen abzudecken.

Eine weitere gute DiD-Strategie ist die Verwendung von "Least Privilege" innerhalb der Datenbank und Whitelisting von Eingaben. Das Erzwingen von "Least Privilege" bedeutet, dass Ihre Anwendung keine unbegrenzte Macht innerhalb der Datenbank hat. Sollte ein Angreifer Zugriff erhalten, ist der Schaden, den er anrichten kann, begrenzt.

OWASP hat ein großartiges SQL Injection Cheat Sheet zur Verfügung, das zeigt, wie man mit dieser Schwachstelle in verschiedenen Sprachen und Plattformen umgeht... aber wenn Sie noch einen draufsetzen wollen, können Sie auf unserer Plattform gleich eine SQL Injection Challenge in Ihrer bevorzugten Sprache spielen; hier sind einige der beliebtesten, um den Anfang zu machen:

SQL-Einschleusung in C#

SQL-Einschleusung in Node.js

SQL-Einschleusung in Python Django

SQL-Einschleusung in Java Spring

Die Reise beginnt

Sie haben große Fortschritte gemacht, um SQL-Injection zu verstehen und die Schritte, die nötig sind, um sie zu beheben. Großartig!

Wir haben besprochen, wie SQL-Injektion auftritt; typischerweise verwendet ein Angreifer Eingaben, um Ihre Datenbankabfragen für seine eigenen schändlichen Zwecke zu steuern.

Wir haben auch den Schaden gesehen, der durch die Ausnutzung von SQL-Injection-Schwachstellen entsteht: Konten können kompromittiert werden und Millionen von Dollar verloren gehen... ein Alptraum, und ein teurer noch dazu.

Wir haben gesehen, wie man SQL-Injection verhindern kann:

• Abfragen parametrieren
• Verwenden von objektrelationalen Mappern und gespeicherten Prozeduren
• Validierung und Whitelisting von Benutzereingaben

Jetzt liegt es an Ihnen. Übung ist der beste Weg, um weiter zu lernen und seine Fähigkeiten zu verbessern, also schauen Sie sich doch mal unsere Lernressourcen zur SQL-Injektion und probieren Sie dann unsere kostenlose Demo der Plattform? Sie werden auf dem besten Weg sein, ein Secure Code Warrior zu werden.

Im Jahr 2020 wird es einen enormen Anstieg bei der Telearbeit geben, dazu kommen weitere groß angelegte Datenschutzverletzungen und ein zunehmender Fokus auf die Folgen einer kompromittierten Privatsphäre im Internet - noch nie war das Thema Cybersicherheit so sehr im Fokus der Öffentlichkeit. Infolgedessen haben sich Regierungen auf der ganzen Welt eingeschaltet, um ihre Cybersicherheitspläne und -infrastrukturen neu zu gestalten und zu aktualisieren, einschließlich Strategien und Vorschriften, die Unternehmen beim Umgang mit unseren wertvollsten digitalen Ressourcen befolgen müssen.

Strategische Schutzrichtlinien für die Cybersicherheit sind kein neues Konzept, und Organisationen wie das NIST haben die Richtlinien globaler Regierungsabteilungen über viele Jahre hinweg informiert. Mit dem rasanten digitalen Fortschritt ist es für viele schwierig geworden, mit der Anzahl der Bedrohungen, möglichen Angriffsvektoren und Compliance-Anforderungen, die Teil einer sich ständig verändernden Landschaft sind, Schritt zu halten.

Ein kürzlich erfolgter Einbruch in 54.000 Führerscheine des Bundesstaates New South Wales aufgrund eines leicht zugänglichen, falsch konfigurierten S3-Buckets auf einem Server eines Drittanbieters hat Tausende von Personen gefährdet, wobei der Sicherheitsforscher, der den Einbruch meldete, einräumte, dass die Daten bereits im Dark Web verkauft worden sein könnten. Das Traurige daran ist, dass es sich um eine einfache Lösung handelt und es unwahrscheinlich gewesen wäre, dass dies überhaupt passiert wäre, wenn diejenigen, die den Cache konfigurieren, die Sicherheit im Blick gehabt hätten.

Die australische Regierung hat vor kurzem die australische Cybersicherheitsstrategie 2020 veröffentlicht, in der neue Initiativen und eine Aufstockung der Mittel um 1,67 Milliarden Dollar für das nächste Jahrzehnt vorgestellt werden, um die "Vision einer sichereren Online-Welt für die Australier, ihre Unternehmen und die wichtigen Dienste, von denen wir alle abhängen", zu erreichen. Dies ist eindeutig eine sehr willkommene Überprüfung und Aktualisierung des Plans, zumal eines der Hauptziele darin besteht:

"Maßnahmen von Unternehmen, um ihre Produkte und Dienstleistungen zu sichern und ihre Kunden vor bekannten Cyber-Schwachstellen zu schützen".

Während sich staatliche Stellen eher auf die Sicherheitsmaßnahmen für die kritische Infrastruktur eines Landes konzentrieren (was sie auch tun sollten) - Bereiche, die reif für einen katastrophalen organisierten Angriff sind - fehlten in der Vergangenheit Richtlinien für die Unternehmen, die täglich unsere Daten sammeln und nutzen.

Wenn es um eine offizielle Strategie wie diese geht, geht es nicht immer um Bier und Kegel. Sie kann ein wenig schwer zu interpretieren und vage in den Details sein, so dass es dem Sicherheitsteam einer Organisation überlassen bleibt, einen Plan auf der Grundlage unspezifischer Richtlinien zusammenzustellen. Dieses Problem betrifft nicht nur die australische Regierung, aber lassen Sie uns ihre brandneue Version analysieren.

Ein Fokus auf Reaktion, nicht auf Prävention.

Die aktualisierte australische Cybersicherheitsstrategie ist ein relevanterer Aufschwung als die letzte Version aus dem Jahr 2016, mit ziemlich umfassenden Plänen für Unternehmen, insbesondere KMUs. Die Strategie umreißt:

"DieRegierung und große Unternehmen werden kleine und mittlere Unternehmen (KMU) dabei unterstützen, ihr Bewusstsein und ihre Fähigkeiten im Bereich der Cybersicherheit zu steigern. Die australische Regierung wird mit großen Unternehmen und Dienstleistern zusammenarbeiten, um KMUs Informationen und Tools zur Cybersicherheit als Teil von "Bündeln" sicherer Dienste (wie z. B. Bedrohungsabwehr, Antivirus und Schulungen zum Bewusstsein für Cybersicherheit) zur Verfügung zu stellen."

Dies bietet KMUs eine anständige Basis, auf der sie ihr Unternehmen vor Cyber-Bedrohungen schützen können, aber es ist weitgehend ein reaktiver Ansatz, und der Fokus liegt auf Erkennungs-Tools - ein relativ kleiner Teil der Cybersicherheitslandschaft.

Es gibt auch erstaunlich wenig Informationen darüber, wie sich große Unternehmen schützen und ihre Angriffsvektoren reduzieren können. Zwar sind viele von ihnen Teil der Pläne zum Schutz kritischer Infrastrukturen (wie Telekommunikation und Verkehr), doch haben Finanzdienstleistungen, Einzelhandel und viele andere Branchen bei einem erfolgreichen Cyberangriff viel zu verlieren. Vielleicht wird dies Teil der kommenden Gesetzgebung sein, aber selbst dann ist die Hervorhebung der Bedeutung sorgfältiger bewährter Cybersicherheitspraktiken auf Unternehmensebene von grundlegender Bedeutung, um signifikante Veränderungen und einen Rückgang der gefährdeten Daten und der Cyberkriminalität zu erreichen.

Wenn man die Strategie als Ganzes betrachtet, ist sie auf einem reaktiven Ansatz aufgebaut. Die Abwehr von Cyberangriffen, die Unterbrechung aktiver Cyberkrimineller und die Sicherstellung ihrer Strafverfolgung sowie der Austausch von Erkenntnissen mit internationalen Verbündeten sind alles wichtige Faktoren, aber stellen Sie sich vor, der landesweite Standard für den Schutz würde sich auf die Prävention konzentrieren. Wenn neben den Schutzmaßnahmen für kritische Infrastrukturen die Sicherheit in jedem Unternehmen an erster Stelle stünde und jede Person, die mit dem Code, der unsere digitale Welt erschafft, in Berührung kommt, richtig ausgerüstet wäre, um Angriffe zu blockieren, bevor sie passieren, wäre die Ersparnis an Zeit, Geld und Herzschmerz für die Opfer unermesslich.

Resilienz ist möglich, aber sie muss geplant werden.

Der Vorstoß der australischen Regierung, sich ernsthaft mit dem Thema Cybersicherheit zu befassen, macht deutlich, dass es auf nationaler Ebene als zentrales Risikofeld identifiziert worden ist. Wie bei jedem anderen böswilligen Angriff, der unsere Lebensweise stören könnte, ist die Widerstandsfähigkeit absolut entscheidend - nicht nur, um einem solchen Versuch zu widerstehen, sondern auch, um als Abschreckung zu wirken, damit er überhaupt stattfindet. Letztendlich können auch Bedrohungsakteure faul sein und werden sich ein leichteres Ziel suchen, um ihr Ziel zu erreichen, wenn ihnen zu viele Hindernisse in den Weg gelegt werden.

Im Moment haben wir es mit einem globalen Cybersecurity-Fachkräftemangel zu tun, und das ist etwas, das CISOs auf der ganzen Welt nachts wach hält. Milliarden von Codezeilen, ständige groß angelegte Datenschutzverletzungen und ein höheres Risiko von Strafen (allein Marriott erhielt eine GDPR-Strafe in Höhe von 123 Mio. USD für die Datenschutzverletzung von 2018... und in diesem Jahr gab es eine weitere Sicherheitsverletzung) als je zuvor haben eine Bedarfslücke für Sicherheitsspezialisten geschaffen, die realistischerweise wahrscheinlich nicht geschlossen werden kann. Es gibt einfach zu viel Code und zu wenig Ressourcen, um sicherzustellen, dass er von allen Seiten abgesichert ist.

Sollten wir also die Idee aufgeben, dass wir jemals wirklich vor Cyber-Bedrohungen bestehen werden? Auf gar keinen Fall. Um widerstandsfähig zu sein, müssen wir alle verfügbaren Ressourcen nutzen und einen Schritt voraus denken. Und für viele Unternehmen können ihre Entwickler bereits beim Schreiben des Codes eine leistungsstarke Methode zur Stärkung freischalten. Gepaart mit einer sichtbaren, positiven Sicherheitskultur im gesamten Unternehmen entsteht so ein sicheres Fundament, das für viele Angreifer nur schwer zu erschüttern und zu knacken ist. Diese Methode erfordert jedoch, dass man die Vorschläge aus der australischen Cybersicherheitsstrategie als Beispiel nimmt und tiefer in die Frage eintaucht, wie sie angepasst werden können, um effektive Veränderungen zu unterstützen, die für das Unternehmen relevant sind.

Zu diesem Zweck ist es wichtig, ein paar der Tipps aufzuschlüsseln:

• Schulungen zum Sicherheitsbewusstsein: Dies wird speziell für KMUs gefordert und zielt im Kontext des gesamten Berichts hauptsächlich darauf ab, allen Mitarbeitern grundlegende Sicherheitshygiene beizubringen (z. B. Erkennen von Phishing-E-Mails, nicht auf unbekannte Links klicken usw.). Realistischerweise muss sie viel weiter gehen und rollenspezifisch werden, insbesondere für diejenigen, die mit Code in Berührung kommen, wie z. B. Entwickler. Es ist zwingend erforderlich, dass die Schulung des Sicherheitsbewusstseins ein Bestandteil der Präventivmaßnahmen und des Aufbaus von Widerstandsfähigkeit ist
• Bildung: In einer erfrischenden Abwechslung gibt es einen detaillierten Plan, um den Mangel an Cybersicherheitskompetenzen in den nächsten zehn Jahren zu beheben, indem der Schwerpunkt auf Cybersicherheitstraining von der Grund- und Sekundarschule bis hin zur Hochschulbildung gelegt wird. Dies ist dringend notwendig, wenn wir die Sicherheits-Superstars der Zukunft ausbilden wollen, aber aus der Perspektive, die Bedürfnisse der Unternehmen jetzt zu adressieren, ist praktisches Training in sicherer Programmierung für die Entwicklungskohorte eine absolute Notwendigkeit, um mit der Reduzierung allgemeiner Schwachstellen zu beginnen, und muss Teil eines funktionalen Sicherheitsprogramms sein.

Als Sicherheitsexperten müssen wir mehr tun, um Unternehmen auf der ganzen Welt dabei zu helfen, die Bedeutung des Aufbaus eines internen Sicherheitsprogramms zu verstehen, das über einfache grundlegende Maßnahmen der Awareness hinausgeht. Zeit in die Weiterbildung von Entwicklern zu investieren, nimmt den Druck von überlasteten AppSec-Spezialisten, und sicherzustellen, dass die gesamte Organisation im Rahmen ihrer Rolle so sicherheitsbewusst wie möglich ist, ist entscheidend für die Reduzierung der Angriffsfläche von Software.

Die Weiterbildung von Entwicklern ist gut investierte Zeit, warum also ignorieren so viele Unternehmen dies?

Eine kürzlich durchgeführte Umfrage der DDLS kam zu dem Ergebnis, dass es in australischen Unternehmen nur wenig Sinn für Prioritäten gibt, wenn es um Schulungen zur Cybersicherheit geht. Tatsächlich schaffte es das Thema nicht einmal unter die drei wichtigsten Schulungsprioritäten, obwohl 77 % der Befragten das Bewusstsein für Cybersicherheit als "extrem" oder "sehr wichtig" für ihr Unternehmen einstuften.

Es ist also kein Wunder, dass Australien Schwierigkeiten hat, die wachsende Qualifikationslücke zu schließen, und noch einiges zu tun hat, um eine widerstandsfähigere Infrastruktur zu schaffen, von wichtigen Dienstleistungen bis hin zum Einzelhandel und allem dazwischen.

Hier bietet sich eine enorme Chance für die Regierungen, eine Basiszertifizierung für Sicherheitskompetenzen oder eine Verordnung zu schaffen, und die Strategie deutet dies als eine Möglichkeit an, mit begrenzten Ressourcen zu arbeiten. Aber auch hier scheint es sich um einen Vorschlag für die Zukunft zu handeln, und wir haben die Mittel, um viel früher damit anzufangen, wenn wir uns zuerst auf die Bereiche mit den größten Auswirkungen konzentrieren. Für mich liegt der Hoffnungsschimmer bei den Entwicklungsteams in den einzelnen Unternehmen. Mit den entsprechenden Werkzeugen und Kenntnissen können sie häufige Schwachstellen im Keim ersticken und das Risiko einer Datenschutzverletzung in ihrem Unternehmen erheblich verringern.

Im Jahr 2019 wurden 24 % aller Datenschutzverletzungen durch menschliches Versagen verursacht - nämlich durch Sicherheitsfehlkonfigurationen, die normalerweise relativ einfach auf Code-Ebene behoben werden können. Wenn hier Schulungen in Verbindung mit dem Aufbau eines unternehmensweiten Sicherheitsbewusstseins zur Priorität gemacht werden, wette ich, dass es weniger CISOs geben würde, die Benachrichtigungen über Datenschutzverletzungen an Tausende von kompromittierten Kunden absegnen.

Der 23. Juni ist ein besonderer Eintrag im Geek-Kalender und markiert den International Women in Engineering Day. Obwohl wir das ganze Jahr über die Leistungen unserer Kollegen und Teams feiern sollten, ist dies unsere Chance, nicht nur den Beitrag von Frauen zur Softwareentwicklung im Allgemeinen zu beleuchten, sondern auch ihren positiven Einfluss bei Secure Code Warrior. Wir können uns glücklich schätzen, dass wir in unserer Organisation ein nahezu ausgeglichenes Verhältnis zwischen Männern und Frauen haben, und damit auch einige talentierte Frauen in unserem Ingenieurteam.

Es ist mir nicht entgangen, dass MINT-Karrieren notorisch männerdominiert sind, und für weibliche Entwickler weiß ich aus erster Hand, dass einige Tech-Umgebungen herausfordernd und unfair gegenüber Frauen sein können, hauptsächlich durch unbewusste Vorurteile. Das ist nicht gut genug, und es war mir wichtig, dafür zu sorgen, dass jeder fair behandelt wird, dass die Vielfalt gefördert wird und dass sich die Teams durch unterschiedliche Meinungen, Erfahrungen und Denkweisen bereichert fühlen. Schließlich sollte kein Unternehmen in einer Echokammer existieren und erwarten zu gedeihen. Es ist die Verstärkung der Stimmen, die am wenigsten gehört werden, die zu unglaublichen Dingen führen kann.

Diese Woche möchte ich die Beiträge von Frauen hervorheben, die so viel zu unserem technischen Schwerpunkt beitragen und mit ihrer wirklich großartigen Arbeit immer wieder mit gutem Beispiel vorangehen. Lesen Sie weiter, um ein paar unserer technischen Superstars kennenzulernen:

Julia Semeniuk, Scrum Master

Was gefällt Ihnen am Softwareentwicklungsprozess?
Ich mag die Ergebnisse. Ich denke, es ist ein sehr wichtiger Teil des Geschäfts: Am Ende des Tages bringt die Softwareentwicklung alle Ideen, Rückmeldungen und Entwürfe zusammen und macht sie für andere Teile des Geschäfts und für unsere Kunden verfügbar.

Vor welchen Herausforderungen stehen Sie in Ihrer Rolle?
Ich denke, die größte Herausforderung ist die Kommunikation und Abstimmung. Wir müssen sicherstellen, dass wir zu jedem Zeitpunkt an dem wichtigsten Teil arbeiten. Deshalb ist die Zusammenarbeit mit Produkt, Support und anderen Teams so wichtig für uns.

Was gefällt Ihnen am meisten an Ihrer Rolle?
Ich liebe den Geist und die Teamarbeit. Jedes bisschen Arbeit, das wir tun, wird durch synchronisierte Arbeit und Zusammenarbeit erreicht. Und den Fortschritt unserer Arbeit und das Wachstum der Menschen zu sehen, macht mich jeden Tag glücklich.

Welche Initiativen ergreifen Sie, um Frauen in Ihrem Team zu unterstützen?
Wir haben das Glück, dass wir auf Secure Code Warrior gleich behandelt werden. Ich glaube nicht, dass wir Initiativen haben, die sich ausschließlich an Frauen richten, wir unterstützen und respektieren uns gegenseitig, unabhängig von Geschlecht und Gender. Allerdings machen Unternehmensinitiativen wie Elternzeit und flexible Arbeitsregelungen für uns alle einen großen Unterschied.

Noemi Alvarez, Senior Software-Entwickler

Rolle bei Secure Code Warrior:
Senior Software Ingenieur

Bevorzugte Sprachen/Frameworks:
Typescript /Javascript - Angular/Node, weil ich mit diesen die meiste Erfahrung habe und mich wohler fühle.

Am wenigsten bevorzugte Sprachen/Frameworks:
Java / PHP, weil ich nicht die Gelegenheit hatte, mit diesen zu arbeiten.

Wie sind Sie zur Softwareentwicklung gekommen?
Ich recherchierte über Trendkarrieren und IT war eine davon, und mein Lieblings-Mathelehrer sagte, ich wäre ein toller Ingenieur.

Mit welchen Herausforderungen sind Sie in Ihrer Rolle konfrontiert?
Mit neuen Technologien und Trends auf dem Laufenden zu bleiben.

Was gefällt Ihnen am meisten an Ihrer Rolle?
Generell, etwas zu bauen/erstellen und zu sehen, wie die Leute es benutzen. Bei SCW die Herausforderung zu haben, es so sicher wie möglich zu bauen.

Laura Verheyde, leitende Software-Ingenieurin

Rolle bei Secure Code Warrior:
Entwickler im ACE-Team. Grundsätzlich helfe ich mit, die Plattform mit neuen Herausforderungen zu versehen.

Bevorzugte Sprachen/Frameworks:
C#, .NET.

Am wenigsten bevorzugte Sprachen/Frameworks:
Wahrscheinlich PHP, aber das liegt vor allem an der mangelnden Erfahrung damit.

Wie sind Sie zur Softwareentwicklung gekommen?
Vor Jahren haben meine besten Freunde alle IT studiert, das hat mein Interesse geweckt.

Mit welchen Herausforderungen sind Sie in Ihrer Rolle konfrontiert?
Das Navigieren und Verstehen von fremdem Code, um meinen eigenen hinzuzufügen, kann eine ziemlich anspruchsvolle Aufgabe sein. Auch der Gedanke, dass es im Bereich der IT noch so viel zu lernen gibt, kann manchmal einschüchternd sein, aber auch sehr lohnend, wenn man eine bestimmte Herausforderung gemeistert hat.

Was gefällt Ihnen am meisten an Ihrer Rolle?
Ein Teil meiner Aufgabe besteht darin, Code auf syntaktischer Ebene zu durchforsten, was ich sehr interessant finde. Daneben ist es ein sehr befriedigendes Gefühl, die Anwendungen zu sehen, zu denen ich beigetragen habe, die Ergebnisse produzieren und neue Inhalte für die SCW-Plattform schaffen.

Haben Sie einen Rat für junge Frauen, die eine ähnliche Karriere in Erwägung ziehen?
Ja, lassen Sie sich nicht von der Vorstellung einschüchtern, an einem männerdominierten Arbeitsplatz arbeiten zu müssen. Meine anfänglichen Bedenken haben sich in den ersten Tagen ziemlich schnell gelegt, da ich die nettesten und freundlichsten Kollegen kennengelernt habe, die man sich wünschen kann. Ich bin mir ziemlich sicher, dass das an den meisten Arbeitsplätzen der Fall ist.

Josh Graham, unser VP of Technology, entwickelt ein Mentorenprogramm, um mehr Frauen in unsere Ingenieurskohorte zu bringen. Unser Ziel ist es, ihnen die Möglichkeit zu geben, ihre Karriere voranzutreiben und dabei von Vorbildern angeleitet zu werden, die ihnen zeigen, was in den Bereichen Softwareentwicklung, Cybersicherheit und Technik möglich ist. Es ist wichtig für junge Frauen, jemanden zu sehen, mit dem sie sich in einer aufstrebenden Rolle identifizieren können und der ihnen zeigt, dass ihre Träume nicht nur wichtig, sondern auch erreichbar sind.

Als Branche und als Unternehmen haben wir noch einiges zu tun, wenn es darum geht, echte Gleichberechtigung für Frauen in Technologiekarrieren zu erreichen. Wir arbeiten hart daran, mehr Frauen in unsere offenen Rollen zu bringen; ihre Beiträge werden uns nur vorantreiben und uns helfen, mit gutem Beispiel voranzugehen. Es ist jetzt an der Zeit, Vorurteile, Privilegien und gläserne Decken anzuerkennen und gleichzeitig ernsthafte Anstrengungen zu unternehmen, um den Status quo zu ändern.

Wir bemühen uns, ein sicheres, unterstützendes Umfeld für Geeks aller Hintergründe zu schaffen. Wir stehen hinter Frauen in der Tech-Branche und bieten flexible Arbeitszeiten und großzügige Eltern-/Familienregelungen in einem globalen Umfeld. Möchten Sie sich uns anschließen? Halten Sie unsere Karriereseite und LinkedIn als Lesezeichen für Ihre nächste Gelegenheit bereit - wir haben immer Stellen im technischen Bereich für begeisterte Technologen, die sich an einem Arbeitsplatz entfalten möchten, an dem Sie so kommen können, wie Sie sind.

Eine Version dieses Artikels erschien ursprünglich in DevOps Digest. Er wurde aktualisiert und hier syndiziert.

An diesem Punkt sind wir sicher alle ein wenig müde von der Phrase, "in diesen beispiellosen Zeiten"... aber, dies sind wirklich beispiellose Zeiten. Wer hätte Ende letzten Jahres gedacht, dass wir in diesem Jahr gegen eine weltweit zerstörerische Pandemie antreten und alles daran setzen würden, sie zu besiegen? Es wäre fast lächerlich und eher wie eine neue Netflix-Science-Fiction-Serie als Teil unserer weltweiten Realität erschienen. COVID-19 hat unser soziales Leben, unsere Wirtschaft und die Sicherheit unserer Arbeitsplätze völlig verändert, ganz zu schweigen von den politischen Prioritäten.

Einer der Gegenangriffe gegen COVID-19 ist die Technologie: Viele Länder haben Apps zur Kontaktverfolgung eingeführt. In Australien gibt es COVIDSafe nach dem Vorbild von TraceTogether aus Singapur. Hongkong, Taiwan, China, Südkorea, Israel und Deutschland haben alle eine Technologie zur Kontaktverfolgung implementiert oder sind dabei, diese einzuführen. Großbritannien ist die am stärksten betroffene Region in Europa, mit zehntausenden von virusbedingten Todesfällen und einer hohen Infektionsrate. Die Veröffentlichung ihrer App steht unmittelbar bevor. In den USA - die ebenfalls stark betroffen sind und in denen viele Menschen auf tragische Weise ihr Leben verloren haben - ist die Technologie ebenfalls im Einsatz, aber der bundesstaatliche Ansatz zur Kontaktverfolgung macht die Situation dort sehr komplex.

Mit Ausnahme von eher staatlich kontrollierten Ländern wie China und Taiwan ist die Nutzung dieser Apps freiwillig, sodass die Bürger die Technologie aus eigenem Antrieb herunterladen und nutzen müssen. Einige Adoptionsraten sind erfolgreicher als andere; zum Beispiel hatte die TraceTogether-App in Singapur eine Adoptionsrate von 25 %, was sie für den gewünschten Zweck ziemlich ineffektiv macht.

Die Idee hinter Apps zur Kontaktverfolgung ist gut. Diese Technologie würde, wenn sie gut funktioniert, sicherstellen, dass Hotspots schnell aufgedeckt werden und umfassende Tests durchgeführt werden können - beides wesentliche Komponenten im Kampf gegen die Verbreitung eines ansteckenden Virus. Allerdings klingen die Worte "Regierung" und "Rückverfolgung" nicht gerade sehr einladend, und es ist natürlich, dass die Menschen vorsichtig sind, was das Herunterladen von so etwas tatsächlich für sie bedeuten würde.

Was sind also die Hauptbedenken der Anwender? Wenn man den Online-Kommentaren Glauben schenken darf, dann gehören zu diesen Bedenken einige:

• Mangelndes Vertrauen in die Regierung, gesammelte Daten verantwortungsvoll zu nutzen
• Besorgnis darüber, wie gut persönliche Daten vor Cyberangriffen geschützt werden
• Unklarheit darüber, welche Daten tatsächlich gesammelt werden, wo sie gespeichert werden und mit wem
• ... und für die Entwickler/Geeks unter uns, wie solide die Apps tatsächlich gebaut sind.

Es ist immer ein bisschen beunruhigend, wenn Apps schnell gebaut werden, und diese Kontaktverfolgungs-Apps müssen in Rekordzeit ausgerollt werden. Es ist ein Albtraum für Entwickler, Sicherheitsleute und Behörden.

Ist Misstrauen also eine berechtigte Reaktion? Und was sollten wir als Priorität in unserer assessment von COVID-19 Kontaktverfolgungs-Apps und der Sicherheit der Endbenutzer betrachten? Als Sicherheitsexperte ist mein Instinkt natürlich, die Cybersecurity-Elemente des Programms zu untersuchen, nämlich wie sicher die Codebasis für eine App ist, zu deren Installation wir alle (mit den besten Absichten) gedrängt werden.

Viele der Apps sind Kopien voneinander (und erben die gleichen Probleme).

Die australische COVIDSafe-App basiert im Wesentlichen auf OpenTrace, ebenso wie die TraceTogether-Software in Singapur. Das Problem ist jedoch, dass TraceTogether eine Reihe von gemeldeten Problemen und eine schlechte Akzeptanz hatte, mit nur 25 % der Bevölkerung als Nutzer - weit entfernt von den 75 %, die erforderlich sind, damit es effektiv ist. Es gab Beschwerden über die allgemeine Leistung, vor allem unter iOS, einschließlich der Tatsache, dass die Batterien sehr schnell entladen werden. COVIDSafe hat einen potenziellen UX-Fehler in seiner iOS-Version, da das Telefon entsperrt sein muss und die App im Vordergrund laufen muss, um alle Daten korrekt aufzuzeichnen.

Während die oben genannten Probleme ärgerlich sind, ist die dringendere Sorge, dass Bluetooth-Schwachstellen weit verbreitet sind und weder TraceTogether noch das australische COVIDSafe immun gegen sie sind. Am 14. Mai berichtete das NIST, dass COVIDSafe eine Denial-of-Service-Schwachstelle aufweist, die es einem Angreifer ermöglicht, die App aus der Ferne zum Absturz zu bringen, wenn er sich in Bluetooth-Handshake-Distanz befindet. Dies würde es einem organisierten Angriff ermöglichen, die Kontaktverfolgung in dicht besiedelten Gebieten zu unterbrechen, wo sie am nützlichsten ist - etwas, das der Sicherheitsforscher Richard Nelson im Detail erklärt. Es ist bekannt, dass COVIDSafe, TraceTogether, das polnische ProteGO und das kanadische ABTraceTogether betroffen sind - sie alle erben das Problem vom fehlerhaften manuData.subdata-Aufruf von OpenTrace.

Es gibt auch andere Datenschutz- und Sicherheitsprobleme, die mit der Bluetooth-Funktionalität im Allgemeinen zusammenhängen. Die Tatsache, dass diese Technologie verwendet wird, um menschliche Bewegungen durch eine eindeutige ID (TempID) zu verfolgen und aussagekräftige Daten zu sammeln, wird unweigerlich zu einem erhöhten Interesse von Angreifern führen, die nach Schwachstellen suchen. An diesem Punkt muss genau untersucht werden, was gesammelt wird, wo es gespeichert wird und für wie lange.

Einige Apps zeigen bereits Anzeichen für einfache Fehler, die komplexe Schwachstellen verursachen.

Der australische Software-Ingenieur Geoffrey Huntley hat den Quellcode von COVIDSafe untersucht, und leider gibt es Probleme, die uns, den Endbenutzern, nicht unbedingt aufgezeigt werden.

Ein kritisches Beispiel war ein die Privatsphäre verletzender Logikfehler, der es einem Angreifer ermöglichen würde, eine Langzeitverfolgung von Geräten durchzuführen; etwas, das ein enormes Risiko für gefährdete Benutzer darstellt, ganz zu schweigen davon, dass es gegen die Datenschutzbestimmungen der App selbst verstößt.

Es ist wichtig anzumerken, dass diese logischen Schwachstellen seit dem 14. Mai gepatcht wurden, aber das dringendere Problem ist, dass diese Schwachstelle 17 Tage lang ungepatcht blieb, nachdem Herr Huntley sie gemeldet hatte. Er und andere Mitglieder der awesome-Sicherheits-Community verfolgen die CVEs im Zusammenhang mit der COVIDSafe-App hier.

Eine Sache, auf die Huntley nach dem Patch hinweist, ist, dass selbst der Fix Anzeichen von, nun ja, Inkompetenz zeigt. In seinem öffentlichen Log vermerkt er, dass der Patch eine zusätzliche Logik beinhaltete, anstatt einfach einen fehlerhaften Cache zu löschen, wobei letzteres eine weitaus robustere Lösung ist. Beides funktioniert, aber der Live-Lösung fehlt es an Finesse - ein Problem bei einer so wichtigen Anwendung.

Obwohl wir fleißige Mitglieder der Gesellschaft haben, die ihre eigene Zeit und ihr Fachwissen einsetzen, um den Quellcode zu durchforsten und auf Probleme hinzuweisen, wird ihre Arbeit viel schwieriger gemacht, als wenn der Code von vornherein Open Source wäre. So wie es aussieht, sind 28 Apps immer noch für Sicherheitsforscher gesperrt.

Die sichere Kodierung bringt uns immer wieder ins Stolpern.

Auch wenn ich sicherlich Verständnis für überarbeitete Entwickler habe - ebenso wie für die höchst ungewöhnliche Situation, eine lebensrettende App inmitten einer Pandemie herausbringen zu müssen - sollte das oben Gesagte verdeutlichen, dass ein paar einfache Schwachstellen in einer im Wesentlichen gemeinschaftlichen Codebasis erhebliche Probleme für Millionen von Benutzern bedeuten können.

Ich würde gerne glauben, dass die meisten Leute gute Bürger sein wollen, die App unterstützen und jedem die bestmögliche Chance geben wollen, Kontakte aufzuspüren und Ausbrüche dieses schrecklichen Virus zu kontrollieren. Auch ich unterstütze Technologie, die dabei helfen kann, dies zu erreichen, aber in vielerlei Hinsicht hat dies den allgemeinen Mangel an sicheren Codierungsprinzipien bei Entwicklern auf der ganzen Welt zutage gebracht.

In jeder Situation, in der Software schnell geschrieben werden muss, sind Fehler nicht gerade unerwartet. Gängige Sicherheitslücken wie Logikfehler, Fehlkonfigurationen und Code-Injection-Fehler sollten jedoch bereits beim Schreiben des Codes verhindert werden können und nicht erst, nachdem freiwillige White Hats die Codebasis auseinandergenommen haben.

Und es ist nicht die Schuld der Entwickler, nebenbei bemerkt. Sie verlassen ihre Hochschulausbildung mit wenig Kenntnissen in sicherer Programmierung, und in ihrer Karriere beziehen sich ihre KPIs fast immer auf die Funktionalität der Funktionen und die Geschwindigkeit der Bereitstellung - um die Sicherheit muss sich jemand anderes kümmern, wenn sie fertig sind. Wir müssen einen Endzustand erreichen, in dem die sichere Programmierung schnell erfolgt. Auch wenn jetzt nicht die Zeit ist, in den Abteilungen, die diese Apps entwickeln, einen seismischen Kulturwandel herbeizuführen, so ist es doch eine rechtzeitige Erinnerung daran, dass sich unser digitaler Risikobereich ausweitet und sie sich in der Pole-Position befinden, um einen Unterschied zu machen, wenn sie die Werkzeuge und das Wissen erhalten, um die Verantwortung für die besten Sicherheitsverfahren zu teilen.

Ist es sicher, die App herunterzuladen?

Die Sache ist die: Für mich, einen Sicherheitsexperten, bin ich zu dem Schluss gekommen, dass die Vorteile der App die Probleme überwiegen. Es ist nicht ideal, dass die oben genannten Schwachstellen in dieser Software vorhanden sind - oder waren -, aber die Auswirkungen, wenn diese als Waffe eingesetzt werden, sind das Worst-Case-Szenario. Im Moment ist die Kontaktverfolgung ein wichtiger Bestandteil, um unsere medizinischen Helden auf der ganzen Welt dabei zu unterstützen, die Ausbreitung zu kontrollieren, den Fluss der Krankenhauseinweisungen einzudämmen und sich gegenseitig so sicher wie möglich zu halten.

Es zeigt, dass wir noch einen weiten Weg vor uns haben, wenn es darum geht, bewährte Sicherheitspraktiken standardmäßig in einem Software-Build zu implementieren, und dass es wichtig ist, dass die Öffentlichkeit die nötigen Informationen erhält, um fundierte Entscheidungen zu treffen.

Meine Familie und ich werden es weiterhin verwenden, obwohl wir wachsam bleiben und unsere Android-Patches auf dem neuesten Stand halten, wie wir es alle tun sollten.

Eine Version dieses Artikels erschien im Cyber Defense Magazin. Er wurde für die Syndikation hier aktualisiert.

Cyberattacken sind heutzutage zum Alltag geworden. Die Menschen erwarten fast schon Nachrichten über eine neue Sicherheitslücke, die alles betrifft, vom Bankwesen bis zur Luftfahrt, oder so unterschiedliche Geräte wie Smartphones und Ampeln. Selbst unser Zuhause ist nicht mehr völlig sicher. Ganze Städte und Ortschaften werden fast täglich von Kriminellen angegriffen, wobei die Angreifer Lösegeld in Millionenhöhe fordern, um kompromittierte kritische Dienste wiederherzustellen.

Aber ein Ort, an dem wir uns hoffentlich immer noch sicher fühlen konnten, war in der Arztpraxis oder sogar im Krankenhaus. Die Menschen sind am verletzlichsten, wenn sie sich an einen Gesundheitsdienstleister wenden. Der menschliche Anstand würde fast verlangen, dass man den Ärzten vor Ort erlaubt, ihre noble Arbeit in Ruhe zu tun. Leider ist das nicht der Fall. Es scheint wenig Ehre " oder vielleicht schiere Verzweiflung " unter den heutigen Cyber-Dieben zu geben. Tatsächlich könnte das Gesundheitswesen das nächste "große" Schlachtfeld der Cybersicherheit werden, da Kriminelle genau die Maschinen angreifen, die medizinische Probleme diagnostizieren, Behandlungen durchführen und Leben erhalten. Angesichts der anhaltenden globalen Gesundheitskrise, die sich vor unseren Augen abspielt, ist es von entscheidender Bedeutung, dieses Problem von mehreren Seiten anzugehen.

Die Bedrohungen werden persönlicher als je zuvor.

Angriffe auf die Gesundheitsbranche sind nicht neu. Cyberkriminelle kennen bereits den Wert, den Patienteninformationen, persönliche Daten und Finanzdaten in der Unterwelt und im Dark Web haben. Diese Informationen können verwendet werden, um direkt Geld von Patienten zu stehlen oder als Ausgangspunkt für sekundäre Angriffe wie Phishing und andere Betrügereien. Kein Wunder also, dass viele der verheerendsten Angriffe der letzten Zeit auf das Gesundheitswesen abzielten. Bei Anthem Healthcare wurden 80 Millionen Patientendaten gestohlen. Premera verlor 11 Millionen persönliche Daten. Bei CareFirst waren es insgesamt 1,1 Millionen kompromittierte Datensätze, und die Liste lässt sich beliebig fortsetzen.

Im Moment scheinen Angriffe direkt auf medizinische Geräte selten zu sein. Allerdings deutet zumindest ein Bericht darauf hin, dass das Problem viel weiter verbreitet sein könnte, da Krankenhäuser die Eindringlinge nicht melden oder Mitarbeiter, die nicht in Cybersicherheit geschult sind, einfach nicht erkennen, dass ein Angriff direkt vor ihren Augen stattfindet. Die Fähigkeit, medizinische Geräte auf beängstigende Weise zu kompromittieren, wie z. B. die Verwendung von Malware, um CAT-Scans und MRT-Ergebnisse mit gefälschten Tumoren zu versehen, wurde von Sicherheitsforschern eindeutig nachgewiesen. Es ist nicht sehr weit hergeholt zu denken, dass Angreifer bereits dieselben oder ähnliche Dinge mit medizinischen Geräten in der realen Welt anstellen könnten.

Das Gesundheitswesen ist auch aufgrund der zunehmenden Abhängigkeit von Geräten im Internet der Dinge (IoT), also winzigen Sensoren, die mit dem Internet verbunden sind und unglaubliche Mengen an Informationen produzieren, besonders anfällig für Cyberangriffe. Die Absicherung der von diesen Sensoren erzeugten Informationen, der von ihnen genutzten Kommunikationskanäle und sogar der Sensoren selbst, war bisher kaum mehr als ein Nachgedanke. Die Anzahl der potenziellen Schwachstellen, die ein Angreifer in diesen IoT-dominierten Netzwerken ausnutzen könnte, ist wahrscheinlich fast unbegrenzt.

Das IoT im Gesundheitswesen birgt ernsthafte Risiken.

Dienste, die für die Patientenversorgung entscheidend sind - und die in einigen Fällen vor 20 Jahren noch nicht einmal denkbar waren - sind Brutstätten sowohl für IoT-basierte als auch für andere, eher traditionelle Schwachstellen. Elektronische Krankenakten, Telemedizin und Mobile Health warteten scheinbar nur auf den Informationsschub, den das IoT bieten könnte. Es ist kein Wunder, dass das Engagement für das IoT im Gesundheitssektor schwindelerregend ist. MarketResearch.com prognostiziert , dass der IoT-Markt im Gesundheitswesen bis zum nächsten Jahr ein Volumen von 117 Milliarden US-Dollar erreichen wird und danach jedes Jahr um 15 % weiter wächst.

In dieser Umgebung können geschickte Angreifer viele Schwachstellen finden, die zur Ausnutzung medizinischer Geräte genutzt werden können. IoT-Sensoren, die in medizinische Geräte eingebettet sind, kommunizieren im Allgemeinen auf eine von zwei Arten und geben ihre Daten aus. Einige sammeln Daten und übertragen dann alle ihre Ergebnisse direkt zur Analyse ins Internet. Andere verwenden eine Form der verteilten Vernetzung, die als Fog Computing bekannt ist, bei der die Sensoren selbst eine Art Mini-Netzwerk bilden und gemeinsam entscheiden, welche Daten mit einem zentralen Repository oder einer Plattform geteilt werden sollen. Diese Daten können dann weiterverarbeitet oder direkt vom medizinischen Personal abgerufen werden.

Erschwerend für die Cybersicherheit im Gesundheitswesen kommt hinzu, dass sich die Branche nie auf Standards, Methoden oder Schutzmaßnahmen für die Datenverarbeitung geeinigt hat. Historisch gesehen wurde die Gesundheitsbranche von Herstellern bedient, die ihre eigenen proprietären Technologien für medizinische Geräte anboten. Dazu gehören heute die eingebetteten IoT-Sensoren, die Kommunikationskanäle, die die Geräte verwenden, und die Plattform für die Analyse der Daten, nachdem sie gesammelt wurden. Dies macht die meisten Krankenhausnetzwerke zu einem Traum für Hacker, oder zumindest zu einem guten Testgelände, auf dem sie alles ausnutzen können, von Sicherheitsfehlkonfigurationen bis hin zu unzureichendem Schutz auf der Transportschicht. Sie können alles versuchen, von Cross-Site Request Forgeries bis hin zu den klassischen XML-Injection-Angriffen.

Der Gegenschlag, den wir brauchen, liegt direkt vor uns.

Trotz der potenziell katastrophalen Folgen, die ein Ausnutzen dieser Schwachstellen haben kann, gibt es etwas, das optimistisch stimmt: Diese Sicherheitslücken sind keine neuen, mächtigen Hintertüren, die von kriminellen Superhirnen geöffnet werden. Sie sind so weit verbreitet, dass es frustrierend ist, sie immer wieder zu sehen. Ein Grund für ihr Auftauchen ist die Verwendung von Altsystemen, die trotz verfügbarer Korrekturen nicht gepatcht wurden, ein anderer ist wiederum der Faktor Mensch. Die Entwickler schreiben Code in einem rasanten Tempo und konzentrieren sich auf ein glattes, funktionales Endprodukt - und nicht auf bewährte Sicherheitsverfahren.

Es wird einfach zu viel Software entwickelt, als dass AppSec-Spezialisten mithalten könnten, und wir können nicht erwarten, dass sie ständig den Tag mit diesen wiederkehrenden Schwachstellen retten. Es ist billiger, effizienter und eindeutig viel sicherer, wenn diese Schwachstellen gar nicht erst eingeführt werden, und das bedeutet, dass Sicherheitsteams und Entwickler die Extrameile gehen müssen, um eine robuste, durchgängige Sicherheitskultur zu schaffen.

Wie sieht eine großartige Sicherheitskultur genau aus? Hier sind ein paar Schlüsselelemente:

• Entwickler werden mit den Werkzeugen und Schulungen ausgestattet, die sie benötigen, um häufige Bugs zu beseitigen (und verstehen, warum das so wichtig ist)
• Das Training ist umfassend, leicht verdaulich und spielt die Stärken der Entwickler aus
• Die Ergebnisse der Schulung werden ordnungsgemäß gemessen, mit Metriken und Berichten (nicht nur eine Übung zum Ankreuzen und Weitermachen)
• AppSec und Entwickler beginnen, die gleiche Sprache zu sprechen: Schließlich arbeiten sie in einer positiven Sicherheitskultur an ähnlichen Zielen.

Die Möglichkeit einer Katastrophe ist immer noch enorm und geht weit über den Diebstahl der medizinischen Daten eines Patienten hinaus. Die Injektion von gefälschten Tumoren in einen Scan könnte eine Person, die ängstlich darauf wartet zu erfahren, ob sie Krebs hat, am Boden zerstören. Und das Austauschen von Medikamenten oder das Ändern von Behandlungsplänen könnte sie sogar töten. Aber es braucht nur einen einzigen Cyberkriminellen, der bereit ist, diese Grenze aus Profitgründen zu überschreiten, und Sie können garantieren, dass es passieren wird. Vielleicht wird der nächste Ransomware-Betrug nicht die Daten eines Krankenhauses verschlüsseln, sondern stattdessen die Diagnosen von Tausenden von Patienten ruinieren. Oder vielleicht droht ein Angreifer, Medikamente zu verändern, wenn er nicht bezahlt wird, und hält buchstäblich Leben als Lösegeld fest.

Es ist klar, dass wir bei der Cybersicherheit im Gesundheitswesen nicht mehr nach dem Prinzip "business as usual" vorgehen können. Wir können uns nicht darauf verlassen, dass ein oder zwei Spezialisten in Gesundheitsorganisationen jedes Problem lösen. Stattdessen brauchen wir sicherheitsbewusste Entwickler, die an Gesundheitsanwendungen und -geräten arbeiten, um potenzielle Probleme zu erkennen und zu beheben, bevor sie in den Einrichtungen eingesetzt werden. Und auch das Gesundheitspersonal könnte eine Grundausbildung in Cybersicherheit gebrauchen.

Es ist wahr, dass nichts wichtiger ist als Ihre Gesundheit. In der Gesundheitsbranche hängt die Aufrechterhaltung einer guten Cybersecurity-Fitness für die Zukunft davon ab, dass heute ein besseres allgemeines Sicherheitsbewusstsein gefördert wird. Ohne eine ernsthafte Behandlung ist dies ein Problem, das nur noch schlimmer werden wird.

Eine Version dieses Artikels erschien ursprünglich in Dunkles Lesen. Er wurde für die Syndikation hier aktualisiert.

In unserer Branche haben es sich viele Sicherheitsexperten zur Gewohnheit gemacht, die brisanten Themen für das kommende Jahr vorherzusagen (und ich bin da keine Ausnahme), aber angesichts von mehr als fünf Milliarden gestohlenen sensiblen Datensätzen im Jahr 2019 dachte ich mir, dass es genauer wäre, vorherzusagen, was in der Cybersicherheit im Jahr 2020 oder sogar in der absehbaren Zukunft nicht passieren wird.

Ich habe mich mit meinem Mitbegründer Matias Madou zusammengesetzt und wir haben bei der Zusammenstellung dieser Liste ein wenig gelacht. Die Liste ist eher als lockerer Ausblick gedacht, aber sie regt zum Nachdenken über den langen Weg an, der vor jeder Organisation liegt, um sie gegen bösartige Cyberangriffe zu schützen.

Schauen wir nun in unsere Kristallkugel und verraten unsere Vorhersagen. Wir werden nicht sehen:

SQL-Injections aus aller Software ausgemerzt

Ich glaube, jeder Sicherheitsexperte auf dem Planeten hat auf den Tag gewartet, an dem er nicht mehr dazu verdammt ist, SQL-Injection-Bugs zu identifizieren, ad nauseam.

Traurigerweise warten wir seit mehr als zwanzig Jahren auf diesen Tag, und wir werden noch mindestens einen weiteren warten. Es ist die Schwachstelle, die wie eine Kakerlake bisher jede Taktik überlebt hat, um sie endgültig auszurotten.

Das ist gelinde gesagt frustrierend, da die Abhilfe schon seit ziemlich genau so langer Zeit bekannt ist. Die Priorisierung von Sicherheits-Best-Practices in jeder Phase der Software-Entwicklung (vor allem von Anfang an) ist jedoch nach wie vor zu gering und angesichts der enormen Zunahme der Code-Produktion seit der Entdeckung von SQL-Injection sicherlich unzureichend.

(Möchten Sie mehr über die Codierungsmuster erfahren, die zu einer SQL-Injection führen können? Nehmen Sie die Herausforderung hier an).

Entwickler und AppSec werden beste Freunde

Ah, Entwickler und das AppSec-Team. Werden sie jemals miteinander auskommen, oder sind sie zu einem Leben der Rivalität wie Rocky gegen Apollo bestimmt? Die kurze Antwort lautet: Ja, sie können miteinander auskommen, aber im Moment sind ihre Prioritäten oft sehr unterschiedlich.

Wenn sie in einer Projektumgebung aufeinandertreffen, stehen sie auf entgegengesetzten Seiten und prallen genau an der letzten Hürde aufeinander: wenn AppSec-Spezialisten den Code eines Entwicklers durchforsten. Der Entwickler hat schöne, funktionale Funktionen gebaut (was seine oberste Priorität ist), die auseinandergerissen werden, wenn Sicherheitslücken entdeckt werden. Der Software-Sicherheitsguru hat sein Baby in der Tat als hässlich bezeichnet und den Entwickler gezwungen, zurückzugehen und alle Fehler zu beheben, was oft die Bereitstellung verzögert.

In unserem aktuellen Zustand wird dies nicht behoben werden, bis Entwickler und AppSec-Teams auf ein gemeinsames Ziel hinarbeiten, nämlich die Erstellung von sicherer Software. Das wird nicht als Standardprozess im Jahr 2020 passieren (und bei vielen Unternehmen noch einige Jahre danach), aber mit dem Aufkommen der DevSecOps-Bewegung und darüber hinaus erkennen Entwickler die Notwendigkeit, sich in Sachen Sicherheit weiterzubilden und nach einem höheren Standard zu arbeiten; einem, der Sicherheitsziele von Anfang an einschließt.

Ein Überangebot an Sicherheitsexperten

Im Jahr 2020, 2025, 2030... ist es fast garantiert, dass wir weltweit unterbesetzt sein werden, wenn es um Sicherheitskompetenz geht.

Einem Bericht des ISC(2) zufolge sind derzeit rund 2,93 Millionen Stellen im Bereich Cybersicherheit unbesetzt. Dies wird mit ziemlicher Sicherheit schlimmer werden, bevor es besser wird, und es gibt keine versteckte Sicherheitsarmee, die darauf wartet, in den nächsten Jahren zu unserer Rettung zu marschieren.

In der unmittelbaren Zukunft besteht unsere beste Chance, diesen Fachkräftemangel zu beheben, darin, Sicherheit zu einer organisatorischen Priorität zu machen und unsere bestehende Belegschaft weiterzubilden. Die meisten aktuellen AppSec-Teams kämpfen wahrscheinlich mit bekannten, alten Sicherheitslücken (siehe Punkt 1 oben). Wenn wir dafür sorgen, dass sie keine kostbare Zeit und Mühe darauf verwenden müssen, diese allgemeinen Probleme zu beheben, haben sie mehr Bandbreite, um sich auf schwierige Sicherheitsprobleme zu konzentrieren (im Moment umfassen diese wahrscheinlich Probleme mit APIs sowie die Erstellung von Tools, die in Entwicklungspipelines passen).

Weniger Code wird produziert

Die Welt wird in einem atemberaubenden Tempo digitalisiert, und die gesellschaftliche Nachfrage wird nicht nachlassen. Jedes Jahr werden ca. 111 Milliarden Codezeilen geschrieben, und diese Zahl wird immer größer und beängstigender werden (für die ohnehin schon überforderten AppSec-Teams).

Ein erhöhtes Codevolumen führt unweigerlich zu einer Zunahme potenzieller Sicherheitslücken, sodass alle Überlegungen, dass 2020 ein langsameres Jahr für die Softwareproduktion und Sicherheitsverletzungen sein wird, ungefähr so realistisch sind wie ein Einhornrennen beim Grand National.

Reduzierung der gestohlenen Datensätze

Wie gesagt, mehr Code bedeutet mehr Schwachstellen, und das bietet mehr Möglichkeiten für Angreifer, einen Weg zu finden, Daten zu stehlen.

Mindestens 5,3 Milliarden Datensätze wurden 2019 weltweit gestohlen, und die Verteidigung gegen Angreifer ist immer noch ein bisschen ein verzweifeltes, reaktives Gerangel. Diese Zahl wird sich in den nächsten zwölf Monaten vielleicht nicht verdoppeln, aber ich denke, sie wird nah dran sein.

Schauen wir uns als Beispiel die historischen Trends der gemeldeten gestohlenen Daten in den Vereinigten Staaten im Jahresvergleich an:

Betrachtet man den Zeitraum zwischen 2005 und 2010, so ist ein stetiger Anstieg mit einer kleinen Ebbe und Flut zwischen den Jahren zu erkennen. Dies ist interessant, aber ein wichtiger Faktor, der hervorgehoben werden sollte, ist, dass 2009 ein starker Rückgang der gemeldeten Verstöße im Vergleich zu 2008 zu verzeichnen war. Die Anzahl der gestohlenen Datensätze stieg jedoch trotz weniger Verstöße deutlich an.

Datensätze sind das neue Gold; sie haben einen Wert für einen Angreifer. Die Grafik spiegelt einen allgemeinen Aufwärtstrend bei Sicherheitsverletzungen und der Anzahl der gestohlenen Datensätze wider, mit einem enormen Höhepunkt im Jahr 2017. Die Anzahl der Angriffe ging 2018 tendenziell zurück, vielleicht aufgrund strengerer Sicherheitsmaßnahmen, aber die Anzahl der erlangten Datensätze war so hoch wie nie zuvor. Cyberangriffe werden immer ausgefeilter und umfangreicher und werden in absehbarer Zeit nicht verschwinden. Und weltweit werden wir im Jahr 2020 wahrscheinlich keinen Rückgang erleben, da die Unternehmen schnell mehr Software produzieren als je zuvor. Sie sind die Torwächter unserer Daten und müssen intelligenter arbeiten, um unsere Privatsphäre zu schützen.

Entwickler fordern längere und häufigere videobasierte Sicherheitsschulungen

Wenn es eine Sache gibt, die Entwickler lieben, dann ist es, sich stundenlang Computer Based Training (CBT) Videos anzusehen. Tatsächlich ist die Nachfrage nach diesen fesselnden Inhalten so groß, dass Netflix eine ganz neue Unterkategorie ankündigen wird, die sich allgemeinen Sicherheitsschulungsvideos widmet.

Äh, nö. Nicht jetzt, nicht im Jahr 2020, niemals.

Für Entwickler erfolgt der Einstieg in das Thema Sicherheit oft über eine Schulung zur Einhaltung von Vorschriften am Arbeitsplatz. Sicheres Programmieren ist selten Teil ihrer Hochschulausbildung, und die Ausbildung am Arbeitsplatz kann die allererste Begegnung mit Software-Sicherheit sein. Und es überrascht nicht, dass sie das oft nicht mögen.

Damit Entwickler Sicherheit ernst nehmen - und damit Schulungen nützlich sind - müssen sie relevant, ansprechend und kontextbezogen für ihre Arbeit sein. Einmalige Compliance-Schulungen - oder ein endloser Strom von langweiligen Videos - sind nicht der Weg zum Herzen eines Entwicklers und werden Schwachstellen nicht reduzieren.

Wenn Sie wollen, dass die Entwickler-Kohorte eine Chance hat, eine sicherheitsbewusste Verteidigungskraft gegen häufige Schwachstellen zu werden, lassen Sie sie mit echten Code-Beispielen arbeiten - die Art, mit der sie bei ihren täglichen Aufgaben zu tun haben. Machen Sie das Lernen mundgerecht, leicht ausbaufähig, und schaffen Sie Anreize, die Spaß machen. Damit eine Sicherheitskultur gedeihen kann, muss sie positiv und ansprechend sein und echte Fähigkeiten und Lösungen im gesamten Unternehmen entwickeln.

Wer weiß? Mit der richtigen Schulung erkennt ein Entwickler vielleicht seinen inneren Sicherheits-Champion und verbreitet die Vorteile von sicherem Coding weit und breit.

Null Todesfälle durch einen cybersicherheitsrelevanten Vorfall

Okay, das ist eindeutig kein Grund zum Lachen. Ich habe schon oft gesagt, dass die Welt sich einfach nicht um Cybersicherheit kümmern wird, bis Menschen durch einen Cyberangriff sterben.

Das Problem ist, dass dies bereits geschehen ist, und es blieb weitgehend unbemerkt.

Cyberangriffe auf US-Krankenhäuser wurden mit einem Anstieg der Todesfälle durch Herzinfarkt im Jahr 2019 in Verbindung gebracht. Natürlich verursachten die Angreifer keine tödlichen kardialen Ereignisse bei Patienten, aber ihre Ransomware-Angriffe auf Krankenhaussysteme und -geräte verlangsamten die Behandlungszeiten für die kritische Versorgung.

Diese Studie der University of Central Florida analysierte 3000 Krankenhäuser, von denen 311 eine Datenpanne erlebt hatten. In den Krankenhäusern, die von einem Sicherheitsvorfall betroffen waren, dauerte es im Durchschnitt 2,7 Minuten länger, bis ein EKG bei Verdacht auf Herzinfarkt durchgeführt wurde; wahrscheinlich aufgrund von Verfahrensänderungen, neu implementierten Sicherheitsmaßnahmen und IT-Support-Problemen, die mehr Zeit in Anspruch nahmen als zuvor. Die Erkennung und Behandlung eines Herzinfarkts ist ein Wettlauf mit der Zeit, und in diesen Krankenhäusern gab es im Durchschnitt 36 zusätzliche Todesfälle pro 10.000 Herzinfarkte pro Jahr.

Das ist schockierend, und leider denke ich, dass es noch schlimmer wird, bevor es besser wird. Dies sollte eine deutliche Erinnerung daran sein, dass wir alle mehr tun müssen, um die Softwaresicherheit zu verbessern und sie in jedem Unternehmen in den Vordergrund zu stellen.

Weniger Stockbilder von "vermummten Hackern"

Wenn man "Hacker" in eine Bildersuche eingibt, stößt man unweigerlich auf Tausende von Bildern einer vermummten, gesichtslosen Gestalt, die auf einem Laptop herumtippt, oder auf eine ähnliche Gestalt mit einer Guy-Fawkes-Maske.

Dieses klischeehafte Bild eines Hackers ist wirklich ermüdend und, nun ja, es lässt jeden wie einen Bösewicht aussehen. Es gibt viele gute Jungs und Mädels in der Sicherheitsbranche, und die negativen Assoziationen rund um das "Hacker"-Image erweisen allen einen schlechten Dienst.
Ob sich das in nächster Zeit ändern wird? Wahrscheinlich nicht, aber es ist schön zu träumen. Für den Moment ist es wichtig, sich daran zu erinnern, dass Sicherheit nicht beängstigend sein muss.