[
https://issues.apache.org/jira/browse/VFS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18063054#comment-18063054
]
Vlad Skarzhevskyy commented on VFS-861:
---------------------------------------
[~ggregory] the tests created.
- https://github.com/apache/commons-vfs/pull/753
Sorry I was not looking for propert solution today..
Other comments:
I appreciate the exising clean implementation of
UserAuthenticatorUtils.cleanup, as it effectively clears all credentials from
memory. Creating a clone of those credentials seems to defeat the purpose of
that security measure.
> Http5FileProvider Basic authentication fails:
> UserAuthenticationData.setData(Type, char[]) should clone its array input
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: VFS-861
> URL: https://issues.apache.org/jira/browse/VFS-861
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.10.0
> Reporter: Vaishnavi Kumbhar
> Assignee: Gary D. Gregory
> Priority: Major
> Fix For: 2.11.0
>
>
> h2. Title
> Http5FileProvider Basic authentication fails: password in credentials is
> wiped by UserAuthenticatorUtils.cleanup(authData)
> h2. Description
> We discovered authentication problem when migrating our application from
> deprecated Http4FileProvider to Http5FileProvider.
> *Our analysis of the problem:* In
> {{{}Http5FileProvider.createHttpClientContext(){}}}, the password is passed
> to {{UsernamePasswordCredentials}} as the *same {{char[]}}* reference
> returned from {{{}UserAuthenticatorUtils.getData(authData, PASSWORD,
> ...){}}}. In {{{}doCreateFileSystem(){}}},
> {{UserAuthenticatorUtils.cleanup(authData)}} is called in a {{finally}} block
> to clear sensitive data. That method zeros the character arrays inside
> {{{}authData{}}}. Because the credentials object holds a *reference* to the
> same array, the password in the credentials is also zeroed *before* any HTTP
> request is made. Http4 does not have this bug because it uses
> {{{}UserAuthenticatorUtils.toString(getData(...)){}}}, which creates a *new
> String* (a copy), so the credentials keep their own data.
> h2. Steps to reproduce
> # Clone the minimal reproduction project:
> ([https://github.com/VaishKumbhar/vfs2-issue])
> # Run: {{mvn test}}
> # Observe: test {{http4WithBasicAuthSucceeds}} passes; test
> {{http5WithBasicAuthFailsBecausePasswordWipedByCleanup}} fails with Http5
> does *not* return the protected content (auth failed).
> The project contains:
> * A minimal HTTP server with Basic auth (JDK {{{}HttpServer{}}}, no extra
> deps).
> * VFS2 {{FileSystemManager}} with either Http4 or Http5 provider.
> * {{FileSystemOptions}} with {{StaticUserAuthenticator}} (username/password).
> * Resolve a {{[http://]...}} URL and read content; with Http5 the password
> is already wiped so the request is sent without Authorization.
> h2. Expected behavior
> Http5FileProvider should authenticate successfully, same as Http4FileProvider.
> h2. Actual behavior
> Server returns 401.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
