XSS in adding JavaScript into the ‘Subnet Name’ field

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.

Apologies for letting this slip through the cracks for a month, I seem to have missed the initial notification for it. I'm hoping the Horizon security reviewers I've subscribed can pin down the version information from your report a bit more... there is no 3.10 tagged for the Horizon project (versioning skipped from 2015.1.4 in the Kilo release to 8.0.0 for the Liberty release). Neither can I find the fbfe127c87f2e860efa7806eb9f6d6847d56ba07 commit you referenced, nor am I sure why you included a link to an advisory we published in 2014.

Dorina Timbur also reported this more recently. Quoting from the duplicate bug:

"As part of a penetration test done by a third party on a customer environment, it was found that by adding JavaScript into the ‘Subnet Name’ field, the JavaScript would trigger when adding the network to an instance and then loading a network trunk. The user needs permissions to create a network and edit an instance for this to trigger. See attached screenshots for more details. This is susceptible to a Cross-Site Scripting (XSS) vulnerability."

The embargo for this bug has expired, so I'm making it public now in hopes of getting more visibility/progress from the community.

@James, Hi I and tatina from the horizon team tried to reproduce this bug on the master branch but not succeed. Could you add more info. about the steps how to reproduce it?

This report seems very similar to https://security.openstack.org/ossa/OSSA-2014-023.html (CVE-2014-3474), which was fixed in Horizon's Juno release (2014.2) and backported to Icehouse (in 2014.1.2), and Havana (in 2013.2.4). Without a clear statement of which version the reporter found this in and no reproduction steps provided, I'm going to assume this is a duplicate of bug 1322197 and mark it as such. We can split the bugs again if the reporter or someone else comes along with more actionable information.

Actually, when starting to mark this as a duplicate, I noticed that there was another report set as a duplicate of this one in Private Security state. Because it was set as a duplicate it didn't show up in our usual queries and so we missed switching it to Public Security when its embargo was set to expire in January.

Vishal: can you have a quick look at bug 1900872 and see if the screenshot examples there provide sufficient context to reproduce the behavior and/or identify potentially affected versions?