SP cookie bloat

Mon Oct 24 20:25:52 UTC 2022

On 10/24/2022 12:30 PM, Paul B. Henson wrote:

> So aside from the flooding issue due to the limit being hardwired to
> 20 (and as always, those scenarios mean you MUST use passive session
> protection and handle timeouts yourself), I don't see any obvious
> reason they would accumulate beyond that number, even if people abort
> logins.

The only scenario I see causing the limit to be exceeded is the multiple 
parallel requests I originally mentioned, as in that scenario the 
cleanup code will remove the same cookie(s) in all of the requests but 
add a new different one in each request.

It's easy to reproduce, assuming the below img src URL results in an 
authentication redirect:

<html><head></head><body>
<img src=https://sp-dev.pbhware.com/shibtest/1>
[...]
<img src=https://sp-dev.pbhware.com/shibtest/100>
</body>
</html>

loading that page results in queries being made with far more than 20 
cookies set.

If I understood you correctly, this is what you're calling flooding, and 
you don't consider this specific case an issue that could potentially be 
remediated by the SP but rather poor application session design and 
something that should be fixed on that side? I definitely wouldn't call 
it a bug, but tweaking the session cleanup to make it remove existing 
cookies randomly rather than deterministically such that multiple 
parallel requests would potentially remove different cookies would 
probably help. That is certainly a bit of a kludge and I could see why 
it might not be considered desirable.

Approaching from another avenue, given the cookie serves no purpose 
unless the blockUnsolicited policy is in use, which it is not by default 
(and evidently unlikely to be used in general), would it be possible to 
simply not set them unless they are needed? Ideally by tying their 
existence into the same configuration directive, or if that's not 
feasible by a separate directive?

-- 
Signet - The Art of Access
https://www.signet.id/