What Exactly It is:
A new variant of Cross Site Scripting Attack came into picture recently based on the way how it can be exploited and the state of payload triggering.
Let me take you through basic concepts of XSS.
Classified as below based on the way of Exploitation.
RXSS – Reflected XSS – Name suggests executes only once when victim clicks on the link.
Demo is available at Google App Security
SXSS – Stored XSS – Name suggests payload stored somewhere and executes everytime whenever victim/admin of site visits that place.
Demo is available at Google App Security
DXSS – Type Zero XSS – DOM XSS- Above two scenarios will keep in touch with server to execute the payload but Document Object Model based XSS don’t need any help from server which can be possible by abusing Browser’s Document Object Model Environment.
Open this link in new tab Google App Security
SXSS – Self XSS – Might be anyone of above kind and can show impact on single user itself instead of impacting others.
Nice Examples – SXSS
UXSS – Universal XSS – Special kind which can be triggered by exploiting browser based flaws to hijack user data. See the PoC here.
Interested…?? – Dig deeper – UXSS
MXSS – Mutation XSS – Discovered by Mario Heiderich. This mXSS may occur in innerHTML. This vulnerability affects major browsers like IE, Firefox, Chrome etc.
Famous applications like Yahoo, Rediff mails, Zimbra etc like commercial products were vulnerable to mXSS. This type of XSS vectors managed to bypass widely deployed server side XSS protections techniques like HTML purifier, Kses, htmlLawed etc. and client side filters like XSS auditor, IE XSS filter, WAF systems, IDS and IPS.
save below code as test.html and open in any browser. You can see the magic.
<html><body> <listing id=x><img src=1 onerror=alert(1)></listing> <script>alert(document.getElementById('x').innerHTML)</script> </body> </html>
FXSS – Flash Based XSS – Also known as XSF (Cross Site Flashing). Another way of performing XSS via SWF files as it is used by web-based advertising and dynamic web or social networking sites.
A basic demo available here – FXSS
Depth analysis from Decompilation to Successful Exploitation by Smiegles
Awesome, now we are little bit aware of most of the possible XSS Scenarios. What else, “Blind XSS” – Same but different as Stored XSS variant. As we already aware that Stored XSS is stored in application and it will trigger whenever user/admin visits that particular page where payload is lying. Instead of Same application why not it will be stored on some other internal application – Here comes the new scenario – Blind XSS.
Difficulties that i’ve came across while exploiting this issue are.
- Where my payload is stored.
- When it will execute.
- How can i get user data.
- What feature/page/application is vulnerable.
Is it similar to Blind SQL/CMDi/XXE/SSRF:
Hopefully Yes. As we know our payloads sleeping somewhere inside their internal applications, the approach lead us to believe that the scenarios as blind based attacks.
How to Detect:
Example of applications where Blind XSS vulnerabilities can occur:
- Contact/Feedback pages
- Log viewers
- Exception handlers
- Chat applications / Forums
- Customer ticket applications
- Web Application Firewalls
- Any application that requires user moderation
As a general approach we host our server and craft payload according to our need then wait for lifetime until our script triggers on victim side.
Boring right ! Here comes the automated process.
Just create your own XSS Host at XSSHunter.. It looks like https://username.xss.ht
Navigate to Payloads section and use suitable payload for your need. No need to wait for lifetime now. As long as our payload triggers we can get an automated email as below.
We can see below details in our mail.
- Vulnerable Page URL.
- Client IP
- User Agent
- Injection Point
Are There Any Alternatives:
Why not. Our community is so big and we are lucky with researchers out there. Below are the opensource frameworks available so that we can configure based on our needs to launch XSS Campaigns.