XSS Prävention bei modernen JavaScript Frameworks

Die meisten modernen JS-Frameworks wie ReactVue, oder Angular bringen von Haus aus bereits viele Sicherheitsfeatures mit, die es vorher nicht in der Form gab. Trotzdem kann man auch hier noch Fehler machen, die sich direkt auf die Sicherheit auswirken. Die Gefahr ist also nach wie vor, dass man aus Unwissenheit Schwachstellen verursacht. Deshalb ist es wichtig, diese Schwachstellen zu kennen, um sie dann auch vermeiden zu können.

Als Beispiel zeige ich hier einen klassischen Fall von Cross Site Scripting (XSS), der auch heute noch sehr real ist. Wir konstruieren uns dazu das folgende Szenario.

Nehmen wir an, wir wollten einen Benutzer mit seinem Namen ansprechen, indem wir ihn über eine Marketing-E-Mail verknüpfen. Das Hinzufügen von ?name=Julian zum Query-String und das anschließende Hinzufügen zum DOM wäre eine schnelle Möglichkeit, dies zu tun.

Zum Beispiel:

document.querySelector('.tagline').innerHTML = nameFromQueryString

Dadurch würde „Julian“ direkt namentlich angesprochen werden auf der Seite. Die Filterung auf den Request-Parameter wird vom JS-Framework hier nicht gemacht werden.

Die Verwendung von Code wie dem oben genannten bedeutet, dass jeder Angreifer Code in Deine Webanwendung einfügen und übernehmen kann. Allein durch Ändern des Namens in <script src="my.malicious.site"> kann man eine URL kreieren, die eine gefälschte Zahlungsseite so aussehen lässt, als würde sie von Deiner SSL-verschlüsselten Website geliefert.

Aus diesem Grund ist es ratsam, Daten von Requestparametern immer vorher zu prüfen und zu filtern, und sie niemals einfach so zu übernehmen. Nur so kann man XSS wirksam vermeiden.

Neues Video: A9:2017 Nutzung von Komponenten mit bekannten Schwachstellen

Eine sehr häufig auftretende Sicherheitslücke in Webanwendungen entsteht durch den Einsatz unsicherer Libraries. Wenn auch Ihr in Euren Webanwendungen fremde Libraries einsetzt, dann solltet ihr jetzt ganz genau zuhören!

Platz 9 der OWASP Top 10 nennt sich „Nutzung von Komponenten mit bekannten Schwachstellen“. Hier geht es um den Einsatz von 3rd-Party-Libraries, die bekannte Schwachstellen enthalten, und dadurch die Sicherheit unserer Anwendung gefährden. Ich werden Euch zeigen, die man das entdecken und vermeiden kann.

A9:2017 Nutzung von Komponenten mit bekannten Schwachstellen

Talk „Hack me if you can“ auf der JAX2019

Auf der diesjährigen JAX in Mainz (6.-10. Mai 2019), der Konferenz für Java, Architektur- und Software-Innovation, habe ich am 8. Mai den Talk „Hack me if you can – Sicherheit in Webanwendungen“ gehalten. Inhaltlich habe ich dabei herausgearbeitet, wie wichtig die Berücksichtigung von Sicherheitsschwachstellen ist, bzw. dass man diese konsequent und strategisch vermeidet. Die richtige Vorgehensweise ist dabei, zunächst die Angriffe zu verstehen, damit man eine wirksame Verteidigung aufbauen kann.

Es gibt viel zu viele Webanwendungen, die zu einfach zu hacken sind. Der Grund ist fast immer, dass sich die Entwickler während der Implementierung keine Gedanken über die Sicherheit machen – weil sie die Angriffe nicht kennen. Deshalb ist es eine Grundvoraussetzung für sichere Software, dass man die Grundlagen sicherer Software kennt.

Den Vortrag habe ich aus diesem Grund in 4 Teile aufgeteilt:

  1. Einleitung: Warum das Ganze?
  2. Wie man hackt
  3. Wie man sich schützt
  4. Wie man sich wehrt

In der Einleitung geht es darum, zu zeigen, dass man sich aktiv um die Sicherheit kümmern muss. Man muss die Angriffe verstehen, um wirksame Verteidigung aufbauen zu können. Ich erläutere, dass viele Basics nicht berücksichtigt werden können, wenn das Know-How bei der Entwicklung nicht vollständig vorhanden ist.

Im 2. Teil „Wie man hackt“ zeige ich die Vorgehensweise von Hackern, so wie man es auch in Hacker-Kursen lernt. Der Grund dafür ist, damit ein Verständnis aufgebaut wird, wie man eine Anwendung angreift, bzw. von der anderen Perspektive aus gesehen, wie man angegriffen wird. Dadurch kann dann im 3. Teil besser verstanden werden, welche Maßnahmen man treffen muss, damit diese offenen Flanken nicht mehr bestehen.

Der 4. Teil beschäftigt sich dann mit der angemessenen Reaktion auf Angriffe. Denn niemand muss für eine Anwendung hinnehmen, dass sie durch Angriffe lahmgelegt wird. Es gibt hier Verteidigungsmaßnahmen, die das unterbinden können. Dabei stelle ich Tools vor, die eine Schaltzentrale für Sicherheitsmonitoring bieten, damit man Angriffe auf seine Anwendungen in Echtzeit verfolgen kann, und den Abwehrmaßnahmen live bei Ihrer Arbeit zuschauen kann.

Vortrag auf der JAX 2019

Am 8. Mai 2019 halte ich auf der JAX 2019 einen Vortrag über Sicherheit in Webanwendungen. Die JAX ist eine Konferenz für Java-, Architektur- und Software-Innovationen.

Der Titel des Vortrags lautet: Hack me if you can – Sicherheit in Webanwendungen. Wie auch schon letztes Jahr in kleiner Runde im Rahmen eines Meetups, werde ich bei diesem Thema über die Wichtigkeit und Notwendigkeit referieren, warum es so essenziell wichtig ist, sich um die Sicherheit in der Software zu kümmern.

Ich werde dabei zeigen, wie einfach es inzwischen die Angreifer haben, insbesondere über arglos entwickelte Anwendungen, bei denen keiner auf die Sicherheit geachtet hat. Dabei ist es oft so einfach darauf zu achten. Man muss eben nur die Basics kennen, um einen wirksamen Grundschutz zu bekommen.

Promovideo für meinen Vortrag auf der JAX in Mainz

Hier die genauen Angaben zum Vortrag: Donnerstag, 8. Mai um 15:15 Uhr in der Rheingoldhalle, Raum Gutenberg 2+3. Den Rest des Tages könnt ihr mich am Stand von EXXETA antreffen, ich würde mich freuen Euch dort zu treffen!

Jackson-Databind und das Problem mit CVE-2017-7525

Wird Jackson-Databind als 3rd-Party-Lib in einem Projekt eingebunden, oder es ist über eine transitive Abhängigkeit mit im Projekt, dann melden Analysetools umgehend ein Finding. Aber in welchem Fall ist Jackson-Databind tatsächlich gefährlich?

Hintergrund

Jackson-Databind wird verwendet, wenn Json Strings deserialisiert werden. Die Deserialisierung ist etwas komplizierter als die Serialisierung, was daran liegt, dass beim Serialisieren die Klassen noch bekannt sind. Werden abstrakte Klassen oder Interfaces verwendet, ist das beim Serialisieren egal – der Json String ist immer der gleiche. Anders herum muss beim Deserialisieren, wenn der Json String wieder in reale Objekte gemappt wird, eine Entscheidung für konktete Klassen gefällt werden, die auch instantiiert werden können.

Damit Jackson bei der Deserialisierung konkrete Klassen ermitteln kann, wird mit Annotations gearbeitet, über die die Klassen angegeben werden können:

{ "phone" : {
"@class" : "package.InternationalNumber",
"areaCode" : 555,
...
}
}

Auf Seite der Java-Klasse wird als Gegenstück z.B. mit @JsonTypeInfo gearbeitet, damit Jackson die richtige Klasse findet. Es gibt hier eine Vielzahl an Annotations, die bei komplexeren Strukturen helfen sollen.

Die Gefahr

Die Sicherheitslücke besteht dann, wenn der Json String so manipuliert werden kann, dass bei der Deserialisierung eine Klasse instanziiert wird, die Schaden anrichten kann (Denial of Service, Sensitive Data Exposure, Data Manipulation, …). Solche Klassen werden in diesem Kontext als „Gadgets“ bezeichnet.

Eine Gadget-Klasse muss allerdings im Klassenpfad der Anwendung liegen, weshalb zunächst unlogisch erscheint, dass damit Schaden angerichtet werden kann. Es gibt aber verschiedene polymorphe Klassen, über die generischer Code eingeschleust werden kann, der dann zur Ausführung kommt. Jackson hat deshalb bereits eine Blacklist an bekannten Gadget-Klassen, die bei der Deserialisierung nicht ausgeführt werden. Allerdings kommen immer neue kreative Varianten dazu, so dass naturgemäß eine Blacklist kein vollkommener Schutz sein kann.

Voraussetzungen für erfolgreichen Angriff

  1. Die Anwendung akzeptiert Json von Clients, das manipuliert werden kann. 
    • Bei der Kommunikation zwischen 2 Anwendungen, die sich in einer Trustzone befinden, sollte diese Gefahr nicht gross sein, da darauf vertraut wird, dass keine bösartigen und manipulierten Json Strings verwendet werden.
    • Wurde die Trustzone allerdings kompomittiert, dann fällt dieses Argument, so dass man auch bei interner Kommunikation weitere Maßnahmen vorsehen sollte.
  2. Die Anwendung beinhaltet im Classpath mindestens 1 Gadget-Klasse, mit der ein Angriff ausgeführt werden kann.
    • Da in einer Anwendung meist sehr viele Klassen über transitive Abhängigkeiten enthalten sind, sind auch viele bekannte Gadget-Klassen verfügbar. Selbst im JDK existieren Klassen, die als Gadgets missbraucht werden können.
    • Aus diesem Grund trifft auch diese Voraussetzung streng genommen immer zu.
  3. Die Anwendung hat aktives polymorphes Typehandling für Felder mit dem Type Object aktiviert (oder andere allgemeine Typen wir Serializable, Comparable, …)
    • Dies wird im Code über die Methode org.codehaus.jackson.map.ObjectMapper.enableDefaultTyping() aktiviert
  4. Die Anwendung verwendet Jackson-Databind in einer Version, die (noch) keine fragwürdige Gadget-Klassen blockiert via Blacklisting.
    • Ist die Jackson-Version aktuell, dann ist es sehr schwer, aber nicht ausgeschlossen, Gadget-Klassen zu finden, die einen Angriff zulassen.

Da (1) und (2) nie komplett ausgeschlossen werden können, sollten wir uns auf (3) und (4) fokussieren.

Folgendes ist noch festzustellen für die beiden Ausprägungen:

  1. Polymorphie: Anhand des Parameters valueType wird über die Annotation JsonTypeInfo definiert, welche „Zielklasse“ bei der Deserialisierung verwendet werden soll. Das ist entweder diese übergebene Klasse valueType selbst oder wird wiederum durch Annotationen dieser Klasse bestimmt. Durch die Annotation JsonTypeInfo kann definiert werden, dass die tätsächlich instanzierte Klasse, durch einen Parameter innerhalb des JSON-Textes vorgegeben wird, was bedeutet, dass der Sender des JSON-Textes die Entscheidung trifft. Die Entscheidung ist nicht völlig frei: die instanzierte Klasse, muss eine Erweiterung der Klasse valueType sein. Jackson bietet dazu mehrere Möglichkeiten. Die Kritische ist die, bei der Klassenname, bzw. ein Teil des Klassennamens, als JSON-Inhalt definiert/ausgewertet wird.
  2. DefaultTyping: unbestimmte/generische Attribute – beispielsweise von Type Tattr Object – können bei eingeschaltetem DefaultTyping mit Objekten befüllt werden, deren konkreter Typ Tconc durch den JSON-Inhalt bestimmt wird. Im Falle des Attributstyps Tattr Object unterliegt Tconc lediglich der Einschränkung, dass Tconc im Klassenpfad zu finden sein muss.


Ein Beispiel für eine gefährliche Codestelle ist folgende:

public class Person {
@JsonTypeInfo(use = Id.CLASS)
public Object phone;
}

Hier wird über @JsonTypeInfo der Klassenname angegeben, so dass dieser in der Json Struktur über die @class Annotation angegeben werden kann. Ist DefaultTyping aktiviert, dann kann an Stelle des Typs Object eine Gadget-Klasse treten, die der Angreifer angibt.

Prävention

  1. Immer die neueste Jackson-Databind Version verwenden
    • denn diese enthält die vollständigste Liste der gefährlichen Gadget-Klassen in der Blacklist
    • das ist kein perfekter Schutz, aber das mindeste was man tun sollte
  2. Default Typing vermeiden
    • statt dessen explizit die Klassen angeben, die bei der Deserialisierung verwendet werden sollen
  3. Allgemeine Klassen wie Object, Serializable, … vermeiden in den Objekten, die übertragen werden
    • dadurch wird vermieden, dass beliebige Klassen für den Angriff verwendet werden können
  4. Möglichst „type name“ verwenden und nicht classname als Type-Id
    • @JsonTypeInfo(use = Id.NAME)  anstatt  @JsonTypeInfo(use = Id.CLASS)

Referenzen

Sicheres Passwort?

Wann ist ein Passwort eigentlich sicher?

Als Benutzer werden wir dazu erzogen, komplexe Passwörter zu verwenden. Aus gutem Grund werden zu einfache Passwörter zumeist abgelehnt, da Passwörter die in einem Wörterbuch vorkommen, innerhalb weniger Sekunden geknackt werden können durch einen sogenannten Wörterbuch-Angriff. Auch ein „123“ davor oder dahinter bringen da nicht viel, da man solche Varianten dabei gleich mit prüft.

Wenn nicht mindestens Gross- und Kleinbuchstaben, sowie Zahlen und Sonderzeichen verwendet werden, kommt man bei immer weniger Systemen weiter bei der Passwortauswahl. Leider wird oft auch nur ein roter Balken angezeigt, zusammen mit einer Warnung. Passwörter mit weniger als 12 Zeichen gelten aber auch als unsicher, wenn sie diese Kriterien erfüllen.

Lang soll es also sein. Mehr als 12 Zeichen. Und es darf nicht in Wörterbüchern vorkommen.

Alles Nutella?

Nutella findet es anscheinend sicher genug, ein 7-stelliges Passwort zu verwenden. In einem Tweet rufen sie dazu auf, mit „Nutella“ seine Geheimnisse zu sichern. Ein schlechter Scherz, dem leider vermutlich zu viele folgen:

Die am häufigsten verwendeten Passwörter sind eine Katastrophe. Mehr als 5 Millionen gekaperte Passwörter wurden durch SplashData statistisch ausgewertet. Zum fünften Mal in folge wurde „123456“ als das am meisten verwendete Passwort des Jahres ermittelt, gefolgt von „password“. 

Hier die aktuelle Top-10 Liste:

  1. 123456
  2. password 
  3. 123456789
  4. 12345678
  5. 12345
  6. 111111
  7. 1234567 
  8. sunshine
  9. qwerty
  10. iloveyou

Den meisten Benutzern ist anscheinend nicht klar, dass sie durch derartigen Leichtsinn riskieren, Opfer von automatisierten Angriffen zu werden. Es kann sehr schnell passieren, dass ein Erpressungs-Trojaner dann die Dateien auf dem eigenen PC verschlüsselt, so dass sie nicht mehr zu lesen sind. Nur durch Zahlung von einigen tausend Euro bekommt man seine Dateien dann wieder entschlüsselt, zusammen mit dem unguten Gefühl, nicht mehr Herr seiner Privatsphäre zu sein.

Doch was tun, wenn man sich für unzählige Konten Passwörter merken muss, die man dann auch noch regelmäßig ändern soll? Auf gar keinen Fall sollte man übrigens das gleiche Passwort für mehrere Konten verwenden, denn ist eines der Konten kompromittiert, haben die Angreifer dann auch gleich Zugriff auf die anderen Konten, wo das gleiche Passwort gilt. „Credential Stuffing“ nennt man einen solchen Angriff, bei dem bekannt gewordene Zugangsdaten bei anderen Webseiten ausprobiert werden. Die Erfolgsrate ist dabei relativ hoch.

Was also tun?

Solange wir uns mit Benutzernamen und Passwörtern authentifizieren müssen, sollten wir Passwortmanager-Programme verwenden. Dort werden die Passwörter sicher verwaltet, und durch Copy&Paste in die Webanwendung übernommen. Das hat den Vorteil, dass wir sehr lange und komplexe Passwörter verwenden können, die kein Mensch von Hand eintippen möchte. Es spricht also nichts dagegen, ein 100-stelliges Passwort zu verwenden, wenn das von der Webanwendung unterstützt wird. Ein Brute-Force-Angriff wird das nicht so schnell knacken können, so dass die Angreifer weiterziehen werden, und es mit anderen Opfern probieren wird, die es noch nicht kapiert haben.

Folgende Passwortmanager-Programme sind gängig:

  • KeePass
  • LastPass
  • Dashlane
  • 1Password
  • StickyPassword
  • Steganos Passwort-Manager

Sichererer?

Noch besser als sehr gute Passwörter zu verwenden ist, wenn man neben diesen auch noch ein weiteres Merkmal verwendet, wir ein Token, das z.B. über eine Authenticator-App generiert wird. Multifakor-Authentifizierung ist der Fachbegriff dafür. Dadurch ist es für Angreifer nicht mehr möglich, durch abgefischte Passwörter den Account zu übernehmen. Im Online-Banking Bereich setzt sich das mehr und mehr durch, auch wenn viele Banken nach wie vor SMS als 2. Faktor verwenden. Dass das nicht sicher ist, darüber habe ich in einem vorigen Post berichtet.