Cross Site Scripting is one of the top dangers in a modern web application. In order to exploit this vulnerability, an attacker has to “inject” malicious javascript code into the site.
According to the owasp top 10 list, XSS is the top 7 vulnerability in today’s web applications. The danger is even greater now that “native” applications are made with javascript (using electron, PhoneGap and other) and running on your local computer.
But why does it work, and how?
In order to exploit this vulnerability, an attacker has to inject malicious javascript code into the website. This usually can happen via a comment, description or similar forms and is possible because of input sanitation.
Now let’s dissect the crucial parts for this vulnerability:
- JavaScript
- Input Sanitation
Javascript
The scripting in Cross Site Scripting actually comes from javascript.
If you’re not familiar with it, here’s a little example of a javascript snippet:
<script>
function x(y){ console.log("hello world"); }
</script>
It usually starts with a <script> tag followed by some C- Style syntax. And that is the important part.
Javascript itself can ranger from easy to really hard to wrap your head around, especially when you’re new to the language or programming in general. But as mentioned before, the important part is to inject the <script> tag.
Input Sanitation
Sanitation is crucial to prevent Cross Site Scripting. It basically is a transformation from a dangerous text into a less dangerous one.
So let’s take our<script> tag and turn it into something less harmless – with encoding.
Encoding
The most common way to sanitize input is encoding. The important encodings for HTML and the web, in general, are listed here.
So if we turn a <script> into a <script> it will still be displayed as <script> but not interpreted as such, so no code can run.
Without the encoding, the script- tag will be interpreted as such and code in it will run.
The Bad News
Most new programmers and coders might not be familiar with this concept when they start out. Even experienced ones can tend to forget. And like that, a bad input sanitation (or none at all) will be implemented in a web app.
The really bad news (for developers, not hackers :P) is, that it is sufficient that just ONE form or input field is not sanitized to perform an XSS.
The Exploit
Now that we understand the basics of this attack – injecting javascript into an unsanitized (or bad sanitized) input field – we just need to apply that knowledge.
Here’s a little gadget for you to play around with. Try to run alert(1); via this input form by applying your knowledge from above.
Remember, you have to inject a <script> tag in normal HTML fashion like you would do when developing javascript. You can find the full source here.
You can watch some of my XSS Exploit videos to get some inspiration:
Wait, why are you allowing XSS on your site?
Simple: It does no real harm if the “payload” is not stored or reflected.
I won’t be saving your attacks in a database or allow URL parameters to be passed for the form, so you can’t really abuse my website for it. You can only pwn yourself.
Plus it’s illegal to hack, but here I’m giving you the permission to run alert(1); or other not damaging commands.
