CODEWITHSUNDEEP
oauth
Moo
Moo

Reputation: 890

Modified OAuth tokens can still authenticate / authorize successfully

Using Owin and OAuth, I've noticed that if you modify the last character of a token you can still get authenticated / authorized successfully.

I'm using a C# WebAPI application, but I don't know if this applies to OAuth in general. This might be by design but it seems like strange behaviour to me so I'm curious to know why this happens.

To replicate this behaviour:

  1. In Visual Studio, create a new project and select 'ASP.NET Web Application' as the template.
  2. Choose the 'Web API' template, and choose 'Individual User Accounts' as the authentication type.
  3. Build the project.

  4. Using a REST client, POST to http://localhost:23220/api/account/register * with a Content-Type: application/json header and the following body:

    { "UserName": "test", "Password": "password", "ConfirmPassword": "password" }

  5. Using a REST client, POST to http://localhost:23220/token * with no headers and the following body:

    grant_type=password&username=test&password=password

  6. Using a REST client, GET http://localhost:23220/api/values * with a Authorization: Bearer xxx header, where xxx is the access token you generated in the previous request. This request should be authorized and you should get a 200 response.

  7. Make the same GET request again, but this time modify the last character of the Authorization header value by incrementing it by 1. So for example, if the last character is a, change it to b; if it's 1, change it to 2 etc. The request will still be successful.

* Change the port accordingly.

Upvotes: 1

Views: 200

Answers (1)

Dark Falcon
Dark Falcon

Reputation: 44181

AccessTokenFormat - The data format used to protect the information contained in the access token. If not provided by the application the default data protection provider depends on the host server. The SystemWeb host on IIS will use ASP.NET machine key data protection, and HttpListener and other self-hosted servers will use DPAPI data protection.

Since setting up the project this way will run under IIS Express, the token is protected with the MachineKey API. I was not able to find a description of the exact data format of the encrypted value, but from previous work in cryptography, I expect perhaps there is padding at the end. This padding would not be protected by the token's signature, but this doesn't matter as it is just stripped off and discarded. Note that the range of changes is limited, so I expect only the last few bits of the last byte can be modified.

Upvotes: 1

Related Questions