Gaesss ini adalah hasil temuan saya di sebuah fintech yang senilai 2M (Makasih Mas) sebenarnya ingin sekali saya tampilkan nama fintech ini namun CEO nya berkata saya tidak boleh mempublish nya 🙂 cuma karena saya agak bar-bar, jadi saya sensor sadja h3h3.
Oh iya, POC ini saya tinggal copy-paste saja dari PDF yang saya kirimkan, dan sebelumnya sudah saya posting di blog pribadi saya (disini), saya sangat malas untuk translate nya kedalam bahasa indonesia, waktu itu saya buat bahasa inggris karena ingin mencoba agar terlihat “internasional dikit” h3h3. Enjoy!
Blind Stored cross-site scripting (also known as second-order or persistent XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.
If an attacker can control a script that is executed in the victim’s browser, then they can typically fully compromise that user. The attacker can carry out any of the actions that are applicable to the impact of reflected XSS vulnerabilities.
In terms of exploitability, the key difference between reflected and stored XSS is that a stored XSS vulnerability enables attacks that are self-contained within the application itself. The attacker does not need to find an external way of inducing other users to make a particular request containing their exploit. Rather, the attacker places their exploit into the application itself and simply waits for users to encounter it.
- An attacker can control a script that is executed in the victim’s browser, then they can typically fully compromise that user.
- Stealing credential user (cookie).
- Log in as a different user (like another user’s or admin).
- Stealing Information from another user’s or admin account.
Steps to Reproduce
- The Concept.
I log in as a user account.
Go to “Tanya Jawab” page > “Hubungi Admin” > choose one admin > Send her “malicious” message.
To make a malicious message, I use the feature of https://xsshunter.com and the payload is:
- And I pretended to ask questions (random question).
- Intercept request with a burp, and get a response with the HTML tag that will be sent, and at this stage, I assume that we can send malicious code into our destination email (in this case the admin email).
- Then I paste the malicious code that I previously made on https://xsshunter.com.
- The injection phase has finished, now it’s just a matter of time when the admin opens an email from me containing malicious code.
- After waiting for about 2-3 days, I got an email notification stating that the admin has opened the email I sent and the code has been triaged! YAY!
To keep yourself safe from XSS, you must sanitize your input. Your application code should never output data received as input directly to the browser without checking it for malicious code. (source)