[Bug 3625] New: Wget does not %-decode authorization credentials

bugzilla at busybox.net bugzilla at busybox.net
Thu Apr 14 04:40:18 UTC 2011


https://bugs.busybox.net/show_bug.cgi?id=3625

           Summary: Wget does not %-decode authorization credentials
           Product: Busybox
           Version: 1.18.x
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: Networking
        AssignedTo: unassigned at busybox.net
        ReportedBy: kevin at kevinlocke.name
                CC: busybox-cvs at busybox.net
   Estimated Hours: 0.0


Wget currently takes the string between the // and @ of the URL and base64
encodes this into the Authorization header.  This behavior differs from GNU
wget and curl which both %-decode the username/password before sending.  The
observed behavior is as follows:

Running the following commands in series:
busybox wget http://test:my%20pass@example.com
wget --auth-no-challenge http://test:my%20pass@example.com
curl --basic http://test:my%20pass@example.com

Results in the following queries to the server:
GET / HTTP/1.1
Host: digitalenginesoftware.com:8088
User-Agent: Wget
Connection: close
Authorization: Basic dGVzdDpteSUyMHBhc3M=

GET / HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Authorization: Basic dGVzdDpteSBwYXNz
Host: digitalenginesoftware.com:8088
Connection: Keep-Alive

GET / HTTP/1.1
Authorization: Basic dGVzdDpteSBwYXNz
User-Agent: curl/7.21.4 (i486-pc-linux-gnu) libcurl/7.21.4 OpenSSL/0.9.8o
zlib/1.2.3.4 libidn/1.20 libssh2/1.2.6
Host: digitalenginesoftware.com:8088
Accept: */*

Note that "dGVzdDpteSBwYXNz" base64 decodes to "test:my pass" and
"dGVzdDpteSUyMHBhc3M=" base64 decodes to "test:my%20pass".

>From an appeal to standards, section 3.1 of RFC 1738 specifies that 'Within the
user and password field, any ":", "@", or "/" must be encoded.'  So any valid
URL passed to wget which contains these characters must be %-encoded.

>From an appeal to practicality, it's a inconvenient to detect whether the
utility being called is BusyBox wget from scripts before deciding whether to
escape these fields.  Parsing of URLs is also easier for the scripts if
reserved characters only appear in URL strings when acting as their reserved
meanings.

Thanks,
Kevin

P.S.  Apologies if this gets submitted multiple times.  I am receiving 500
errors during submit and my "My Bugs" list is still empty.

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the busybox-cvs mailing list