Hi ISAM Masters,

In order to have better control of the cookie and give the vulnerability scanner one less reason to complain, instead of ac.uuid, we are using WebSEAL Session Cookie as Attribute Collection Service session index as documented in the ISAM Mobile CookBook.

The assumption is the value of the WebSEAL Session Cookie doesn't change from user logon till logout. While recently I noticed this assumption doesn't hold true if there is a secondary OTP authentication by the authentication service. 

After the secondary OTP authentication, the session cookie value get changed by one letter as the example below

Before OTP:
1_TlyMhwpe3wTKPnXjh4BFEKWNjP+nCu9uY1HlVsuWBr2p1UafuMA=_AAAAAgA=_T4qG7O725VI7vN23SPj41mhuUKU=

After OTP:
1_TlyMhwpe3wTKPnXjh4BFEKWNjP+nCu9uY1HlVsuWBr2p1UafuMA=_AAAAAwA=_T4qG7O725VI7vN23SPj41mhuUKU=

My questions are:

1. Is there any settings in WebSEAL or AAC which can alter this behavior and make the session cookie constant throughout the session lifetime?
2. If we split the WebSEAL session cookie using `_`, what kind of information is stored in the last two parts? 
3. If the answer to the first question is NO, how can I make ac.uuid as a domain cookie instead of a host cookie, and make it to have the same lifetime as WebSEAL session cookie?

Thanks in advance!

Frank

Hi Frank,

Some thoughts about your post:

* The mobile cookbook you are referring to is the rather old (2014?) "ISAM Mobile Demonstration Cookbook" for which I only found a copy on my hard drive. The cookbook does indeed instruct you to change the default ac.uuid to PD_S_SESSION_ID. It's not clear to my why such change was needed/proposed.

* Now, this article from Shane Weeden explains that you better not use PD_S_SESSION_ID as the attribute collector session index since it's value changes when you transition from an unauthenticated to an authenticated state. So I wonder what's wrong with using the cookie generated by info.js itself? What do you mean with "better control"? and what vulnerability does the cookie introduce?

* With regard to (3): the ac.uuid cookie is created in the info.js script which comes with ISAM. So you can change the script to your liking (e.g set a specific expiration date, set a domain, etc). Take a look at the code and it'll be clear.


Kind regards, Peter.

------------------------------
Peter Volckaert
Sales Engineer
IBM Security
------------------------------

Thanks Peter for the response!

I read Shane's article and aware WebSEAL session cookie changes when transition from an unauthenticated to an authenticated state. While in my case, info.js is included after WebSEAL authentication. What changes the session cookie is the secondary OTP.

I have studied info.js and managed to set it to domain level using JavaScript, but info.js itself is not the only place set this cookie. As you can see in the next screenshot ACS backend server also set this cookie, WebSEAL rewrite the cookie name

Things goes while with these two ac.uuid cookies since they have the some value

when the user logout, WebSEAL tried to reset the ac.uuid cookie which was set by JavaScript code in info.js, but it doesn't know it is a domain cookie, so the reset doesn't work at all. Also WebSEAL just ignored the one set by ACS backend server.

neither of these two ac.uuid cookie get reset during logout, as you can see the next request still carry those two cookies after logout.

information stored in the last ACS session leaked into the next one when the user login again.

let me know if you have any idea to fix this.

Thanks again.

------------------------------
Frank Wang
------------------------------

Original Message:
Sent: 01-08-2019 03:28 AM
From: Peter Volckaert
Subject: WebSEAL Session Cookie as Attribute Collection Service Session Index

Hi Frank,

Some thoughts about your post:

* The mobile cookbook you are referring to is the rather old (2014?) "ISAM Mobile Demonstration Cookbook" for which I only found a copy on my hard drive. The cookbook does indeed instruct you to change the default ac.uuid to PD_S_SESSION_ID. It's not clear to my why such change was needed/proposed.

* Now, this article from Shane Weeden explains that you better not use PD_S_SESSION_ID as the attribute collector session index since it's value changes when you transition from an unauthenticated to an authenticated state. So I wonder what's wrong with using the cookie generated by info.js itself? What do you mean with "better control"? and what vulnerability does the cookie introduce?

* With regard to (3): the ac.uuid cookie is created in the info.js script which comes with ISAM. So you can change the script to your liking (e.g set a specific expiration date, set a domain, etc). Take a look at the code and it'll be clear.


Kind regards, Peter.

------------------------------
Peter Volckaert
Sales Engineer
IBM Security
------------------------------

Hi Frank,

* In your first screenshot I notice that the ac.uuid is not in the request. (Or may the screenshot is not showing the entire request?) While I would expect that the ac.uuid was set during the execution of the info.js in the browser, which happens before the call to /mga/sps/ac. In other words: can you please check if the info.js does set the ac.uuid and that it's a domain cookie? If so the call to /mga/sps/ac should contain an ac.uuid cookie and (may be - not sure) the back-end server would then not create the cookie itself.

* I don't think that pkmslogout removes the ac.uuid by default. You will most likely have to customize pkmslogout such that it deletes the cookie. This can be done by customizing logout.html: put Javascript in that page that deletes the cookie. Let me know if you need an example of that.

Kind regards, Peter.


------------------------------
Peter Volckaert
Sales Engineer
IBM Security
------------------------------

Original Message:
Sent: 01-09-2019 10:32 AM
From: Frank Wang
Subject: WebSEAL Session Cookie as Attribute Collection Service Session Index

Thanks Peter for the response!

I read Shane's article and aware WebSEAL session cookie changes when transition from an unauthenticated to an authenticated state. While in my case, info.js is included after WebSEAL authentication. What changes the session cookie is the secondary OTP.

I have studied info.js and managed to set it to domain level using JavaScript, but info.js itself is not the only place set this cookie. As you can see in the next screenshot ACS backend server also set this cookie, WebSEAL rewrite the cookie name

Things goes while with these two ac.uuid cookies since they have the some value

when the user logout, WebSEAL tried to reset the ac.uuid cookie which was set by JavaScript code in info.js, but it doesn't know it is a domain cookie, so the reset doesn't work at all. Also WebSEAL just ignored the one set by ACS backend server.

neither of these two ac.uuid cookie get reset during logout, as you can see the next request still carry those two cookies after logout.

information stored in the last ACS session leaked into the next one when the user login again.

let me know if you have any idea to fix this.

Thanks again.

------------------------------
Frank Wang
------------------------------


Original Message:
Sent: 01-08-2019 03:28 AM
From: Peter Volckaert
Subject: WebSEAL Session Cookie as Attribute Collection Service Session Index

Hi Frank,

Some thoughts about your post:

* The mobile cookbook you are referring to is the rather old (2014?) "ISAM Mobile Demonstration Cookbook" for which I only found a copy on my hard drive. The cookbook does indeed instruct you to change the default ac.uuid to PD_S_SESSION_ID. It's not clear to my why such change was needed/proposed.

* Now, this article from Shane Weeden explains that you better not use PD_S_SESSION_ID as the attribute collector session index since it's value changes when you transition from an unauthenticated to an authenticated state. So I wonder what's wrong with using the cookie generated by info.js itself? What do you mean with "better control"? and what vulnerability does the cookie introduce?

* With regard to (3): the ac.uuid cookie is created in the info.js script which comes with ISAM. So you can change the script to your liking (e.g set a specific expiration date, set a domain, etc). Take a look at the code and it'll be clear.


Kind regards, Peter.

------------------------------
Peter Volckaert
Sales Engineer
IBM Security