Hi Martin,

I agree this is one of the basic security problems and having just a cookie shouldn't be enough to access an account but as it stands it currently is.

Firstly I need to make a correction to my original post. CMSCookie looks like it was added by us in the webconfig in replace of the current cookie .ASPXFORMSAUTH which I just noticed this morning by looking through our version control (Judging by the commit it was to change the timeout but this is irrelevant) however this happens even with the default settings.

I created an example site using the kentico installer to test this, the website template I used was the community starter site Kentico 7.0 (I have also tested with some of our other sites at various hotfix's).

- Log into site as Administrator (I'm using chrome)
- Using chromes inspector tool go to Resources > Cookies > (domain name) and look for .ASPXFORMSAUTH cookie. Copy its Value
- Sign out of the administrator (at this stage I would expect the cookies value to become invalid, never again be able to be used)
- Close Chrome
- Open FireFox (with firebug installed) and navigate to the site home page
- Go to Firebug and Navigate to Cookies
- Create a cookie titled .ASPXFORMSAUTH with the value that we copied before. Make sure you tick Session and HTTP Only.
- Reload the page and you will see that you are logged in as that user

I come across this because a site we built had to go through a security assessment and this is what came back. (minus domain name and paths for our own security)

Authenticated Session Replay Vulnerability
Finding Details
The [sitename] utilises the “CMSCookie” (note we changed this back to the original cookie) value to track the identity of a user.

However, EWA testing showed that the Session ID was not properly invalidated at the server
side after the user logout of the application and can still be replayed to ‘resurrect’ the session
of a legitimate user and impersonate that user.

EWA verified the issue by capturing the Session ID of a user before logging out. After the user
logged out of the portal EWA manually inserted the captured Session ID into the browser
(session replay) and browse to a restricted page (e.g. [secure path]) to gain access as
the user that had logged out. The replay was successful and EWA was logged back into the
application as that user.

Impact Details
A successful attack will allow the attacker to have the same level of access privilege as the
captured user. If the captured user is an administrator the attacker will have the same
administrative access to the application.

It should also be noted that with the lack of a secure protocol (e.g. HTTPS) the risk of an
attacker capturing a Session ID is dramatically increased.

Recommendation
[site name] should ensure that after the user has logged out of the portal the
“CMSCookie” Session ID is not only cleared from the browser but is also invalidated on the
server as well.

After my own testing I was able to replicate this, even on the default install.