deprecate HttpSessionSecurityCookieFilter

[bradcupit]

See original discussion on the GWTP mailing list.

First a side note:
An XSS attack can run JavaScript and read cookies like the JSESSIONID. That means an attacker could hijack the user's session, so to prevent this it's good to mark the JSESSIONID as 'HttpOnly'.

GWTP has built-in protection against a different kind of attack, CSRF, via HttpSessionSecurityCookieFilter. In a CSRF attack the attacker can't see the client cookies. Unfortunately HttpSessionSecurityCookieFilter does it's magic by duplicating the JSESSIONID. So even if we mark the real JSESSIONID as HttpOnly to prevent session hijacking (see side note above), an XSS attacker can still see our JSESSIONID in the GWTP cookie, and still hijack our session. Unfortunately, we can't fix HttpSessionSecurityCookieFilter's cookie with 'HttpOnly' since GWTP client code needs to read it.

Instead we should use GWTP's RandomSecurityCookieFilter, which uses a random number rather than the JSESSIONID.

This ticket is to deprecate HttpSessionSecurityCookieFilter and document why.

Note: it's not a problem unless the app is already vulnerable to XSS, but using HttpSessionSecurityCookieFilter negates using the 'HttpOnly' preventative measure.