thecodest, Author at The Codest

XSS

Wir leben im Zeitalter der Rahmenwerke, nicht der Sprachen. Das bedeutet, dass sich Programmierer um viele Aspekte der Entwicklung, einschließlich der Sicherheit, weniger Sorgen machen sollten. Die meisten der aktuellen Backend-Frameworks implementieren Sicherheitsmodule, die von externen, spezialisierten Unternehmen und großen Gesellschaften getestet werden. Deshalb, abnehmendes Sicherheitsbewusstsein könnte sich zum Beispiel zwischen jungen Programmierern zeigen, die mehr Verantwortung für die Produkte übernehmen, vor allem im Bereich der Freiberuflichkeit.

Einer der häufigsten Angriffe auf der Client-Seite der Anwendung ist XSS (Cross-Site Scripting). Es wird durch das Einschleusen von ausführbaren clientseitigen Skripten in Webanwendungen [1] durchgeführt und nutzt implementierte HTML-Rendering-Methoden oder Javascript Code Auswerter, die es ausführen. XSS ist relativ lukrativ, da viele verschiedene Daten gesammelt werden können, darunter Sitzungscookies oder Benutzerdaten, und es kann eine Tracking-Anwendung wie ein Keylogger installiert werden, was es sowohl für Benutzer als auch für Unternehmen gefährlich macht. Manchmal werden auch andere Formen von Angriffen durchgeführt, um XSS auf der Seite zu ermöglichen, wie z. B. SQL-Einschleusung.

Beispiel

Das Anmeldeformular auf der Seite gibt den in der GET-Anfrage gesendeten Parameter loginName in der Eingabe des Anmeldenamens wieder. Der Wert wird weder vom Server noch von der Client-Seite der Anwendung verarbeitet. Durch Anfrage: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
Code wird ausgeführt und Daten werden offengelegt

Dies ist ein Beispiel für eine reflektierter XSS-Angriffbei denen Skripte über speziell vorbereitete URL-Adressen eingeschleust werden, die dem Opfer übermittelt und von der Serverantwort reflektiert werden. Andere bekannte und beliebte Formen von Angriffen sind die folgenden:

Gespeicherte XSS mit injizierten Daten, die auf der Serverseite gespeichert sind, in der Regel durch in der Anwendung verfügbare Formulare. Die Client-Anwendung rendert Code, der z. B. in einer Datenbank gespeichert ist.
DOM XSS führt einen XSS-Angriff durch, ohne die Serverseite zu nutzen. Im weiteren Teil des Artikels werden wir uns auf diese Form des Angriffs konzentrieren.

Aktuelle Sicherheitslücken in den Bibliotheken React und Vue

Für die aktuellen Versionen React/Vue wurden zwei größere Probleme entdeckt, die noch nicht offiziell behoben sind. Die erste Schwachstelle ist bei allen Frameworks gleich und hängt mit Methoden zusammen, die das Rendering von Roh-HTML in Vorlagen ermöglichen: v-html und dangerouslySetInnerHTML, respectively, for Vue and React. Each documentation [2] informs readers that unwise usage may expose users to XSS attack. If no other options allow for resolving the problem, ensure that the data is gefiltert und entkommen. Obwohl sie gefährlich sind, sollten Sie nicht erwarten, dass diese Methoden repariert werden. Verwenden Sie sie auf eigene Gefahr.

Im ersten Quartal 2018 wurde ein großer Fehler in React entdeckt, der die direkte Ausführung von Code durch Setzen der Eigenschaft für ein Tag-Element ermöglicht. Die Übergabe von Beispielcode innerhalb von Attributen, wie z. B. javascript:alert(1) und das Ausführen eines gerenderten Links wird den Code ausführen. Dieses Problem [4] ist immer noch offen und es wurde noch kein Fix vorbereitet und zusammengeführt, also stellen Sie sicher, dass Ihr Code sicher ist. Die in der offiziellen Diskussion vorgeschlagenen Beispiele bieten einige Möglichkeiten, dieses Problem zu lösen.

Wenn eine Aktualisierung auf die neuesten Versionen nicht möglich ist, sollten Sie sicherstellen, dass alte Probleme nicht zu Problemen führen, indem Sie dafür sorgen, dass Ihr Code nicht offengelegt wird:

Kind Knoten Einspritzung - React, Verwendung von React.createElement [5]
serverseitiges Rendering - React/Vue [6]
CSS-Injektion [8]

Es geht immer noch um Javascript. Es geht immer noch um Front-End

Vergessen Sie nicht, dass Javascript als Sprache neben den Frameworks oder Bibliotheken selbst auch einige gefährliche Funktionen hat, die vermieden oder mit Vorsicht verwendet werden müssen. Sie stehen im Allgemeinen im Zusammenhang mit der DOM-Manipulation oder der Ausführung von Skripten. eval() repräsentiert Flaggschiff-Funktionen dieser Art und ist extrem gefährlich, da sie gegebenen stringifizierten Code direkt ausführt [9]. Schauen Sie sich also Ihren Code besser an, wenn Sie eine dieser Funktionen finden:

Dokument.schreiben
document.writeln
(Element).innerHTML
(Element).outerHTML
(Element).insertAdjacentHTML

Hier kann die Verwendung von Linters mit einem geeigneten Regelwerk hilfreich sein, um solche Schwachstellen zu finden. Es gibt auch viele offene oder kommerzielle Code-Analysatoren, die Ihnen helfen können, Sicherheitslücken in entwickeltem Code zu entdecken.

Unabhängig von der Wahl der Bibliothek/des Frameworks müssen wir uns an grundlegende Prinzipien der Front-End-Entwicklung erinnern. Erstens: Stellen Sie immer sicher, dass der externe Code, den Sie einfügen, aus einer vertrauenswürdigen Quelle stammt. Prüfung Ihre Abhängigkeiten, und wählen Sie sie mit Bedacht aus. Einige können schwerwiegende Sicherheitslücken enthalten, die Ihren Code angreifbar machen, auch wenn mit dem Code selbst alles in Ordnung ist. Mehr über die Sicherheit von Abhängigkeiten können Sie hier lesen:

https://thecodest.co/blog/security-in-javascript-packages/

Sollten Sie sich also immer noch Sorgen machen?

Ja - und ich empfehle jedem, sich in puncto Sicherheit niemals auf externe Bibliotheken oder sich selbst zu verlassen. Egal, wie sicher Sie Ihre Software einschätzen, bemühen Sie sich immer, sie so weit wie möglich auf gängige Angriffsformen hin zu testen [10].

Lesen Sie mehr:

5 Fehler, die Sie bei der Pflege eines Projekts in PHP vermeiden sollten

PHP Entwicklung. Symfony Konsolenkomponente - Tipps & Tricks

Warum brauchen wir Symfony Polyfill (... und warum wir es nicht brauchen)