You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
Yato03
changed the title
⚠Critical Cross-Site Injection (XSS) in TextArea elements⚠
⚠Critical Stored Cross-Site Injection (XSS) in TextArea elements⚠
Dec 24, 2024
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.
The text was updated successfully, but these errors were encountered: