Cannot create an OAuth token when using HTTP-basic

[pmartin]

Hi,

Issue details

I am trying to create an oauth token for the API. It doesn't seem possible when my wallabag instance is protected by HTTP-basic.

It works if I disable HTTP-basic, or if I unset the corresponding variables in app.php.

Environment

• wallabag version that exhibits the issue → 2.0.8
• How did you install wallabag? → git
• Last wallabag version that did not exhibit the issue (if applicable) → I discovered the issue with 2.0.6 but didn't try with previous versions
• php version → PHP 7.0.9-1~dotdeb+8.1 (nginx + php-fpm, http/2)
• OS → Linux debian 8.5
• type of hosting → dedicated
• which storage system you choose at install → MySQL

Steps to reproduce/test case

I'm trying to create an oauth token via the API, testing with curl in CLI (but I also had the problem with libcurl used from a C++ program).

The URL and the HTTP login/password and client_id/client_secret/username/password are all OK -- I just removed them to post this issue.

curl --user 'HTTP_USER:HTTP_PASSWORD' --data 'grant_type=password&client_id=MY_CLIENT_ID&client_secret=MY_CLIENT_SECRET&username=MY_USERNAME&password=MY_PASSWORD' https://MY_WALLABAG_URL/oauth/v2/token

I get the following response:

{"error":"invalid_client","error_description":"The client credentials are invalid"}

If I add the following line of code at the very top of web/app.php :

unset($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']);

=> The exact same curl command works and I get the oauth token:

{"access_token":"A VALID OAUTH TOKEN","expires_in":3600,"token_type":"bearer","scope":null,"refresh_token":"A VALID REFRESH TOKEN"}

It also works fine if I temporarily disable HTTP-basic on the server-side and do not send it in the request. But if I send the HTTP-basic identification infos in the request, event if it's disabled on the server-side, the application seems to use them and fail creating the token.

I'm guessing there might be some mixup somewhere between HTTP-basic info and login/password passed as GET parameter?
(sorry, I don't know symfony's security component to really help finding the culprit)

I also reproduced this behavior on the demo instance. Without specifying HTTP-basic login/password, I can create an oauth token :

$ curl --data 'grant_type=password&client_id=1_1bh4app65mv40csw4wg84og4wckkgwkogwkc0koocs4scgko48&client_secret=3pwsnib1kbmsoo8kkgosw8g088wscgwg0s8k0kg4gcwkck0wk8&username=wallabag&password=wallabag' http://v2.wallabag.org/oauth/v2/token

{"access_token":"YWFjZDQxMzE2YTU2ZDVlZjI3NzU2OWFlZTI0MzU4ZmRkZTI4NmNkMzNiOTlmYTkxZDk0NjRkYzU1ZjI2NTQ1Mg","expires_in":3600,"token_type":"bearer","scope":null,"refresh_token":"OWFhYjhlNjIzNmM0NjM4MDRhMzA5MzBlZDI2NmVlNjM1NzljMmU1ZjcyYmUxODNiNDZkNmU3NDU0OGIxOWFjNA"}

But if I add --user 'plop:glop' I get an error :

$ curl --user 'plop:glop' --data 'grant_type=password&client_id=1_1bh4app65mv40csw4wg84og4wckkgwkogwkc0koocs4scgko48&client_secret=3pwsnib1kbmsoo8kkgosw8g088wscgwg0s8k0kg4gcwkck0wk8&username=wallabag&password=wallabag' http://v2.wallabag.org/oauth/v2/token

{"error":"invalid_client","error_description":"The client credentials are invalid"}

I hope this helps :-)
Feel free to ping me if you need more information, of course!

Thanks!

[j0k3r]

As far as I understand, your wallabag instance is protected using a .htaccess with a login/password and you try to get a token from that instance by giving login/password (for the .htaccess to the request.

Right?

As far as I understand, the oAuth2 bundle we are using use the HTTP Basic information as client_id / secret.

The HTTP Basic Authentication is used to authenticate your client and is described by the RFC6749. (FriendsOfSymfony/FOSOAuthServerBundle#295)

Basically, if you want to use HTTP Basic, you should do:

curl --user '1_1bh4app65mv40csw4wg84og4wckkgwkogwkc0koocs4scgko48:3pwsnib1kbmsoo8kkgosw8g088wscgwg0s8k0kg4gcwkck0wk8' --data 'grant_type=password&username=wallabag&password=wallabag' http://v2.wallabag.org/oauth/v2/token

{"access_token":"OThjMmJkMmVjYzg2YzRkMDg0OTU0MDk2MWQ0MGM4OTdiYzJiMmQ0MjU1MzExNmNjYjUwOGI0ZjEwY2RmNDQ2Yw","expires_in":3600,"token_type":"bearer","scope":null,"refresh_token":"OWIxZTRlODczM2NiMjcyNGFlZDBiOTBmMTViNWI1ZmUzMTIzYjQxZmE5MjdiZjRkOTRjMzkzMDg2ZWI4YzdmNA"}

It seems to be just an other way to send client_id & secret.

[j0k3r]

As far as I understand, your wallabag instance is protected using a .htaccess with a login/password and you try to get a token from that instance by giving login/password (for the .htaccess to the request.

Right?

As far as I understand, the oAuth2 bundle we are using use the HTTP Basic information as client_id / secret.

The HTTP Basic Authentication is used to authenticate your client and is described by the RFC6749. (FriendsOfSymfony/FOSOAuthServerBundle#295)

Basically, if you want to use HTTP Basic, you should do:

curl --user '1_1bh4app65mv40csw4wg84og4wckkgwkogwkc0koocs4scgko48:3pwsnib1kbmsoo8kkgosw8g088wscgwg0s8k0kg4gcwkck0wk8' --data 'grant_type=password&username=wallabag&password=wallabag' http://v2.wallabag.org/oauth/v2/token

{"access_token":"OThjMmJkMmVjYzg2YzRkMDg0OTU0MDk2MWQ0MGM4OTdiYzJiMmQ0MjU1MzExNmNjYjUwOGI0ZjEwY2RmNDQ2Yw","expires_in":3600,"token_type":"bearer","scope":null,"refresh_token":"OWIxZTRlODczM2NiMjcyNGFlZDBiOTBmMTViNWI1ZmUzMTIzYjQxZmE5MjdiZjRkOTRjMzkzMDg2ZWI4YzdmNA"}

It seems to be just an other way to send client_id & secret.

[pmartin]

Hi,

Thanks for your help :-)

Actually, my wallabag instance is protected by a .htaccess (well, I'm using nginx, but same idea) with a login/password, yes -- but I'm not trying to use that login/password to get the oauth token.

The http-basic login/password is here as a first layer, in front of wallabag's own login/password -- it's a bit overkill considering the criticity of this kind of application, but, basically, the idea is to get 2 layers of security:

• one firt layer at the webserver level: the http-basic login/password
• and only if you pass this first layer, a second layer at the application level: wallabag's login/password or oauth mechanism.

Main goal: if there is a hole in either PHP or wallabag (or my install / config), it should not be exploitable without first breaking the http-basic login/password at the webserver level.

To setup this, I first installed wallabag, with its own login/password. And, then, put a .htaccess (again, nginx equivalent) in front of it, with another login/password.

the oAuth2 bundle we are using use the HTTP Basic information as client_id / secret.

Oh... That's probably what's causing my problem.

But if it's expected behavior, I'm OK to close this issue and I'll try to find another way -- I should be able to prevent nginx from passing the http-basic login/password to wallabag, with a bit of luck.

[pmartin]

Hi,

Thanks for your help :-)

Actually, my wallabag instance is protected by a .htaccess (well, I'm using nginx, but same idea) with a login/password, yes -- but I'm not trying to use that login/password to get the oauth token.

The http-basic login/password is here as a first layer, in front of wallabag's own login/password -- it's a bit overkill considering the criticity of this kind of application, but, basically, the idea is to get 2 layers of security:

• one firt layer at the webserver level: the http-basic login/password
• and only if you pass this first layer, a second layer at the application level: wallabag's login/password or oauth mechanism.

Main goal: if there is a hole in either PHP or wallabag (or my install / config), it should not be exploitable without first breaking the http-basic login/password at the webserver level.

To setup this, I first installed wallabag, with its own login/password. And, then, put a .htaccess (again, nginx equivalent) in front of it, with another login/password.

the oAuth2 bundle we are using use the HTTP Basic information as client_id / secret.

Oh... That's probably what's causing my problem.

But if it's expected behavior, I'm OK to close this issue and I'll try to find another way -- I should be able to prevent nginx from passing the http-basic login/password to wallabag, with a bit of luck.

[j0k3r]

Wow, really secure installation !
Yeap sadly I think it's the expected behavior of the bundle 😞

[j0k3r]

Wow, really secure installation !
Yeap sadly I think it's the expected behavior of the bundle 😞