Details

      Description

      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; }

        Activity

        Hide
        Oleg Kalnichevski added a comment -

        Fixed in SVN trunk and 4.1.x branch.

        Oleg

        Show
        Oleg Kalnichevski added a comment - Fixed in SVN trunk and 4.1.x branch. Oleg
        Hide
        Oleg Kalnichevski added a comment -

        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

        Show
        Oleg Kalnichevski added a comment - 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
        Hide
        Ralf Pöhlmann added a comment -

        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.

        Show
        Ralf Pöhlmann added a comment - 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.
        Hide
        Oleg Kalnichevski added a comment -

        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

        Show
        Oleg Kalnichevski added a comment - 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
        Hide
        Ralf Pöhlmann added a comment -

        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); }

        }

        Show
        Ralf Pöhlmann added a comment - 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); } } —
        Hide
        Oleg Kalnichevski added a comment -

        > 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

        Show
        Oleg Kalnichevski added a comment - > 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

          People

          • Assignee:
            Unassigned
            Reporter:
            Ralf Pöhlmann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development