Secure Programming of Web Applications: Cross-Site Scripting (XSS)

Added at 11/27/2020 by Frank Hissen

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access.

This is an excerpt from the book "Secure Programming of Web Applications: Web Application Security for Software Developers and Project Managers", also available as eBook
A corresponding online (video) training course exists: Online Course 'Web Application Security', also available on Udemy, and on request as HTML5/SCORM/Audio comment version

Description

Cross-site scripting (XSS) is one of the most common security vulnerabilities in web applications. It is often underestimated but can cause a lot of damage and especially follow-up attacks (e.g., session-hijacking). The root cause for XSS holes is completely missing or incomplete output encoding (correspondingly for HTML, JavaScript, ...). A false assumption about the source data which the web application uses to create its output can also sometimes be traced back to wrong input validation and filtering.

In case of insufficient output encoding the attacker is able to add own code into the web application that is executed at the user-side. This can be pure HTML commands or JavaScript code. In this case, the attacker gains full access within the user's current context within the web application.

To be able to execute this (malicious) code, the attacker must trick its victim to call manipulated URLs. This is possible through direct channels (e.g., embedding the code in shared areas of the application) or other channels like third-party pages or phishing mails (compare chapter "Hacking Anatomy"). The following types of cross-site scripting exist:

1. Persistent: The attacker is able to store own code - despite input filters and output encoding - within the web application. An example would be a guest book function whose entries are visible to all site visitors. Of course, in this case also users that are not logged in are affected by a successful attack. For instance: The attacker might able to store this code
   <script>alert('XSS')</script>
   under a certain URL, e.g.,
   https://example.com/guestbook?entry=99123
   Each visit of this web page entry from within the application/site or clicking the link from somewhere else leads to the execution of the attacker's malicious code.
2. Reflected: The web application puts the content of URL parameters directly into its HTML output. The attacker is able to add own code this way - despite input filters and output encoding. A typical example are search functions. For instance, the following search parameter could be vulnerable:
   https://example.com/search?query=search+term
   The attack code
   <script>alert('XSS')</script>
   embedded into the URL would look like this:
   https://example.com/search?query=%3Cscript%3Ealert(%27XSS%27)%3C/script%3E
   When calling the link, which simply points to the web application the user is familiar with, the malicious code is executed.
3. DOM-based: The DOM-based type works very similar like the type "reflected". However, in this case the vulnerable URL parameter is not included by the web application on the server-side but on the client-side - for instance through JavaScript. Again, the same manipulated URL is created by an attacker. The flawed code is delivered by the web application (JavaScript) but the execution takes places on the client.

Secure Programming:

Preventing XSS vulnerabilities is simple and basic: Encoding of all functional characters within the respective application context - mostly HTML and JavaScript (but also XML, JSON and - if used - plugins). Many development environments include (external) libraries to perform the adequate encoding, because it is such a common problem. However, it is the developer's responsibility to apply it to all parameters of the application. The encoding has to be realized following these rules:

Essential is the clear - at best central - coverage of all code segments which process user data

→ The best encoding is useless when it is not applied to all relevant parts of the application!

The most important encoding rules to convert characters of user inputs:

• & to &
• " to "
• < to &lt;
• > to &gt;
• ' to &#39;

Keywords

Secure Programming, Web Applications, XSS, Cross-Site-Scripting, Web Application Security, Software Developing, Secure Code/Coding, Security Awareness

Categories: IT Security Background articles Development/Java

---

Comments

Post your comment

Share

If you like this page, it would be a great thing if you share it with others:

reddit Digg StumbleUpon XING
WhatsApp Telegram