[Cyberduck-trac] [Cyberduck] #9073: BasicAuth header being sent on first request

[Cyberduck]

#9073: BasicAuth header being sent on first request
----------------------------+----------------------
 Reporter:  rok             |         Owner:
     Type:  defect          |        Status:  new
 Priority:  normal          |     Milestone:
Component:  mountain duck   |       Version:  4.7.3
 Severity:  normal          |    Resolution:
 Keywords:                  |  Architecture:  Intel
 Platform:  Mac OS X 10.11  |
----------------------------+----------------------
Changes (by rok):

 * type:  enhancement => defect


Old description:

> In Mountain Duck the BasicAuth header is being sent on first try unlike
> on Cyberduck, where it tries to login anonymously. So if for an instance
> you decide to return 403 forbidden error on server in case a user tries
> to access WebDAV through HTTP it simply aborts the login process in
> Cyberduck and the user credentials are not being sent. However that is
> not the case with Mountain duck. I do notice that it warns the user about
> sending username and password in plain text, but there could be another
> layer of security that at first tries to connect to server over HTTP and
> if it gets Forbidden or some sort of an error that it displays it to the
> user, instead of blindly sending the BasicAuth credentials.

New description:

 In Mountain Duck (and Cyberduck) upon authentication if username and
 password is given before first request it will automatically try to send
 the Authorization BasicAuth header on first request. The problem is that
 if the protocol chosen is HTTP it will send the username and password
 unprotected on first try. There is no way to protect the user on server
 side to prevent user credentials from leaking. For example WebDAVFS -
 Native Mac OSX WebDAV client (and probably davfs) fix this by sending
 OPTIONS request first and then based on response adjust the settings or
 show a warning. If for example client gets 301 response to HTTPS, it
 changes the url to HTTPS and remembers it for next requests. On Cyberduck
 or Mountain duck this is not the case and every single request first gets
 sent over HTTP and later after 301 redirect to HTTPS it tries to send it
 over HTTPS.

 So what would needed to be done:
  - make Mountain duck and Cyberduck first try to send OPTIONS request and
 acknowledge if the response is 301 (redirect) to HTTPS
  - make sure to remember HTTPS or other address if 301 was given to that
 protocol for next requests
  - If 403 (forbidden) was return after first OPTIONS packet, meaning
 server doesn't allow HTTP connection it should maybe somehow warn the
 user, but most importantly not allow the client to send user credentials.

 Mainly it should be possible to protect user credentials by settings on
 server end side like forbidding access over HTTP or redirecting them to
 secure connection, without leaking the user credentials.

--

-- 
Ticket URL: <https://trac.cyberduck.io/ticket/9073#comment:1>
Cyberduck <https://cyberduck.io>
Libre FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows