Cross-site scripting (XSS) remains a serious threat, even though the most commonly used front-end frameworks include many security features out of the box. Frameworks like React or Angular provide mechanisms to mitigate risk by default, but improper implementation or inclusion of external libraries can lead to security vulnerabilities. So developers should not rely solely on these tools, but should continue to code in a security-conscious manner and take additional defensive measures to effectively prevent XSS.
Advertisement
Martina Kraus has been involved in web development since her early years. She has always been excited about implementing large software solutions in Node.js and Angular. As a self-employed software developer, she works primarily with Angular with a focus on security in web applications.
Attackers are constantly discovering new ways to identify XSS vulnerabilities and insert malicious code into trusted websites. Due to the ongoing threat, development and security teams must regularly update their best practices and continually implement advanced security mechanisms such as Content Security Policy (CSP).
CSP plays a central role in protection against XSS because it dictates to browsers exactly what external content they are allowed to load. This article demonstrates the use of CSP as part of a layered security strategy to prevent XSS attacks and secure web applications.
Malicious code goes unnoticed with cross-site scripting
have cross-site scripting A common security vulnerability in web applicationsThis makes it possible to embed malicious code – usually in the form of JavaScript – into the pages of a trusted website. When the page is accessed, the browser executes the injected code regardless. This attack is based on the browser’s inability to distinguish between legitimate scripts from the server and malicious scripts from the attackers.
An attack typically goes like this:
- Identifying vulnerabilities: The attacker specifically looks for opportunities to insert malicious code into a web application. This often happens through input fields, for example for comments, usernames or search queries.
- Injecting code: If an attacker finds a vulnerability, he injects malicious code into the web application. This can be done directly through input into forms or indirectly through links that contain code in the URL and are sent to unsuspecting users.
- Execution of malicious code: If an unknowing victim accesses the site, malicious code runs in their browser. The attacker can then, among other things, change the displayed content, redirect the browser to a malicious website, or access cookies to impersonate the victim.
Depending on where the malicious code is stored and executed, a distinction is made between server-side XSS and client-side XSS. In the former, the malicious code is stored on the server and displayed to every user who accesses the affected page. Client-side XSS is an attack through changes to the DOM (Document Object Model) of the page in the victim’s browser, which does not require the client to obtain the affected data from the server.
The following example assumes that a web application has an XSS vulnerability. To exploit such a vulnerability, an attacker can use different payloads. The following code snippet lists some of the different options:
//index.html
Content Security Policy als Gegenmaßnahme
Die erste Version der Content Security Policy ist 2010 erschienen. Mozilla-Entwickler haben die Maßnahme in einem wissenschaftlichen Artikel ausführlich beschrieben. Sie haben darin erläutert, wie Entwickler Sicherheitsrichtlinien definieren können, um dem Browser genau mitzuteilen, welche Ressourcen eine Webanwendung laden darf. Obwohl die Idee hinter CSP auf äußerst positive Resonanz stieß, zeigte sich, dass die Kontrolle über das Laden von Ressourcen in modernen Anwendungen komplexer ist als ursprünglich angenommen. Dennoch wird CSP kontinuierlich weiterentwickelt und bleibt damit eine wichtige Sicherheitsmaßnahme. Eine zentrale Rolle moderner CSP-Richtlinien ist es, als zweite Verteidigungslinie gegen XSS-Schwachstellen zu dienen. Wirksam ist sie jedoch nur, wenn die Anwendung an erster Stelle die Nutzereingaben gründlich bereinigt. Angesichts der Tatsache, dass fast jede Webanwendung trotz guter Sicherheitsvorkehrungen irgendwann anfällig für XSS werden kann, stellt sich die Frage, wie die CSP-Richtlinie den Angreifer daran hindern kann, die Schwachstelle auszunutzen.Blockieren der Skriptausführung mit CSP
Die Content Security Policy zielt darauf ab, verschiedene Angriffsvektoren zu unterbinden. Dazu setzt CSP strikte Einschränkungen bezüglich der Ausführung von Skriptcode durch. Der folgende Ausschnitt zeigt einen CSP-Header mit einer minimalen Konfiguration:Content-Security-Policy: script-src 'self'script-src wie im obigen Beispiel, style-src, img-src, und frame-src. Für den Schutz vor JavaScript-Injection-Attacken ist die script-src-Direktive essenziell.
Jede Direktive kann einen oder mehrere Werte angeben, die festlegen woher Inhalte geladen werden dürfen. Quellen können URLs, Schlüsselwörter wie 'self' (die eigene Domain) oder 'none' (blockiert das Laden von Ressourcen dieser Art vollständig) sein.
Der Server fügt den CSP-Header in die HTTP-Response mit der HTML-Seite für den Browser ein. Die Richtlinienkonfiguration script-src 'self' teilt dem Browser mit, dass diese Seite nur Skripte ausführen darf, die von ihrem eigenen Ursprung (Origin) kommen. Sie bestimmt zudem, dass es verboten ist, Inline-JavaScript-Code auf dieser HTML-Seite auszuführen.
The CSP can ensure that only JavaScript code is allowed to run from the site where the application originates (Figure 1).
(Image: Martina Krause)
The example in Figure 1 shows an application running on https://my-site(1). With the CSP header set, the browser is only allowed to execute loaded JavaScript files that come from the same site https://my-site(2). Even if everything else is blocked, the policy also explicitly excludes the execution of the JavaScript file https://evil.de/attack.js (3).,
What does this mean for the attack vectors shown above?
first attack over It relies on JavaScript executing malicious code when the browser tries to load an image that cannot be found. Even if the code is present on the page, it is executed by the browser because of the CSP rule. script-src 'self' No inline JavaScript code.
Blocking code execution also protects against another attack vector that attempts to do the same Directly execute maliciously injected JavaScript code.
The attack finally tries to end , eine JavaScript-Datei von https://evil.de zuladen. Da https://evil.de nicht der Origin der Anwendung entspricht, wird der Browser das Laden dieser Datei verweigern. CSP blockiert also vollständig die Ausführung von potenziell zweifelhaftem JavaScript-Code.
The browser displays an error message when the CSP is violated (Figure 2).
(Image: Screenshot (Martina Cross))
Unfortunately, this also means that legitimate inline JavaScript code in the application will also not be executed. Since this is often the case, the CSP rules shown so far are not practical.
This is where the 2016 Content Security Policy Level 2 applies. Its goal is to create better compatibility with practical applications without compromising security. CSP Level 2 introduces two new mechanisms: hash and nonce.
