XSS in network create error reporting

Bug #1417762 reported by Jason Hullinger
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
New
Medium
Unassigned
OpenStack Security Advisory
Won't Fix
Undecided
Unassigned

Bug Description

The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response:

Request

POST /project/networks/create HTTP/1.1
...

csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=<img src=zz onerror=alert(1)>&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes=

Response

HTTP/1.1 200 OK
Date: Tue, 03 Feb 2015 20:42:28 GMT
Server: Apache/2.4.10 (Debian)
Vary: Accept-Language,Cookie
X-Frame-Options: SAMEORIGIN
Content-Language: en
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/json
Content-Length: 209

{"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. <img src=zz onerror=alert(1)> is not one of the available choices."]}}, "workflow_slug": "create_network"}

In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output.

Tags: security
Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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.

Changed in ossa:
status: New → Incomplete
Grant Murphy (gmurphy)
description: updated
Revision history for this message
Thierry Carrez (ttx) wrote :

Adding horizon-coresec for debunking...

As the report stands, it hardly qualifies as XSS since the output is not HTML but JSON... I don't see why you would HTML-encode that output ? Or can you leverage the same bug on HTML output ?

Revision history for this message
Paul McMillan (paul-mcmillan) wrote :

If the output is rendered without escaping as innerhtml, it could certainly be an issue. I haven't had a chance to look at this issue in detail yet, but just because it's json doesn't mean it's not used inappropriately further down the line.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

It seems that the injected code is part of an error and it is not saved.
How an attacker would trick an user to insert such code...
@Paul any progress on that one ?

Revision history for this message
Paul McMillan (paul-mcmillan) wrote :

The attack is an example of reflected XSS. Assuming the original report is correct, this kind of thing allows an attacker to turn a CSRF vulnerability into an XSS vulnerability.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

So, if without a CSRF, this is not exploitable, then it's a Class D type of bug (https://wiki.openstack.org/wiki/Vulnerability_Management#Incident_report_taxonomy).

I propose to open this by next Monday if no one objects.

Revision history for this message
Matthias Runge (mrunge) wrote :

I'd say: open it up. It's not pretty and leaves room for improvement.

Revision history for this message
Paul McMillan (paul-mcmillan) wrote :

Opening it is fine. It needs to be fixed, but absent other vulnerabilities, this particular instance isn't very exploitable.

Revision history for this message
Jeremy Stanley (fungi) wrote :

Agreed on class D for this report, and since nobody has objected I've switched it to public, tagged as a security hardening opportunity and switched the advisory task to "won't fix."

information type: Private Security → Public
tags: added: security
Changed in ossa:
status: Incomplete → Won't Fix
Changed in horizon:
milestone: none → kilo-3
Thierry Carrez (ttx)
Changed in horizon:
milestone: kilo-3 → kilo-rc1
David Lyle (david-lyle)
Changed in horizon:
importance: Undecided → Medium
David Lyle (david-lyle)
Changed in horizon:
milestone: kilo-rc1 → liberty-1
tags: added: kilo-rc-potential
David Lyle (david-lyle)
tags: removed: kilo-rc-potential
Jeremy Stanley (fungi)
description: updated
Changed in horizon:
milestone: liberty-1 → liberty-2
Changed in horizon:
milestone: liberty-2 → liberty-3
Thierry Carrez (ttx)
Changed in horizon:
milestone: liberty-3 → liberty-rc1
David Lyle (david-lyle)
Changed in horizon:
milestone: liberty-rc1 → next
Adriano (dritec)
Changed in horizon:
assignee: nobody → Adriano (dritec)
Adriano (dritec)
Changed in horizon:
assignee: Adriano (dritec) → nobody
Revision history for this message
Trygve Vea (trygve-vea-gmail) wrote :

I _THINK_ the affected code was removed in this commit, http://git.openstack.org/cgit/openstack/horizon/commit/?id=8738c6db729e44313b90fa8e48758f284aea276a - but I'm not 100% sure.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

The example in the bug description is just an example. In my understanding, the point is if you specify an invalid choice which contains JS code for a choice field the specified value is returned as part of an error message.

I am not sure how it has a potential risk of XSS. The case here is if an API user sends a crafted string he receives the crafted string.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

The same thing was discussed above (around comment 5).

The message is generated by Django (not by horizon), so this bug should be forwarded to Django (if it still exists in the latest version of Django like 1.11).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.