Re: Security: Dancer Session cookie swap

# cache session here instead of flushing/reading from cookie all the t
+ime
my $SESSION = undef;
[download]

I don’t know the request cycle Dancer uses or the server you’re running on but I would guess if you have a persistent process, that up there is the problem. It’s not reset in init like their other two “cache” vars. Try adding this to lib/Dancer/Session/Cookie.pm and see if the problem rears its head again–


sub init {
    my ($self) = @_;
    $SESSION = undef; # <- new bit.
[download]

You should file a ticket against this issue if you really are seeing it and you should include this info or a link to the thread if it helps.

Comment on Re: Security: Dancer Session cookie swap Select or Download Code

Replies are listed 'Best First'.
Re^2: Security: Dancer Session cookie swap by Anonymous Monk on Jun 11, 2014 at 10:11 UTC
This isn't a problem https://metacpan.org/source/DAGOLDEN/Dancer-Session-Cookie-0.22/t/session-stealing.t	[reply]
Re^3: Security: Dancer Session cookie swap by Your Mother (Archbishop) on Jun 11, 2014 at 15:49 UTC
That test actually does do what I would expect to find the bug if it were there. So, nice find. The report here, however, is from rare cases of swapping so it might be a highly intermittent problem that's hard to trigger or requires a fatal at a different point in the request cycle or one related to a specific server implementation. I provided an example not too long ago of a naļve test that would appear to be right but miss intermittent bugs: Re: why Test::More?. That session stealing test ought to be run in parallel with 10 agents, stutter-timed, for hundreds of requests to feel "bomb-proof" to me because that's closer to what can happen in the wild. My point was it's not a good idea to have a persistent/cache without having it initialized in a known state at the top of all request cycles, as the other two persistent/cache $VARS wisely are.	[reply]
Re^2: Security: Dancer Session cookie swap by Anonymous Monk on Jun 06, 2014 at 00:16 UTC
... init ... Looks to me like that has very very low chance of making a difference, but its easy to test The op needs to provide more details	[reply]
Re^2: Security: Dancer Session cookie swap by locked_user sundialsvc4 (Abbot) on Jun 05, 2014 at 21:15 UTC
A very good guess, “Mom.” The handling of the `$SESSION` variable does look potentially-weak in connection to a persistent environment, but what really freaks me about this code is the specific content of the session-cookie variable. Although I see the presence of a “secure session-store,” I do not see it being used in the manner that I would expect. Instead, I see a cookie-value that is provided by the client-side being used, as-is on the server side. Yet, your post does bring up a very valid thought-point, which should now be considered carefully by the OP. This code as-written might “work” if ... but, maybe only if ... it is “properly” used. But, especially given the specfic way that the session-variable is used internally (`“cache session here instead of flushing/reading from cookie all the time ...”`), what if the OP’s code, by some circuitous obscure path, isn’t using it “quite properly?” This object as-designed would be particularly vulnerable to “impropriety,” and most-especially in any sort of persistent environment. Indeed, it would be entirely sufficient to explain the Bug, if two successive requests were dispatched to the same persistent (mod_perl or FastCGI) worker-bee in succession ... yes, there could well be a hole precisely-there . . .