CODEWITHSUNDEEP
pythondjangooauth-2.0django-rest-frameworkdjango-oauth
Gal Silberman
Gal Silberman

Reputation: 3894

Extra protection layer for Django Rest Framework and OAuth2 Toolkit

This is a follow up question for this.

I'm using the latest Django OAuth2 Toolkit (0.10.0) with Python 2.7, Django 1.8 and Django REST framework 3.3

Some background:
When authenticating, the client receive a new AccessToken that he uses every time a makes a new request to the server. This AccessToken is owned by the client and being transferred using Authorization header upon request.

A simple test that I made was grabbing this access token from an authenticated client and send it in the Authorization header using a simple HTTP request from a different machine.
The result was that this new "client" is now authenticated just like the original client, and he can make requests as he pleased.

So the issue is:
The access token is not bind to any form of client validation (Like session id or client IP address). Any one that can get/find/steal/lookup the client's AccessToken, can be fake requests on behalf of this client.

I researched this issue allot but I couldn't find any one who addressed this matter. Maybe i'm doing something wrong in the from of authenticating the client? I would love some insights. Maybe its a simple configuration, out-of-the-box solution that I missed.

Thanks!

Upvotes: 3

Views: 541

Answers (1)

All Іѕ Vаиітy
All Іѕ Vаиітy

Reputation: 26452

This method of attack is called replay attack. This video by Professor Messer explains replay attack.

You can't really implement anything client side (browser) to overcome this because of the transparency of web browsers.

What you can do is to implement a digest authentication using a nonce.

In cryptography, a nonce is an arbitrary number that may only be used once.

a basic implementation looks like this.

enter image description here

  1. User requests API server.
  2. API server responds with a HTTP 401 and a nonce in a WWW-Authenticate header [you have to keep track of nonces] (a JWT with nonce which is set to expire in a small window, may be 2 seconds or less would be better and stateless).
  3. Client signs the request with received nonce, a client nonce and password and calls the resource again.
  4. API server validates the signature, If the signature is valid the request is accepted.
  5. Attacker captures the request and fakes the user.
  6. Since nonce is expired/'used only once' the attacker's request is rejected.

Upvotes: 1

Related Questions