Skip to content
This repository has been archived by the owner on May 19, 2020. It is now read-only.

Stored Cross Site Scripting vulnerability exists in post content. #1333

Closed
SecGus opened this issue Apr 22, 2020 · 4 comments
Closed

Stored Cross Site Scripting vulnerability exists in post content. #1333

SecGus opened this issue Apr 22, 2020 · 4 comments

Comments

@SecGus
Copy link

SecGus commented Apr 22, 2020

Summary

A user is able to inject JavaScript into a post via the post creation feature.

Expected Behaviour

The CMS should HTML encode any inputted data so it is reflected back safely to the user.

Actual Behaviour

The CMS reflects back the post content without HTML encoding, meaning the client browser renders it as valid HTML / JS on the main page, and on that posts page. This can lead to malicious javascript being executed on anyone who visits the site's browser.

Context details (if applicable)

  • Anchor version: 0.12.7
  • Server setup: Ubuntu running apache2 and PHP 7.2
  • Reproduction:
  1. Login to admin panel.
  2. Create a blog post where the post title can be anything, and post content is an XSS payload, in my case, I used <script>alert(1);</script>.
  3. Go to the main page to trigger the payload, alternatively, go to the blog post created in the previous step, this too shall trigger the payload.
    Screenshot from 2020-04-22 20-05-33

As we can see in the blog post source, the title and category are both HTML encoded before being reflected back to the user, although, the post content is not, and our browser renders our JS as valid code.
Screenshot from 2020-04-22 20-07-05

@SecGus SecGus changed the title Stored Cross Site Scripting Exists in post content. Stored Cross Site Scripting vulnerability exists in post content. Apr 22, 2020
@daviddarnes
Copy link
Member

Duplicate of #1298

@daviddarnes daviddarnes marked this as a duplicate of #1298 Apr 23, 2020
@galaktipus
Copy link

Any relevant commit for the above issue?

@TheBrenny
Copy link
Member

@galaktipus There's no commit because it was deemed to not be an issue. In the thread it was discussed that AnchorCMS has this as a feature, and not as a vulnerability.

Further, in the contribution guidelines, we request that you search for your issue to see if it's already been reported before opening a new one. This has obviously not been done. :(

@SecGus
Copy link
Author

SecGus commented Apr 29, 2020

Apologies, this was my mistake, I did not realize it was a dupe until I had posted the issue. I do recommend blocking event handlers and script tags, to provide some sort of security, but still allowing HTML customizable content. Maybe add toggleable HTML entity encoding. Without this option, the XSS can be exploited for horizontal privilege escalation.

I understand this was added as a feature, but it can still be used maliciously to some extent, and it is worth thinking about how the end user interacts with your product. Of course it is completely your choice on how you move forward with this.

Thank you for your time, and sorry again for the duplicate issue :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants