The Non-Technical Explanation of Cross-Site Scripting (XSS)

The Non-Technical Explanation of Cross-Site Scripting (XSS)

Let's all reminisce back to the days of static web pages. Before there was a library of JavaScript for every day of the year, web development was much less complicated. There were no fancy animations, no e-commerce stores, and, most importantly, no user input. Wait, is this whole article seriously about why user input ruined the internet?

Woah, don't jump to conclusions there! Yes. User input introduced challenges unforeseen in old-school static pages. Web developers were now forced to give up some control and accept data from untrusted sources. Hackers discovered how to take advantage of user input as a foot halfway into the door, only the door was left open intentionally for valid reasons.

Computers speak binary code, A.K.A ones, and zeros. However, coding applications in millions of ones and zeros is unrealistic. Fortunately for software developers, humans made this process much simpler by building language-like commands that are then transformed into those ones and zeros. This transformation is made possible by a piece of software called the compiler. The compiler turns programming keywords such as "new," "continue," or "this" into their respective bits of ones and zeros. These keywords, and many symbols, are given unique meanings by the compiler. Consequently, by the end-user entering keywords or symbols relevant to the compiler, programs can easily misinterpret seemingly valid input for extra commands.

Cross-Site Scripting (XSS for short) is a fancy word for injecting rogue web code into websites. Often times this rogue code is introduced through improperly sanitized input fields. When a programmer accepts input, they are supposed to ensure that none of these keywords or symbols make it past to be executed by the program. This process is known as input sanitization. So XSS only introduces security flaws for the website itself, right? Wrong.

XSS runs as a client-side script, a term in web development for scripts run by the client browser and not the server. XSS will typically only affect the end-user and can go largely undetected by the server. A successful XSS attack can implement keylogging technology, download malware onto a device, and even steal authentication data.

While XSS is the general term for any attack utilizing injected rogue JavaScript code, several variants of XSS attacks exist. Reflected XSS, the most common variant, allows application data to pass through a URL. This attack is often paired with social engineering as it is not embedded in the website. Stored XSS, however, can operate solely, almost as a Watering Hole type attack, to exploit client browsers. Stored XSS attacks will most commonly be found on websites that allow users to leave comments or upload custom text content.

Explanation of XSS Attack Variants

Want to learn more about XSS attacks and how they are exploited in modern web applications? Read more and learn how to create a Stored XSS attack with real-world examples here!