anchorcms/anchor-cms

Stored XSS in anchor-cms

security-breachlock opened this issue ยท 4 comments

Affected software: Anchor CMS 0.12.7

Type of vulnerability: XSS (Stored XSS)

Discovered by: Breachlock

Website: https://www.breachlock.com

Author: Balvinder Singh

Description: Anchor CMS is prone to a Persistent Cross-Site Scripting attack that allows a malicious user to inject HTML or scripts that can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site.

Vulnerable URL:
http://localhost/anchor-cms-0.12.7-bundled/anchor-cms-0.12.7/admin/posts/edit/1

Vulnerable parameter:
Description

Proof of concept:
Step1: Login into the anchor cms.

Step2:URL:http://localhost/anchor-cms-0.12.7-bundled/anchor-cms-0.12.7/admin/posts/edit/1
Go to the posts section and click on the description, and insert something with malicious javascript.

xss_1_desc_parameter_
Step3: Here the xss got executed.

xss_2_exected

This is not XXS. You have to have a login to post content on the page, and Anchor explicitly allows users to use HTML.

@security-provensec As @Bibliofile mentioned, this is indeed not an XSS vulnerability. AnchorCMS allows HTML in pages and posts by design. It is built as a simple CMS for designers and developers that might want to include scripts or stylesheets on individual pages, which is perfectly fine for us. We even advertise this fact right on the front page of anchorcms.com.
For projects that must cope with potentially malevolent input from their own users, another CMS might be a better fit.
I'd encourage you to take a deeper look into open source projects before reporting CVEs to avoid false positives and damaging your reputation.

Hi @Radiergummi,
Thanks for the reply, I would like to inform you that you have to put some sanitization on the input field so that the HTML characters are properly sanitized.

With Kind Regards
Security Breachlock

@security-provensec did you actually read @Radiergummi comment properly? Sanitisation is not necessary as the main content area intentionally accepts regular markup. Additionally, XXS attack would be somewhat redundant if the attacker already has access to the admin interface