0

I'm working on a REST API built with WCF WebApi Preview 6. This is for a multi-tenant application and consumed by different clients (web and mobile applications).

There are certain resources on this API that requires authentication in order to access them or operate with them. The information to the API for those endpoints is provided by the client by using a encrypted token, containing encrypted information about the device, user, tenant, etc.

I created a stress test which is actually revealing data leakage across tenants. I'm going to explain one concrete example and the workflow in place, so you have a better idea.

A user in client device authenticates with the API and get a token. Later on, the device POST a resource to an endpoint that requires the security token to operate. The token validation happens in a MessageHandler, which ensures everything is fine and then put transient information in HttpCurrent.Items so it is available to the rest of the request.

We use HttpContext.Current.Items because we were sure it is scoped to the request, so later on when processing the request I could refer to the right tenant and insert the information there.

We are not sure what is happening, but some data is routed to the wrong tenant based on the information in HttpContext.Current.Items.

How can this happen?

Is the information in HttpContext.Current.Items stepped on before the request finishes? Is the process that handles the data actually outside the request?

Raciel R.
  • 2,136
  • 20
  • 27
  • Is your MessageHandler running in the same thread as the request comes in on? – Martin Ernst Jun 15 '12 at 16:17
  • Martin, I'm not sure how the webapi handles this, but regardless HttpContext.Items is supposed to be maintained in the lifespan of a request. Right? – Raciel R. Jun 15 '12 at 17:52
  • How tests are performed? I remember bumping into issues when httpcontext is SET manually to different instances on the same thread. – Wiktor Zychla Jun 15 '12 at 19:55
  • The test is done by spawning threads per tenant/login as if they were in a real device. The test server is hit as it were handling any regular request. Reading on the WCF WebApi Codeplex site, it turns to be that ( _as Marting mentioned before_ ) the MessageHandler is not running on the same thread so whatever it is set in HttpContext.Current.Items can be stepped on a different thread. – Raciel R. Jun 15 '12 at 21:03
  • They recommend using request.Properties to pass information from the MessageHandler to the resource/controller. I'm struggling now on how to make the token available w/o having to get it and set HttpContext.Items on every resource operation. – Raciel R. Jun 15 '12 at 21:03
  • HttpContext.Current will be maintained for the thread processing the request (which could change if the request takes a while). If you use a different thread then HttpContext.Current could point to a different request's context. Given what you've described, I don't see the point of having the MessageHandler run on a different thread - your authentication is key to processing the request so you can't do anything in the request until the authentication has been done - what's the point of running it on a separate thread? Looks like a bad design to me. – Martin Ernst Jun 18 '12 at 09:13

0 Answers0