auth_token does not quote token to validate

Bug #974319 reported by Chmouel Boudjnah on 2012-04-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Dolph Mathews

Bug Description

When we are sending a bogus token with a space to validate like :

"foo bar"

I am getting this error message :

  File "/opt/stack/swift/swift/common/middleware/", line 47, in __call__
    return, my_start_response)
  File "/opt/stack/swift/swift/common/middleware/", line 38, in __call__
    return, start_response)
  File "/opt/stack/swift/swift/common/middleware/", line 47, in __call__
    return, start_response)
  File "/opt/stack/swift/swift/common/middleware/", line 460, in __call__
    return, start_response)
  File "/opt/stack/keystone/keystone/middleware/", line 126, in __call__
    return, start_response)
  File "/opt/stack/keystone/keystone/middleware/", line 174, in __call__
    user_headers = self._build_user_headers(token_info)
  File "/opt/stack/keystone/keystone/middleware/", line 397, in _build_user_headers
    user = token_info['access']['user']
KeyError: 'access' (txn: txfa72e0ad18394a60bcb2fd00a100e7bb)

Reason seems to be because on the token sent to keystone to validate is unquoted and sent as is which come back as a 200.

I am not entirely sure if this is httplib or keystone coming back as 200 here is a snippet describing what i mean :

See the second test (unquote with a space) will return as 200.

Fixing the problem by quoting token before validating in keystone is trivial to fix the problem but I wonder if there is more to that.

Changed in keystone:
assignee: nobody → Chmouel Boudjnah (chmouel)

Fix proposed to branch: master

Changed in keystone:
status: New → In Progress
tags: added: essex-backport-potential

i don't fully understand what is going on in the pastie.

it appears in the first test you are sending a valid string but in the second you are sending an invalid one, yet you are claiming that the first one is invalid? or just that the second call should not return a 200?

Dolph Mathews (dolph) on 2012-05-10
summary: - auh_token does not quote token to validate
+ auth_token does not quote token to validate
Alan Pevec (apevec) on 2012-06-04
tags: added: essex-backport
removed: essex-backport-potential
Joseph Heck (heckj) on 2012-06-07
Changed in keystone:
importance: Undecided → Medium
Chmouel Boudjnah (chmouel) wrote :

It took me a while to track down this and I am not sure I still fully understand this.

So what happen when the client does this kind of request :

GET /v2.0/tokens/foo bar HTTP/1.1
Host: localhost:35357
Accept-Encoding: identity
X-Auth-Token: ADMIN

We are getting a HTML Error message :

But for a good query we are getting :

Note that this one is not a HTML error but a standard error.

So when using httplib read that via the function read_status :

at line 11 it tries to do some splitting of the first line to get the http error, still cannot do it on line 14 but cannot do it since we HTTPBaseServer come back with an HTML <head> as the first line, so it goes on until line 27 :

return "HTTP/0.9", 200, ""

and return a 200 error.

It all come down to BaseHttpServer DEFAULT_ERROR_MESSAGE :

# Default error message template
<title>Error response</title>
<h1>Error response</h1>
<p>Error code %(code)d.
<p>Message: %(message)s.
<p>Error code explanation: %(code)s = %(explain)s.

which I think should be non html and the %(message)s is XSS vulnerable as well (i.e:

so well HTTPBaseServer is buggy and httplib should detect that..

We could maybe try with another library than httplib to validate the token in

Let me know what do you guys think.

Chmouel Boudjnah (chmouel) wrote :

Oops first pastie should be :

Chmouel Boudjnah (chmouel) wrote :

Okay according to termie in this review:

this is going to be a wontfix :

probably not worth the trouble of breaking some random old client out there for what is essentially a non-useful fix: httplib's client misinterprets the status after it sends a horrifically deformed request and the server interprets it as http/0.9
i say we tell people who are sending horrifically deformed requests that they are wrong and should be quiet

so somebody with the right rights can please close this bug as WONTFIX.

Changed in keystone:
assignee: Chmouel Boudjnah (chmouel) → nobody
Mark McLoughlin (markmc) wrote :

Marked Won't Fix as requested by Chmouel

Changed in keystone:
status: In Progress → Won't Fix
Alan Pevec (apevec) on 2012-12-13
tags: removed: essex-backport
Changed in python-keystoneclient:
assignee: nobody → Dolph Mathews (dolph)
status: New → In Progress

Submitter: Jenkins
Branch: master

commit 308a773283a1eece37cb46446ca61a773cc12f42
Author: Dolph Mathews <email address hidden>
Date: Thu Dec 13 12:31:06 2012 -0600

    URL-encode user-supplied tokens (bug 974319)

    Change-Id: I7440f879edb8d61ea2382d5d4a56e32eacce4cfd

Changed in python-keystoneclient:
status: In Progress → Fix Committed
Dolph Mathews (dolph) on 2013-05-29
Changed in python-keystoneclient:
milestone: none → 0.2.1
status: Fix Committed → Fix Released
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers