Dolibarr: Security issue with REST API / Secrets args as URLs instead of headers

[ygini]

Bug

Looking at Dolibarr REST API explorer, the first line I see tell us how to get an authentication token with this URL: http://erp.corp.abelionni.com/api/index.php/login?login=ygi&password=yourpassword[&reset=1]

And all other API use a ?api_key=token args to provide the token.

This is a big mistake and security issue. Args of this kind should always be provided as HTTP header and not in URI. Most web server logs by default URI. That mean all setup in prod using this API has username and password written in clear text on the server.

Environment

• Version: 4.0.2

Expected and actual behavior

When URL are acceded by clients, all web server will log request with source IP, target web site and acceded URI.

For example, on a default Apache 2.4 setup on CentOS 7 with HTTPS I can see this line in the logs:
10.0.0.2 - - [15/Jan/2017:09:19:27 +0000] "GET /api/index.php/login?login=ygi&password=yourpassword HTTP/1.1" 403 594 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0.2 Safari/602.3.12"

Using an URL argument for an authentication system is a really weak system, this will lead to password leakage that can be really really bad for the end consumer.

And by the way, it will make more sense in term of REST API construction, authentication don't describe the requested resource, so it must be in header and not URI.

I know Dolibarr team don't care at all about security (otherwise #5950 would be taken more seriously). But this is serious, this software can't be taken as an acceptable ERP in SMB without a lot of improvement on this part.

[eldy]

You make a mistake when you say security is not taken seriously. It is our priority. That's why there is lower security report on Dolibarr than on other project with same size.
The bug you mention #5950 is fixed since now several month.
API rest with Dolibarr 5.0 also introduce the method POST for doing the authentication method. Also, note that goal of token is that you make REST call with the known token, the explorer is provided for development purpose and the method to get token too.
However, note that having authentication login/pass in header or in url can both be intercepted by a Man in the middle. You must use https if you really want to be secured (but best practice is to use the token directly instead)

[ygini]

HTTPS is encryption in transport.

Token and initial authentication for token obtention (nothing related to explorer here) passed in args are encrypted in transport but not on the server since it will be logged.

Providing such a weak authentication system is a proof that you've no idea about what security is.

The low level of security report just mean no one look at it AND/OR you don't care about it. Each time I look at your system I found one, and each time you prefer to ignore it.

@eldy, I don't know you but seriously, change the way you see security because, no, at this time you are far to be good at it. The main proof of this is your current API. There is no way you can be interested by security AND produce an auth API like this one.

[eldy]

Off course HTTPS is at a different OSI level. That does not change that using POST is not enough. HTTPS is required too.
If you want to help me to progress, can you, instead, provide me a proof concept on how to have the password into a log server with a default apache setup using the token when calling API ?
Same question using the POST method for authentication provided with v5 ?

[ygini]

In my original message you've a sample log grabbed after a API initial login.

The things is:

1. login/password auth is used to generate the token, not only for explorer demo, so it has to be secure
2. token can be stolen too, so must be secure too

Default Apache setup log full request, URI included, this mean anyone accessing the log can see the user password.

In business, logs are centralized and IT must not have access at any time to the end user password. Using Dolibarr API in current setup, IT will have access to clear text password just by looking at logs.

Regarding v5 authentication, it's not a matter of POST or GET. It's a matter of using builtin HTTP feature, like DIGEST or BASIC (if over HTTPS, for LDAP based users) authentication. This is the thing. Use HTTP authentication mechanism (with authentication as header field) will ensure that web server won't log it, and HTTPS will protect end user from MiTM.

For authentication token, it's the same, don't provide it as a request content but as an HTTP header (like X-Dolibarr-Token)

[ygini]

Tell me if you need additional details. I will be happy to share API design recommandation and tips to make this soft better (however, and I'm sorry for this, I've no time to spend as a dev).

Also, API URL should be set with API version in it. To allow rewrite of existing feature without breaking software compatibility.

For example, /api/v1/login?login=ygi&password=yourpassword can still exist along with /api/v2/login using HTTP based authentication. Keeping old software using the same API base URL and yet providing brand new API with new way to work.

[eldy]

We made 2 changes into 6.0:

• login to get token can be done using post (already available with 5.0). Setting the token from backoffice is still however recommended.
• token is set into the http header for any call by the api explorer (and api client can/must do so too).

[cperrot]

While this discussion is a bit older. I would suggest a logout function in Dolibarr 8 as to be able to invalidate the DOLAPIKEY token.

[eldy]

You must understand that the goal of token is to be able to use API with no need to login.
The login API must be used to get a token, then you should not more have to use the login API. If you do this, it means the caller of API store the login and pass, and this is a serious security problem.
By storing the token only, the user of API can only use API and never know the login/pass.
So there is not api to invalidate the DOLAPIKEY token. But you can invalidate it from the backoffice. Or using the API to renew the value to another value (login with the parameter renew set to 1).

Note: In v11, a restiction on ip is possible for APIs

An enhancement can be to be able to set a different restriction on ip for each account/token instead of a global restriction on ip for all APIs

[egils-consulting]

I agree. No cleartext passwords in URLs.
I can try making a pull request for a new page in settings where tokens can be generated similarly to github and gitlab.
Would that be accepted @eldy?

[eldy]

With recent version of Dolibarr, there is no clear password into url used for api call. Using api is done by using the token and this token is provided into http header.
1 old api (login in get) still exist to get the token for compatibilty purpose but there is no reason to use it.