[Owasp-testing] Testing for logout functionality (OTG-SESS-006)

Simon owasp at 31337.it
Mon Dec 14 15:48:07 UTC 2015


Hi Christer,

On 14.12.2015 16:20, Christer wrote:
> The things you’ve listed are all valid improvements on the threat
> vector(s). However, I would recommend to treat them as mitigations to
> reduce the risks and not as guarantees to remove the attack vector(s).

well, I don't really see it as an attack vector, if you are not able to
steal the cookie.
Like OTG-INFO-010, being able to map the application architecture is not
a bug. If I know you use rails that's not a problem in and for itself:
it becomes a problem if the version of rails you are running has bugs
that can be exploited.
I see OTG-SESS-006 the same: IF (and only if) I can steal your cookie,
you have a problem.

> Did you by any chance use something like OWASP Cornucopia to show the
> need for the safeguards you’ve listed?

No, I did not know about its existence until now. I'll have a look on it
later.

> I’ve worked on websites that persist the sessions in cookies, rather
> than server-side, and this should always be treated as something that
> comes with risks that need to be assessed and accepted/rejected. Attack
> vectors/vulnerabilities should be treated separately from the acceptance
> of the risks they entail. So, a company might assess the risks as
> “acceptable" and continue with solutions that don’t provide a
> “server-side session termination”. However, having it in the testing
> guidelines is valid since it requires the company to make a conscious
> decision about the risk rather than not know about the vulnerability.

I agree. I would word it like this in OTG-SESS-006 to make this clear.
Using cookies only for the session is not a vulnerability in itself. It
becomes a problem if an attacker is able to steal the session cookie
(and if that becomes the case, there will be a lot of other problems in
the app as well).


I propose the following addition:
"Some web application frameworks rely solely on the session cookie to
identify the logged-on user. The user's ID is embedded in the
(encrypted) cookie value. The application server does not do any
tracking on the server-side of the session. When logging out, the
session cookie is removed from the browser. However, since the
application does not do any tracking, it does not know whether a session
is logged out or not. So by reusing a session cookie it is possible to
gain access to the authenticated session. A well-known example of this
is the Forms Authentication functionality in ASP.NET."
---[snip snip]---
If this is the case, it becomes really important that the cookie is
protected against theft, and should therefore be
- transmitted over https only
- marked as httpOnly
- marked as secure
---[snip snip]---


I see the part about "Testing for server-side session termination" as
problematic too: "If the log out function causes session cookies to be
set to a new value, restore the old value of the session cookies and
reload a page from the authenticated area of the application."
How is an attacker supposed to know the "old values"? If that is the
case, he could have used them prior to the "real" user logging out
anyway, so it user is compromised in any case if an attacker knows the
value of the session cookie.

So the real vulnerability would be the disclosure of the session cookie
- not the use of a cookie session store.

I think this should be made clear.


Regards,
Simon



More information about the Owasp-testing mailing list