For one application, I observe multiple SMSESSIONs being set for the same resource. The web agent is on an Apache server. The application works as expected. Also, if I got to a URL on the same domain to view cookies I see only one SMSESSION cookie present.
This behavior has been flagged as a possible application vulnerability. I'm wondering if anyone else has observed this behavior. If so, any suggestions on how to change or explain this behavior?
To clarify, at no time does my browser session send more than one SMSESSION on a subsequent request. I'm simply trying to understand the 'why' this behavior can occur during a response for the same resource.
Cookie set has some specification as per following:
On top of cookie name:value pair, there are domain and path. This make it unique to the application that match to the domain.
set-cookie: SMSESSION=/7lKs69U8d/...TRIM...; path=/; domain=.test.lab
The response on set-cookie that you have, are they referring to same path and domain? Do you have cookie provider configured?
Header trace log (ie: captured with fiddler2 (www.fiddler2.com)) will give better information to troubleshoot the issue.
Thanks for your response. The agent in question is aware of a cookie provider. However, in the Fiddler trace where this happens I do not the cookie provider invoked. The path is "/" and the domain is the same.
Below is a copy of the Set-Cookie in the HTTP Response as seen by Fiddler. It shows two cookie SMSESSIONS set for the same resource -- but the path and domain are the same.
Set-Cookie: SMSESSION=zH4 ...TRIM; path=/; domain=.3m.com
Set-Cookie: SMSESSION=Wy0 ...TRIM; path=/; domain=.3m.com
Thanks for your update. What Patrick mentioned on SessionGracePeriod is something worth to check.
Beside, if you have other application that web agent didn't behave that way, you can compare the ACO parameters different between them. It might be one of the ACO parameter play a role.
A header trace logs and corresponding web agent logs are needed to understand better. I will suggest to open CA Support ticket if you didn't find hint from ACO parameter setting.
On one hand, as Kar Meng points out, you'll get several smsession cookies if the path and domain are different.But if path and domain are the same, the SMSESSION cookie value might be updated frequently leaving youthinking that it might create multiples.
You can control the update of the SMSESSION value by configuring
On the other hand, you'll see alson only 1 SMSESSION cookie sent on the request. The browser will selectthe one which as the domain corresponding to the requested fqdn.
More general details on smsession cookie :
Hope that helps,Patrick
Thanks everyone for the feedback! This community is amazing.
I believe I understand better why multiple Set-Cookies for the same CA SSO credential is occurring. A brief explanation is give below
This environment has web servers on a PCI External Network that act as a reverse proxy for web servers on our Internal PCI Network. All web servers involved have SiteMinder web agents installed and share the same SiteMinder policy.
Thus every external URL for this application will invoke two SiteMinder web agents before the app gets invoked. Each web agent will update its SMSESSION credential to reflect the last time it was used for idle timeouts. This results in the browser seeing multiple Set-Cookie calls for multiple SMSESSIONs.
The browser will process each SMSESSION separately. However, on subsequent requests, the browser will have only one SMSESSION and thus it sends only one SMSESSION. All is well.
Takeaway: This is expected behavior and is not a security risk it would seem.