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:
Login to admin panel.
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>.
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.
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.
The text was updated successfully, but these errors were encountered:
SecGus
changed the title
Stored Cross Site Scripting Exists in post content.
Stored Cross Site Scripting vulnerability exists in post content.
Apr 22, 2020
@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. :(
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
4 participants
You can’t perform that action at this time.
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.
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)
<script>alert(1);</script>.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.

The text was updated successfully, but these errors were encountered: