New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot create an OAuth token when using HTTP-basic #2278

Closed
pmartin opened this Issue Sep 9, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@pmartin
Contributor

pmartin commented Sep 9, 2016

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!

@nicosomb nicosomb added the Bug label Sep 10, 2016

@j0k3r

This comment has been minimized.

Show comment
Hide comment
@j0k3r

j0k3r Oct 2, 2016

Member

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.

Member

j0k3r commented Oct 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pmartin

pmartin Oct 3, 2016

Contributor

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.

Contributor

pmartin commented Oct 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@j0k3r

j0k3r Oct 3, 2016

Member

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

Member

j0k3r commented Oct 3, 2016

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

@j0k3r j0k3r closed this Oct 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment