XSS – Cross Site Scripting is an injection attack where users intentionally/unintentionally click links/URLs containing scripts that execute in the browser. Now this script might just throw a popup which is like a welcome message on the website – “Welcome to Ethical Hacking Tutorials” , or maybe a driver of malicious actions like stealing your cookies or redirecting to a phishing page. We will have some idea about the underlying theory that causes XSS, and move towards practical XSS.
Let’s break the above into parts for better understanding.
- You trust a website you are browsing or a link in email/sms,
- It is pointing out to another website which you maybe browsing very often or a website which has some offer or maybe just browsing is what you love, you open the link anyway.
- The browser loads the website you clicked, browser having no method to verify the link was trusted or non-trusted.
- The extracted data ( session cookies, key-strokes, phishing pages) is sent to attacker/hacker by methods like writing to external domains/websites or maybe in other exploit forms.
Event Handlers make page more interactive or reactive to events, the events like onclick, onload, onunload, onmouseover, onmouseout. So if any of these event occurs, an action can be associated with this event.
A much more comprehensive list of Event Handlers preset here, Read more.
For example the page contains onload , when the page/ associated element loads, the event can be used to trigger something. Here I am triggering Welcome message for visitors of my website when body element loads
<body onload=alert(‘Welcome to Ethical Hacking Tutorials - learn XSS’)>
When the body tag loads, that is an event, and onload is event handler which responds to event by a popup (alerting ) – Welcome to Ethical Hacking Tutorials – learn XSS.
Similarly you can think of other event Handlers.
Types of XSS
- Reflected XSS
- Stored XSS
- DOM (Document Object Model) based XSS
Reflected XSS – or non-persistence XSS
This type of XSS as name says is reflected but is not persistent. The browser executes injected code without validating the script/code which might be harmful. But the injected code/script is not stored in database or server ( like Stored XSS ). Where do I look for this bug ? Say your search Query box is taking input and same is also reflected on parts of page like – you searched for I want to learn XSS . What if you injected malicious payload with script that reflects back and executes payload(malicious script).
Input Field :
Ok, we being good guys, how can hackers use this maliciously ?
The payload can be malicious to alert a popup box saying you have been hacked , or can also get your session cookie. See below example.
<script >alert("Welcome to EthicalHackX")</script>
Or it can be really malicious revealing your secrets like session cookies.
"<script >alert("Welcome to EthicalHackX")</script>
Since this is reflected / non-persistence XSS, the page reloads or someone without the link is not affected if no payload injected. How do we proceed ? Well while sharing the links inject the payload in the link itself , see the URL in image above. We can share something like
http://192.168.56.101/dvwa/vulnerabilities/xss_r/?name=%22%3C%2Fscript%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E# , when the user/victims opens the URL , the malicious payload executes.
Why is this happening ? Source Code Review :
We can see the user input is taken as passed to browser without sanitization which is very bad practice.
Stored XSS / Persistence XSS
Unlike the Reflected XSS, stored XSS is stored in database/server. Whenever you browse the page where the stored payload is appearing, it executes ( if not sanitized ), and boom, again the same thing like above. The difference is hacker does not has to send crafted links, anyone browsing the page sees the same thing, and browser does what it does the best – execute the stored payload on page. Unlike Reflected XSS, the payload does not vanishes if you dont use crafted URL, as it is stored on page already. And you can now distribute the page URL everywhere, post it on groups, social media as some clickbait and see the malicious code do the magic. Lets see by example.
While all this benefit the programmer to make a more dynamic page, the same can also be used by attacker/hacker maliciously when the input is not properly sanitized.
Unlike Stored or Reflected XSS, any data/payload is not going to server , but the whole process happens on the client browser itself and hence it is difficult to detect.
DOM Based XSS Example
Ok, Bye Theories, What I do now ?
So from above reading , you now know that you can associate events to response. Say you crafted a URL that is redirecting to fake websites, acting as clickbait, or stealing session cookies ? We will see how to make payloads or beter say bypass the security in place for XSS in next post, we will also learn about how to exploit XSS Vulnerability rather than just throwing random alerts.