Let’s talk Cross-site scripting (XSS):
- What in the world-wide web is a XSS attack?
- Implementing a XSS on Chatterbox-client side!
- How we can protect our chatroom from malicious classmates?
Cross-site scripting (XSS) is the most common form of attack on web applications and websites. “Malicious users” can inject their own code into a web app on the client-side by writing their code in an input form, posting a comment, posting on a message board, the list goes on (which is terrifying). There are various other ways to implement XSS attacks, but for the purposes of this article (and my sanity as a novice coder), let’s just focus on using script tags.
If a site is not protected, then depending on the nature of the “malicious code”, one’s webpage color might change, or they might see a pop-up alert every time their page is loaded or they click “submit”. This code may send unwanted emails with malicious urls. Most hax0rs use it to obtain sensitive user information or their cookies, which may hold saved user login information or install malware, and all just by writing their code into input forms! (Bolded and italicized to emphasize how easy it is to implement an attack.)
Let’s pretend we want to implement a XSS attack. We would never want to do this on a public website that does not belong to us because that is illegal :) Instead, we will take a look at how to implement an XSS on a classic Chatterbox-Client sprint.
The layout of the Chatterbox chatroom is an input bar and a message board. The site allows users to create and submit posts for anyone in the chatroom to see. To implement an XSS attack, one need only write script tags with their desired output inside: => (<script>evilFunction()</script>). So not chill!!! In the example below, I have written out malicious code that would create a pop up box alerting my classmates who have yet to protect their Chatterbox chatroom from XSS attacks that they have, in fact, been hacked by me, a l33t hax0r.
If my partner and I had not protected our website from XSS attacks and one of our classmates had posted this code, this message would pop up every time the page loads. We would not see this code in the message board, but we could see this script tag in our index.html file. It would look like:
The alert is an example of one way malicious users can inject code, but the code could be anything: changing the background of our webpage to another color or bolding all the text — just to name innocent examples.
We protected ourselves from sneaky classmates by encoding the information submitted users interacting with our Chatterbox.
In the message template created each time a user submits a post, we surrounded our text with “%-…%”. This turns all user submissions to strings so that they cannot be injected into our HTML. Thus, even if a classmate were to submit a script tag with malicious code, we would see the script tag as a string and it would not have any bearing on our code.
In the example below, we escape the created room using the characters “%= … %”. According to ejs.co, this “outputs the value into the template (HTML escaped)”.
There are various other ways to protect yourself from XSS attacks and other well-known client-side attacks out there, but this will be your best bet as a novice learning to code and working on the Chatterbox-client sprint project. Thanks for reading, and remember: use protection!
Xoxo, Gossip Girl
