[
https://issues.apache.org/jira/browse/VFS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vaishnavi Kumbhar updated VFS-861:
----------------------------------
Description:
h2. Title
[|https://github.com/VaishKumbhar/vfs2-issue#title]
Http5FileProvider Basic authentication fails: password in credentials is wiped
by UserAuthenticatorUtils.cleanup(authData)
h2.
h2. Description
[|https://github.com/VaishKumbhar/vfs2-issue#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.
h2. Steps to reproduce
[|https://github.com/VaishKumbhar/vfs2-issue#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.
h2. Expected behavior
[|https://github.com/VaishKumbhar/vfs2-issue#expected-behavior]
Http5FileProvider should authenticate successfully, same as Http4FileProvider.
h2.
h2. Actual behavior
[|https://github.com/VaishKumbhar/vfs2-issue#actual-behavior]
Server returns 401.
was:
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. Reproduction project
[https://github.com/VaishKumbhar/vfs2-issue]
Clone and run {{mvn test}} to reproduce.
> Http5FileProvider Basic authentication fails: password in credentials is
> wiped by UserAuthenticatorUtils.cleanup(authData)
> --------------------------------------------------------------------------------------------------------------------------
>
> 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
> Priority: Major
>
> h2. Title
> [|https://github.com/VaishKumbhar/vfs2-issue#title]
> Http5FileProvider Basic authentication fails: password in credentials is
> wiped by UserAuthenticatorUtils.cleanup(authData)
> h2.
> h2. Description
> [|https://github.com/VaishKumbhar/vfs2-issue#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.
> h2. Steps to reproduce
> [|https://github.com/VaishKumbhar/vfs2-issue#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.
> h2. Expected behavior
> [|https://github.com/VaishKumbhar/vfs2-issue#expected-behavior]
> Http5FileProvider should authenticate successfully, same as Http4FileProvider.
> h2.
> h2. Actual behavior
> [|https://github.com/VaishKumbhar/vfs2-issue#actual-behavior]
> Server returns 401.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
