bugGNU Wget - Bugs: bug #57686, Basic Auth: make auth-no-challenge...

 
 

bug #57686: Basic Auth: make auth-no-challenge mode by default

Submitter:  Sergey Ponomarev <stokito>
Submitted:  Tue 28 Jan 2020 05:32:29 PM UTC
   
 
Category:  Program Logic Severity:  3 - Normal
Priority:  5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  trunk Operating System:  None
Reproducibility:  Every Time Fixed Release:  None
Planned Release:  None Regression:  None
Work Required:  None Patch Included:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 29 Jan 2020 01:23:37 PM UTC, comment #1: 

Ok, I figured out that the main reason for the challenge was not a security but because we don't know which auth scheme uses server: basic or digest. So in the response for the first request server returns `WWW-Auth digest` then it will send password hash instead of clear password as for basic auth.

curl have an option -anyuth that works as wget by default.
So we can make `--auth-no-challenge` by default (i.e. send credentials without pre-request) and add the same `-anyauth` option as curl have for those who previous behavior.
I.e. make wget working the same as curl.

Sergey Ponomarev <stokito>
Tue 28 Jan 2020 05:32:29 PM UTC, original submission:  

I didn't find anywhere what was a motivation of developers to introduce the Basic Auth challenge mechanism was introduced except of that "it imitates the web browser experience". My only guess is that this is needed to allow to server to set some cookie but I'm pretty sure that that wasn't a real case.

I would like to ask you to reconsider this because in fact it makes almost no sense for security reason but create an additional network load instead and confusion for users who got an error.

The only documentation about that descibes the Auth challenge mode is:

> ‘--auth-no-challenge’
>  If this option is given, Wget will send Basic HTTP authentication information (plaintext username and password) for all requests, just like Wget 1.10.2 and prior did by default.
> Use of this option is not recommended, and is intended only to support some few obscure servers, which never send HTTP authentication challenges, but accept unsolicited auth info, say, in addition to form-based authentication.


So let's think about the attack vector and how the auth challenge flow protects us.
1. If the original sever stopped to ask for auth this may happens because of few reasons:
  * the API is not protected anymore and become public (low possibility). In this case it's ok show credentials because the just not needed anymore.
  * the API endpoint was moved somewhere else (version change) or it was removed at all. In this case it's also fine to send credentials but wget will receive 404 or 302 error.

In both cases an attacker can get an access to server's access logs and see the Authorization header with credentials but in any case if the  the original server was written correctly will not show the Authorization header in logs. But if the API is really requires credentials then the same situation.


2. If the original server gone (it's domain expired, service closed etc.) and now there is some another server with the same URL then there is two possibility:

  • The new server with the same URL belongs to an attacker: then it will just imitate the API and ask for the Basic Auth as previous service did and send WWW-Realm header. So the auth challenge won't help in this case.
  • The new service is non frauding then they just receive the Authorization header but they won't do anything with it.

In both cases credentials are leaked to someone else but anyway the original server is not exists anymore so there is not a big deal. Except of if your password is the same on other sites but here nobody can help you.

3. An attacker sitting on a wire (MITM). The HTTPS protects from this. But even for HTTP an attacker will see your credentials on successful API call. In case if the call wasn't successful this means that original server gone as I described in situation 2.

So, in fact the Auth challenge doesn't protect credentials in any case. Then why to do this?

The problem is that "some few obscure servers" are in fact not so few and one of them is for example GitHub OAuth server. I can't retrieve user info from GH OAuth because it doesn't sends the realm on first request.
So I lost some time of my life trying to figure out what was wrong. You may found in internet forums that there is a lot of people who faced the similar issue.
Another issue is that this violates Postel's law: "be conservative in what you do, be liberal in what you accept from others".
But what is even more important is that this creates an additional load to client, network and servers and gives absolutely nothing.
For example I wanted to call the GitHub's API from embedded device which is very slow and with limited resources and bad connectivity over wifi. And I was unpleasantly surprised that in fact all my API calls are made two times: one for the challtnge and another a real useful call.

Please disable the Auth challenge mode or even remove it from wget. I'm pretty sure that nobody will miss it.

Sergey Ponomarev <stokito>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by stokito (Submitted the item)
  •  

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code