Bogus vulnerability reported ("'banners' Persistent Cross Site Scripting")

Hello all,

A "vulnerability" has recently been circulating with this text:

Code

Steps To Reproduce :-  
  
1. Install the CMS from the download link & configure it.  
2. After configuration login with admin Credential .  
3. You will notice “Add banner” in the top of the browser.  
4. Click on it and Put XSS payload (any) in “Description” field.  
5. Save it & Click on Home.  
6. Every time any user visit the website , the XSS payload will trigger.

To be clear, this is not an actual vulnerability, for a number of reasons:
  1. The description field is escaped, JavaScript code will not execute
  2. If they meant instead the "Direct code" field, then yes, script could execute. That's the whole purpose of this field though, JavaScript-based ad serving code is industry standard and we need to have somewhere to input it.
  3. To use "Direct code" you need the "Place an HTML banner (dangerous!)" privilege, which by default is only given to staff. Obviously it's no vulnerability if you already need to be staff to execute it!
  4. Even if you had "Place an HTML banner (dangerous!)" privilege, you would also need "Avoid broad input filtering security layer" privilege, as otherwise the filtering layer (XSS filter) would also pick up on the JavaScript. This privilege is also by default only given to staff.

It's fairly common for bogus vulnerabilities to come up. If you see something circulating, please check on our site to see if we've covered or fixed it - and contact us via a private issue on the tracker if we have not.

Sometimes people come to us to report vulnerabilities, and they report them to the tracker without being logged in. Maybe they report it as a private issue, in which case they immediately lose access to their own issue (as there is no account for MantisBT to grant special access too). Or maybe they make it public, which is poor behavior for a reported of a security vulnerability – and we'd make it private ourselves quickly.
I don't believe this was reported at all though. Sometimes 'researchers' claim to report a vulnerability, but we've never heard of it by the time it is published.

We have documented procedures for dealing with security vulnerabilities which basically revolve around responsible and managed full disclosure.

If you appreciate what I do for the Composr project, I do accept contributions via Patreon. It's a lot of work just to maintain Composr, let alone develop new versions, and let alone respond to bogus issues like this. During the lifecycle of Composr v10 I've tried to improve our free support processes across the board so the project is well managed for all our users. So any contributions are appreciated as it helps facilitate me doing this.
Edited

← Previous Article

Updated minimum PHP requirement

Next Article →

Community Site Showcase