To reduce the overhead of SSL connections between our website server and our Tessitura Web API server, I am considering using two web API clients: one that uses SSL (https) and one that is unsecured (http). I would use the secured client only for API calls that involve passwords and credit card information, and otherwise use the unsecured client. I believe that this method is sound, but I have a small concern: In the unsecured API calls, users' session keys would be exposed. However, our Tessitura Web API server only responds to calls from permitted website servers, so it seems that it would be impossible to hijack a Web API session. Does this seem correct?
That is a really interesting idea. Based on a recent experience fixing a vulnerability for PCI reasons, the risk that comes to mind is that of session hijacking. Which is a really deep subject so my response is not going to do it justice. But I can say this...
If you are storing the "tessitura session key" client side in a cookie that opens the possibility of session hijacking through the browser and exposing the tessitura session through a non ssl connection to the api would make that risk even more.
Supposing you've got "tessitura session key" server side and your using a really good authentication method for the website (ex. asp.net forms authentication or something else that uses a different ticket pre & post-login to prevent session hijacking), then you're mostly safe on the web server side. But you'd have to be pretty sure there are no vunerablities in how the API is secured.
As you know that key is the customers session information and will help someone get to account data if they are able to get hijack either the web or api server. Since good security happens in multiple flawed layers all working together to create a secure system, I would suggest avoiding that change unless it's going to significantly improve the response time that is worth adding additional risk.
Hello Mr. Najd,
Thanks! You've given me some important things to consider. As I just replied to Jon, the Tessitura session key is stored on the server. The web API only responds to requests from that server, so a stolen session key would only be useful to someone actually logged into that server.
I like your idea of "multiple flawed layers all working together," and I will likely heed your advice. At worst, I can use a non-SSL client for those few methods that don't require a session key.
Bryan
It's exciting to talk shop on TN.com, so huge thanks guys for letting me chime in. A suggestion for forcing ssl:
http://code.google.com/p/securityswitch/
...I have used this code for years and is a fantastic approach to forcing ssl. It also has code to suppress browser prompting when you switch from http to https. <- main reason I ended up using it. I highly recommend it, it's super easy to integrate with asp.net.
Don, thanks for sharing. I will be trying that out .
Jon
How do you folks handle the transfer of the session before and after login? We use the anonymous login and then transfer the session when someone logs in. OWASP recommends that you reset the session whenever switching from http to https. But if we do that the all the user information is lost once they log in.
Hi Gloria,
Why are you using TransferSession() in response to login events?
To the best of my knowledge, a new session is only required when the current session has expired tickets in the cart, or when it has checked out. TransferSession() allows you to preserve the old session's login and a few other details in these scenarios, so the same constituent can continue shopping without having to log in again.
On the other hand, TransferCart() ensures that the current session's cart actually belongs to the currently authenticated constituent. TransferCart() is useful for the scenario where your session has been previously authenticated as a designated "anonymous" constituent, and you are reauthenticating as a registered constituent.
On a slightly unrelated note, you can apparently revive the expired-cart session by removing all lineitems. The main obstacle to this is that once ticketed items in the cart have expired, built-in API methods like GetCart() throw exceptions, making it difficult to find the lineitem-sequence-numbers to remove.
Hope that helps!
Hi Bryan,
Using TransferCart requires you to create a new session doesn't it? So if they are logged in as anonymous, add to cart then login, doesn't it create a new session?
Gloria,
I don't believe that TransferCart() requires a new session. If it did, then how would it know which old session / constituent to transfer the cart from? I think it it operates on a single, re-authenticated session.