Token in URL is a security risk

How should we fix this? Should we hash the token so it goes encrypted over the wire? Should we re-design the validate-token? Would having the token as an http header in the call help?

The calls in question are described in the dev guide here:

http://docs.openstack.org/incubation/identity-dev-guide/content/Validate_Token-d1e1914.html

The use case here is to validate the token, so my suggestion is to replace the operation to validate a token from GET /tokens/<id> to POST /tokens/validate with a body that includes the token ID and tenant:

POST /tokens/validate
{
    "token": {
      "id": "asdasdasd-adsasdads-asdasdasd-adsadsasd",
     "tenantId": "1234"
}

That way the id will be encrypted for clients using SSL and not show up in the log.

I like this solution but would this be violating ReST principles in any way? POST should be used for creates, and validating a token doesn't really create anything.

Yes, my understanding is that it isn't as ReSTfully pure as the original solution...but security should trump restful purity, and my suggestion is the most straightforward way I could think of...not to say that there aren't other (better) solutions possible.

I agree with Robin's solution and logic:

The use case here is to validate the token, so my suggestion is to replace the operation to validate a token from GET /tokens/<id> to POST /tokens/validate with a body that includes the token ID and tenant:

POST /tokens/validate
{
    "token": {
      "id": "asdasdasd-adsasdads-asdasdasd-adsadsasd",
     "tenantId": "1234"
}

That way the id will be encrypted for clients using SSL and not show up in the log.

We should add this as an additional call and not break the old one until we have verified clients are not using it. It should also be documented as the recommended call and the old call should be clearly marked as an insecure call.

Elegant solution.Minor concern.Should validate be a query param instead of path param.
Should all resources not be a nown?

Also we have a shorthand HEAD call /tokens/{tokenId}. I dont thin HEAD call would take body.
How do we plan to support it?

The approach is a misuse of HTTPs uniform interface. If it's necessary for security reasons then so be it.

That said, I'm wondering if a better approach would be to simply encrypt the token in the URI for the purpose of logging. Or better yet (and I realize I'm setting the bar high here) encrypt and base64 the token before placing it in the URI. The caller's own token can be used as the shared secret for the encryption, since it will be encrypted anyway by the SSL.

We might use something like this: http://www.codekoala.com/blog/2009/aes-encryption-python-using-pycrypto/

That could be a good solution. It won't need an API change either. Thanks!

On 11/8/11 11:28 PM, "Jorge Williams" <email address hidden> wrote:

>
>The approach is a misuse of HTTPs uniform interface. If it's necessary
>for security reasons then so be it.
>
>That said, I'm wondering if a better approach would be to simply encrypt
>the token in the URI for the purpose of logging. Or better yet (and I
>realize I'm setting the bar high here) encrypt and base64 the token
>before placing it in the URI. The caller's own token can be used as the
>shared secret for the encryption, since it will be encrypted anyway by
>the SSL.
>
>We might use something like this:
>http://www.codekoala.com/blog/2009/aes-encryption-python-using-pycrypto/
>

Could we not have token as a header
/tokens GET and HEAD
X-VALIDATE-TOKEN - Token to be validated.
We then dont have to expect clients to do encryption and encoding.

I do like Jorge's approach for its consistency.However it adds more work on the clients part.

FWIW, we just added similar functionality in Glance because of security credentials in the Location field:

https://github.com/openstack/glance/commit/5e6fb33b22c868e8ce2638198c27f3e3a099318a

Might be something to look at :)

-jay

In this case I'd argue for simplicity and ease of use over HTTP/REST purity. We could probably "noun-ify" the validate call into something like POST /validation-request, but that doesn't seem to gain anything to me. Otherwise, if we use the scheme Jay points to, at least there's consistency between openstack projects.

Regardless of the option we chose I think we should stick to GET/HEAD to better support caching.

I'm going to build an extensions for this.
Middleware can query if the extension is there (OS-KSVALIDATE). If so, it can send an encrypted token as a header to tokens/validate.
I'll support everything under token/:id, including token/:id/endpoints (so that would be token/validate/endpoints)
I'll propose it and see where it goes from there.

Ziad was able to find a solution that preserves backwards compatibility.

Solution adds the following call in an extension:

GET v2.0/OS-KSVALIDATE/token/validate
     Passing in a header with X-Subject-Token (ex: T1000)
     Also passing in the X-Auth-Token (service token)

In the background this maps to v2.0/tokens/T1000

This has the benefit of not changing or breaking the core API. It's backwards compatible. In the middleware now, you can query the server to see if it supports the OS-KSVALIDATE extension and use this more secure call instead of the core call.

You can make this call with any of the token core APIs

Ex:
GET v2.0/OS-KSVALIDATE/token/endpoints maps to GET v2.0/tokens/{tokendID}/endpoints

Notes on the solution:

Maybe need option to disable core v2.0/tokens (503?)

Logging also needed with message to indicate to devops to use OS-KSVALIDATE extension call.

Documentation changes may also help make devops aware.

May also need VARY header (X-SUBJECT-TOKEN, X-AUTH-TOKEN)

For the check token call:
HEAD v2.0/tokens/(tokenid)?belongsTo=string (where string is the tenant in scope).

This is mapped to:
HEAD v2.0/OS-KSVALIDATE/token/validate

But if v2.0/tokens is disabled, it will return a 503 with no message-body in the response. The user will need to try a GET if they want more information or don't understand the 503 by itself.

Resetting the status of this bug because the above fix is not present in the new codebase (AFAIK).

thanks Dolph!

Cool, Joe just added the VMT. For some reason we couldn't access this bug (probably created before we set up the team)

@heckj: do you agree this is a known weakness of the current API that needs to be strengthened, rather than a directly-exploitable security vulnerability ? In which case we will open this bug publicly rather than continue to consider it under embargo.

@ttx - yes, weakness in the API setup. The V3 proposed API will resolve (I hope) this issue

(open the bug)

Opened.

So with v3 not going into folsom should someone attempt to triage this now while folsom is still in RC?

Matt,

This has been triaged - and the solution is a new/updated API sequence, so it's resolution is entirely dependent on the V3 API

Yeah that's my point. v3 isn't landing for folsom ( as I understand it ). So do we want to put in an alternative fix until it does land?

Matt -

what fix would you suggest that isn't changing the API?

Not sure atm. Trying to take a look now. Maybe we could do something to supress the value in logs / stacktraces. Sanitize at the very least.

More than happy to hear your suggestions, but the fundamental issue here is that the token is the URL, and its that passing through proxies, etc. that represents the disclosure of a potential security issue.

Obviously there's not much we can do about that without modifying the API.

This was addressed by revving the Identity API to v3 and implemented by gyee as part of bp stop-ids-in-uris

v3 spec: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md