Vulnerability description
HTML injection and JavaScript execution in forms related to TextArea funcionality.
This vulnerability allows attackers to inject malicious code to impersonate a victim user by looking to an evidence or an user description. If the victim browser is outdated, the vulnerability allows to get remote access control of the victim machine.
To Reproduce
This is an example of malicious use of XSS. In this example I'll use two users: John Doe, a normal user and Margaret Hendricks, a coordinator. John Doe is going to make an evil evidence in order to accept itself when Margaret views it.
Steps to reproduce the behavior:
- Creation of the evil evidence. John create an evidence with a JavaScript payload:
We save it in draft in order to save the payload in the database. By now, the payload doesn't work.
Payload:
<script>var l = window.location.href.split('/'); var index = l.length-1; window.location="http://localhost/21/coordinator/evidence/accept/"+l[index];</script>
Change the domain name by yours.
- John edit again the evidence:
- John save the evidence in draft again.
By now, the payload is working. John's ittention is saving the payload working in the database.
- John publish the evidence.
Now, John publish it to send it to Margaret.
- Margaret views the evidence
When opened, the malicious code is executed.
- The payload successfully accept the evidence.
With a more complex payload we can achieve exploits like changing the password of the victim.
Why is it vulnerable?
When we send the payload the first time, it isn't interpreted:
When we open it, the actual functionality of interpreting the styles like bold, italic, etc. render the malicious HTML tags.
Now, if we save it again, the payload working is uploaded to the database and ready for being used.
To sum up, I think problem is how the system can save it in a safe way and not letting the textarea to render it.
Critical Stored Cross-Site Injection (XSS) in TextArea elements
Vulnerability description
HTML injection and JavaScript execution in forms related to TextArea funcionality.
This vulnerability allows attackers to inject malicious code to impersonate a victim user by looking to an evidence or an user description. If the victim browser is outdated, the vulnerability allows to get remote access control of the victim machine.
To Reproduce
This is an example of malicious use of XSS. In this example I'll use two users: John Doe, a normal user and Margaret Hendricks, a coordinator. John Doe is going to make an evil evidence in order to accept itself when Margaret views it.
Steps to reproduce the behavior:
We save it in draft in order to save the payload in the database. By now, the payload doesn't work.
Payload:
By now, the payload is working. John's ittention is saving the payload working in the database.
Now, John publish it to send it to Margaret.
When opened, the malicious code is executed.
With a more complex payload we can achieve exploits like changing the password of the victim.
Why is it vulnerable?
When we send the payload the first time, it isn't interpreted:
When we open it, the actual functionality of interpreting the styles like bold, italic, etc. render the malicious HTML tags.
Now, if we save it again, the payload working is uploaded to the database and ready for being used.
To sum up, I think problem is how the system can save it in a safe way and not letting the textarea to render it.