bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sergey Ponomarev
Subject: [bug #57686] Basic Auth: make auth-no-challenge mode by default
Date: Tue, 28 Jan 2020 12:32:31 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

URL:
  <https://savannah.gnu.org/bugs/?57686>

                 Summary: Basic Auth: make auth-no-challenge mode by default
                 Project: GNU Wget
            Submitted by: stokito
            Submitted on: 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: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: trunk
        Operating System: None
         Reproducibility: Every Time
           Fixed Release: None
         Planned Release: None
              Regression: None
           Work Required: None
          Patch Included: None

    _______________________________________________________

Details:

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.





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57686>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]