We will talk here about the Cross-site scripting kinds of attacks, or if you prefer-XSS attacks. If you are long enough into a tech’s world, there is no way that you haven’t heard about XSS before. But if you haven’t, don’t worry, I will guide you through this tutorial which will help you to learn everything you need to know about it.
Cross-site Scripting Description
This is a kind of the issue which refers to the client-side code. Here, the attacker has a purpose to execute some very malicious scripts, which are mostly connected to those that belong to payments. So, this injection is executed in some legitimate browser. Have you known that XSS is the highest web app vulnerability? It mostly occurs once a web app is using some of the unvalidated user input. Of course, the usage applies to the output it actually generates. It is the truth that the attacker here doesn’t attack the victim directly, he or she doesn’t even target the victims. What do they do instead of it? You will hear in the next part of this lesson!
Cross-site Scripting Impact
I have explained you the basic stuff about how cross-site scripting works, and then I have mentioned that the attacker here doesn’t target the victim. Yes, that is the truth. But, what he does then? He always prefers to exploit that vulnerability within those website or web apps that the victim would visit. That was easy to guess? Well if you ask me, I wouldn’t agree with that. The things are much complicated here than we thought. Let’s say the attacker has exploited the vulnerability and what happens later is that those apps or web servers will always deliver a malicious script to the browser of the victim, every single time they visit them or use the app. The most abused in this story is JavaScript. Why Java? Because it is a default and most fundamental within the browsing experiences. I will show you through the example how it works and what it does. I think you will understand it the best that way.
Example Of Cross-site Scripting
Let’s say that you need to run JavaScript code not knowing that it is malicious. You will act the same like always, right? But how the attacker’s mind works? If he wants to run it, the first thing he needs to do is to find a proper way to inject a payload. He will try to inject it into a web page which the victim is visiting, of course. There is another thing about how it is able to achieve it. He can also refer to social engineering. In that case, he will try to convince the victim to visit a website. Of course, he will aim for that one which has injected JavaScript payload.
This is how looks like an XSS vulnerable website:
print ”<html>”
print ”<h1>Most recent comment</h1>”
print database.latestComment
print ”</html>”
Do you see something malicious here? What is a threat is that the <script>doSomethingEvil();</script> code stays hidden, but once you open it will appear.
<html>
<h1>Most recent comment</h1>
<script>doSomethingEvil();</script>
</html>
Most of the times user won’t be able to recognize and to stop this attacks. But we will talk about that later, you know that we have a solution for literally everything!
Attacks Of Cross-site Scripting
When talking about this highly-dangerous injection, you need to know that it has various types. I will explain you all of those now. The first one is called reflected, which means that it is non-persistent. This is the basic web vulnerability. It is also far more common. The example would be that the existing vulnerabilities in Google may allow the malicious sites to attack the Google’s users, those that visited them while being logged in. The second type is called persistent or stored. Most of the times this type is coupled with a computer worm. They together allow the execution of the arbitrary code and listing on the filesystem. The next type is called DOM-based XSS flaw. Here the arbitrary HTML with scripts together could be simply injected and all that just by using some types of the force error messages. Self-XSS, our next type of the enemy. This one relies on the social engineering tips about whom I already talked about. The last type is called mXSS, or a mutated form. This is a form which almost cannot be seen once it has been performed, and about whom I’ve also already talked about.
How To Fix Cross-site Scripting
Yes, I have said that it is almost impossible to fight against these issues. But, there must be something we can do, right? Let’s see what is in our power… We can take some preventing measures! The first thing you need to be sure that you have done is contextual output encoding. Along with that encoding goes the escaping of the string’s input. Second thing, always be sure that you have validated safely the untrusted HTML inputs. Also, it is recommended to check your cookie security and to disable the scripts. If all else fails, turn to the emerging defensive technologies! For example, Content Security Policy, JavaScript sandbox tools or try auto-escaping templates.
Afraid of XSS? You should be. But, not if you try to learn this lesson and to implement it in your cyber life