Cross-Site Scripting and Cookies, a Delicious Disaster
If you read our previous article, "The Non-Technical Explanation of Cross-Site Scripting," you probably have a solid idea of what Cross-Site Scripting (XSS) is. While good Whitehats understand the theory behind a vulnerability, great Whitehats dig a little further. Today we'll show an example of XSS on a demo blog I created using Django- a Python web framework. Our vulnerable blog, 'XSS Blog,' is publicly available on my GitHub for your learning benefit. Feel free to make changes, fix, and break all the things! Let's dive in, shall we?
To understand the complete picture of an XSS exploit, you'll first need to understand how websites authenticate users. Websites communicate over a protocol known as Hyper Text Transfer Protocol, HTTP for short. For those of you who may be new to networking, a protocol is simply a guideline for how computers can communicate efficiently. HTTP is a stateless protocol, meaning the previous request is unknown in a session of multiple HTTP requests. For example, imagine a conversation between people that can't remember what they're talking about. While there are a variety of solutions to this problem, we'll be discussing the most delicious one.
Cookies are byte-sized storage artifacts placed onto your computer by a web server. They often hold user information for the web server, such as authorization data and account preferences. Upon successful authentication to a website, the server issues the client a cookie. This cookie is then sent back and forth upon each new request. Without cookies, a client would be forced to authenticate to a website on each new request. As far as authentication is concerned, the cookie will often be a "sessionid" variable with a unique string only understood by the server. This string of characters represents a session id which should be lengthy and arbitrary. When that arbitrary string is passed to the web server, it can be used as proof of previous authentication. Therefore, theoretically, an attacker can impersonate a user if they capture their session id. Note that cookies are not inherently the most secure thing ever created. They are stored in plain text, A.K.A unencrypted, for all prying eyes to see.
After authenticating with XSS Blog using the provided credentials in the README.md file, we can inspect our first cookie. I'm utilizing Google Chrome's built-in console, but you can use any modern browser. If you're following along with Chrome, navigate to the "Application" tab, then click the "Cookies" dropdown on the sidebar.
This attack is the gift that keeps giving- it truly does get better! Think about what happens when a comment is submitted to a website. The comment is stored in a database for future rendering. Not only did we demonstrate a successful XSS exploit, but we also created a Stored XSS. Any user that visits this page will be automatically compromised by our simple comment. Depending on the popularity of the "A Random Post" page, a significant portion of the XSS blog's user base could easily be compromised. Ladies and gentlemen, I present the dangers of a cross-site scripting attack.