Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

⚠Critical Stored Cross-Site Injection (XSS) in TextArea elements⚠ #156

Open
Yato03 opened this issue Dec 24, 2024 · 0 comments
Open

Comments

@Yato03
Copy link

Yato03 commented 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.

textArea

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:

  1. Creation of the evil evidence. John create an evidence with a JavaScript payload:

1

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.

  1. John edit again the evidence:

2

  1. John save the evidence in draft again.

2-5

By now, the payload is working. John's ittention is saving the payload working in the database.

  1. John publish the evidence.

3

Now, John publish it to send it to Margaret.

  1. Margaret views the evidence

4

When opened, the malicious code is executed.

  1. The payload successfully accept the evidence.

5

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:

sending_payload

When we open it, the actual functionality of interpreting the styles like bold, italic, etc. render the malicious HTML tags.

image

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.

@Yato03 Yato03 changed the title ⚠Critical Cross-Site Injection (XSS) in TextArea elements⚠ ⚠Critical Stored Cross-Site Injection (XSS) in TextArea elements⚠ Dec 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant