Switching between a secured and unsecured client

Hi Bryan, 

It sounds good. Are you storing the session key in a browser cookie?   Have you taken a look at firesheep?  A collegue mentioned  I shoould  look it up not too long ago. It is a firefox add in for sniffing cookies.  

Are you passing the ip address when getting a session?

One thing I am doing with the site I am currently working on is making sure all the pages that are sensitive require SSL and cannot be accessed otherwise.

Jon  

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.

Hi Jon,

I store the Tess session key in the browser session (the ASP.NET session variable, in memory on the server).

Yes, I do pass the IP address (Request.UserHostAddress) to GetNewSessionKeyEx().  Does that serve any purpose aside from record-keeping?

My solution to require SSL is a user control that automatically redirects.  The code looks like:

if (!Request.IsSecureConnection)
{
    Response.Redirect(Request.Url.ToString()
        .Replace("http://", "https://"));
}

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.

Bryan,

Sounds good. I am using code similar to that for a couple forms I created on our main site to enforce ssl.  The current site I am working I am using MVC and I am using the built in filter attributes to handle the requiring SSL. 

In regards to the ip  address I as just thinking it is a good idea to have it.  I am not sure it is going to be anymore useful than a reference. 

I think this is a really good topic.

Jon

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!

Bryan

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.

Bryan