You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Ralf Pöhlmann (JIRA)" <ji...@apache.org> on 2012/04/23 22:10:33 UTC
[jira] [Created] (HTTPCLIENT-1186) NTLM authenticated connections
are mixed
Ralf Pöhlmann created HTTPCLIENT-1186:
-----------------------------------------
Summary: NTLM authenticated connections are mixed
Key: HTTPCLIENT-1186
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1186
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient
Affects Versions: 4.1.3
Reporter: Ralf Pöhlmann
Priority: Critical
Executing multiple request using the same http context as recommended mixes authenticated connections among different users.
If we execute two request usign the same context, the first request adds the user token to the http context as well as to the connection properties. The second request fins already a user token in the http context but if a new connection will be created (no free connection in the pool) this new connection is never assigned to an user token and is used independent of any user context!
see DefaultRequestDirector:
// See if we have a user token bound to the execution context
Object userToken = context.getAttribute(ClientContext.USER_TOKEN);
...
if (managedConn != null && userToken == null) {
userToken = userTokenHandler.getUserToken(context);
context.setAttribute(ClientContext.USER_TOKEN, userToken);
if (userToken != null) {
managedConn.setState(userToken);
}
}
and RouteSpecificPool:
public BasicPoolEntry allocEntry(final Object state) {
if (!freeEntries.isEmpty()) {
ListIterator<BasicPoolEntry> it = freeEntries.listIterator(freeEntries.size());
while (it.hasPrevious()) {
BasicPoolEntry entry = it.previous();
if (entry.getState() == null || LangUtils.equals(state, entry.getState())) {
it.remove();
return entry;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1186) NTLM authenticated connections
are mixed
Posted by "Ralf Pöhlmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260570#comment-13260570 ]
Ralf Pöhlmann commented on HTTPCLIENT-1186:
-------------------------------------------
It's hard to provide a test case, as this test case would require a NTLM-enabled server.
Unfortunately I fail to see where the state of the connection gets updated. The method ManagedClientConnection.setState() seems to be called by DefaultRequestDirector.execute() only. Looking at that method I fail to see where the connection gets updated other than within the code snippet I posted above. As this code does not check if the current connection already has a userToken, userTokens will not be set on new connections.
Could you please point me towards the code which updates the connection and is supposed to set the user token.
> NTLM authenticated connections are mixed
> ----------------------------------------
>
> Key: HTTPCLIENT-1186
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1186
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1.3
> Reporter: Ralf Pöhlmann
> Priority: Critical
> Labels: DefaultRequestDirector
>
> Executing multiple request using the same http context as recommended mixes authenticated connections among different users.
> If we execute two request usign the same context, the first request adds the user token to the http context as well as to the connection properties. The second request fins already a user token in the http context but if a new connection will be created (no free connection in the pool) this new connection is never assigned to an user token and is used independent of any user context!
> see DefaultRequestDirector:
> // See if we have a user token bound to the execution context
> Object userToken = context.getAttribute(ClientContext.USER_TOKEN);
> ...
> if (managedConn != null && userToken == null) {
> userToken = userTokenHandler.getUserToken(context);
> context.setAttribute(ClientContext.USER_TOKEN, userToken);
> if (userToken != null) {
> managedConn.setState(userToken);
> }
> }
> and RouteSpecificPool:
> public BasicPoolEntry allocEntry(final Object state) {
> if (!freeEntries.isEmpty()) {
> ListIterator<BasicPoolEntry> it = freeEntries.listIterator(freeEntries.size());
> while (it.hasPrevious()) {
> BasicPoolEntry entry = it.previous();
> if (entry.getState() == null || LangUtils.equals(state, entry.getState())) {
> it.remove();
> return entry;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1186) NTLM authenticated connections
are mixed
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260544#comment-13260544 ]
Oleg Kalnichevski commented on HTTPCLIENT-1186:
-----------------------------------------------
I am sorry but I still fail to see a security issue here. Before a connection gets released back to the manager (and therefore before it can be potentially leased to another user) its state will be updated. It really does not matter if a connection starts its life as stateless. What matters is whether or not it is stateful by the time it gets released back to the pool.
Could you please provide a test case that demonstrates how an authentication connection can be leased to a user with a different security context?
Oleg
> NTLM authenticated connections are mixed
> ----------------------------------------
>
> Key: HTTPCLIENT-1186
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1186
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1.3
> Reporter: Ralf Pöhlmann
> Priority: Critical
> Labels: DefaultRequestDirector
>
> Executing multiple request using the same http context as recommended mixes authenticated connections among different users.
> If we execute two request usign the same context, the first request adds the user token to the http context as well as to the connection properties. The second request fins already a user token in the http context but if a new connection will be created (no free connection in the pool) this new connection is never assigned to an user token and is used independent of any user context!
> see DefaultRequestDirector:
> // See if we have a user token bound to the execution context
> Object userToken = context.getAttribute(ClientContext.USER_TOKEN);
> ...
> if (managedConn != null && userToken == null) {
> userToken = userTokenHandler.getUserToken(context);
> context.setAttribute(ClientContext.USER_TOKEN, userToken);
> if (userToken != null) {
> managedConn.setState(userToken);
> }
> }
> and RouteSpecificPool:
> public BasicPoolEntry allocEntry(final Object state) {
> if (!freeEntries.isEmpty()) {
> ListIterator<BasicPoolEntry> it = freeEntries.listIterator(freeEntries.size());
> while (it.hasPrevious()) {
> BasicPoolEntry entry = it.previous();
> if (entry.getState() == null || LangUtils.equals(state, entry.getState())) {
> it.remove();
> return entry;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-1186) NTLM authenticated connections
are mixed
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-1186.
-------------------------------------------
Resolution: Fixed
Fixed in SVN trunk and 4.1.x branch.
Oleg
> NTLM authenticated connections are mixed
> ----------------------------------------
>
> Key: HTTPCLIENT-1186
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1186
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1.3
> Reporter: Ralf Pöhlmann
> Priority: Critical
> Labels: DefaultRequestDirector
> Fix For: 4.2 Beta2
>
>
> Executing multiple request using the same http context as recommended mixes authenticated connections among different users.
> If we execute two request usign the same context, the first request adds the user token to the http context as well as to the connection properties. The second request fins already a user token in the http context but if a new connection will be created (no free connection in the pool) this new connection is never assigned to an user token and is used independent of any user context!
> see DefaultRequestDirector:
> // See if we have a user token bound to the execution context
> Object userToken = context.getAttribute(ClientContext.USER_TOKEN);
> ...
> if (managedConn != null && userToken == null) {
> userToken = userTokenHandler.getUserToken(context);
> context.setAttribute(ClientContext.USER_TOKEN, userToken);
> if (userToken != null) {
> managedConn.setState(userToken);
> }
> }
> and RouteSpecificPool:
> public BasicPoolEntry allocEntry(final Object state) {
> if (!freeEntries.isEmpty()) {
> ListIterator<BasicPoolEntry> it = freeEntries.listIterator(freeEntries.size());
> while (it.hasPrevious()) {
> BasicPoolEntry entry = it.previous();
> if (entry.getState() == null || LangUtils.equals(state, entry.getState())) {
> it.remove();
> return entry;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1186) NTLM authenticated connections
are mixed
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260457#comment-13260457 ]
Oleg Kalnichevski commented on HTTPCLIENT-1186:
-----------------------------------------------
> If we execute two request usign the same context, the first request adds the user token to the http context as well as to the connection properties.
> The second request fins already a user token in the http context but if a new connection will be created (no free connection in the pool) this new connection
> is never assigned to an user token and is used independent of any user context!
Please help me understand the problem.
Newly created connections carry no state. They can become state-ful in the course of request execution. Therefore HttpClient updates the state attribute associated with the connection upon its _release_ back to the connection manager. What do you think is wrong with that?
Oleg
> NTLM authenticated connections are mixed
> ----------------------------------------
>
> Key: HTTPCLIENT-1186
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1186
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1.3
> Reporter: Ralf Pöhlmann
> Priority: Critical
> Labels: DefaultRequestDirector
>
> Executing multiple request using the same http context as recommended mixes authenticated connections among different users.
> If we execute two request usign the same context, the first request adds the user token to the http context as well as to the connection properties. The second request fins already a user token in the http context but if a new connection will be created (no free connection in the pool) this new connection is never assigned to an user token and is used independent of any user context!
> see DefaultRequestDirector:
> // See if we have a user token bound to the execution context
> Object userToken = context.getAttribute(ClientContext.USER_TOKEN);
> ...
> if (managedConn != null && userToken == null) {
> userToken = userTokenHandler.getUserToken(context);
> context.setAttribute(ClientContext.USER_TOKEN, userToken);
> if (userToken != null) {
> managedConn.setState(userToken);
> }
> }
> and RouteSpecificPool:
> public BasicPoolEntry allocEntry(final Object state) {
> if (!freeEntries.isEmpty()) {
> ListIterator<BasicPoolEntry> it = freeEntries.listIterator(freeEntries.size());
> while (it.hasPrevious()) {
> BasicPoolEntry entry = it.previous();
> if (entry.getState() == null || LangUtils.equals(state, entry.getState())) {
> it.remove();
> return entry;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1186) NTLM authenticated connections
are mixed
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCLIENT-1186:
------------------------------------------
Fix Version/s: 4.2 Beta2
My bad. I did miss the fact that when the user token is not null the state does not get updated, while newly created connections do not get the state attribute state updated when leased from the manager.
Oleg
> NTLM authenticated connections are mixed
> ----------------------------------------
>
> Key: HTTPCLIENT-1186
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1186
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1.3
> Reporter: Ralf Pöhlmann
> Priority: Critical
> Labels: DefaultRequestDirector
> Fix For: 4.2 Beta2
>
>
> Executing multiple request using the same http context as recommended mixes authenticated connections among different users.
> If we execute two request usign the same context, the first request adds the user token to the http context as well as to the connection properties. The second request fins already a user token in the http context but if a new connection will be created (no free connection in the pool) this new connection is never assigned to an user token and is used independent of any user context!
> see DefaultRequestDirector:
> // See if we have a user token bound to the execution context
> Object userToken = context.getAttribute(ClientContext.USER_TOKEN);
> ...
> if (managedConn != null && userToken == null) {
> userToken = userTokenHandler.getUserToken(context);
> context.setAttribute(ClientContext.USER_TOKEN, userToken);
> if (userToken != null) {
> managedConn.setState(userToken);
> }
> }
> and RouteSpecificPool:
> public BasicPoolEntry allocEntry(final Object state) {
> if (!freeEntries.isEmpty()) {
> ListIterator<BasicPoolEntry> it = freeEntries.listIterator(freeEntries.size());
> while (it.hasPrevious()) {
> BasicPoolEntry entry = it.previous();
> if (entry.getState() == null || LangUtils.equals(state, entry.getState())) {
> it.remove();
> return entry;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1186) NTLM authenticated connections
are mixed
Posted by "Ralf Pöhlmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260498#comment-13260498 ]
Ralf Pöhlmann commented on HTTPCLIENT-1186:
-------------------------------------------
Thanks for your quick response, I will try to elaborate on the problem.
The problem occurs when using NTLM authentication with multiple threads and a shared connection pool:
One thread sends a request and authenticates a connection from the connection pool. Then another thread (same user) makes a request and reuses the connection from the first thread. While the second thread is still working the first one tries to send another request. As the connection is still in use by the second thread, the first one will get a new connection from the pool. This newly created connection will get authenticated but the usertoken will not be set on that connection. As a consequence you have a connection in your pool which is authenticated but not marked with a user token. This is a potential security risk and also a problem if the connection is reused by a request from another user.
Have a look at the execute() method from the DefaultRequestDirector. In my opinion the userToken should be set whenever you have a managed connection as the connection pool might have returned a new connection for that usertoken:
Basically it should look like this:
----
if (managedConn != null) {
if (userToken == null) {
userToken = userTokenHandler.getUserToken(context);
context.setAttribute(ClientContext.USER_TOKEN, userToken);
}
if (userToken != null) {
managedConn.setState(userToken);
}
}
---
> NTLM authenticated connections are mixed
> ----------------------------------------
>
> Key: HTTPCLIENT-1186
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1186
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1.3
> Reporter: Ralf Pöhlmann
> Priority: Critical
> Labels: DefaultRequestDirector
>
> Executing multiple request using the same http context as recommended mixes authenticated connections among different users.
> If we execute two request usign the same context, the first request adds the user token to the http context as well as to the connection properties. The second request fins already a user token in the http context but if a new connection will be created (no free connection in the pool) this new connection is never assigned to an user token and is used independent of any user context!
> see DefaultRequestDirector:
> // See if we have a user token bound to the execution context
> Object userToken = context.getAttribute(ClientContext.USER_TOKEN);
> ...
> if (managedConn != null && userToken == null) {
> userToken = userTokenHandler.getUserToken(context);
> context.setAttribute(ClientContext.USER_TOKEN, userToken);
> if (userToken != null) {
> managedConn.setState(userToken);
> }
> }
> and RouteSpecificPool:
> public BasicPoolEntry allocEntry(final Object state) {
> if (!freeEntries.isEmpty()) {
> ListIterator<BasicPoolEntry> it = freeEntries.listIterator(freeEntries.size());
> while (it.hasPrevious()) {
> BasicPoolEntry entry = it.previous();
> if (entry.getState() == null || LangUtils.equals(state, entry.getState())) {
> it.remove();
> return entry;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org