|
Re: Security: Dancer Session cookie swap
by perlfan (Parson) on Jun 05, 2014 at 13:07 UTC
|
First make sure your sessions are persisting between reboot of the server. I'd recommend using MySQL. If your sessions are file based (and say, in /tmp), they could potentially get flushed out.
So the only way that the same sessions will be getting doled out is if your session data on the server is not persisting and if the session IDs don't have the proper entropy - i.e., if the sessions are sequential integers and reset each reboot, then you'd have the same kind of problems that you're seeing. | [reply] |
Re: Security: Dancer Session cookie swap
by Your Mother (Archbishop) on Jun 05, 2014 at 18:47 UTC
|
# cache session here instead of flushing/reading from cookie all the t
+ime
my $SESSION = undef;
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.
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. | [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
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] |
|
|
... 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] |
|
|
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 . . .
| |
Re: Security: Dancer Session cookie swap
by Anonymous Monk on Nov 12, 2014 at 15:32 UTC
|
| [reply] |
|
|
Oh wow, a bit more technical details and interesting claims I experienced this behavior with various session-engines (YAML, memcached and cookies). Please don't bother digging in Session::Cookie. ;)
And as mentioned somewhere above it can't be higher, I could isolate the problem to pure Dancer without any middleware.
But like always no code for anyone else to run and reproduce the problem ... the patch provided that purportedly works for the OP was ultimately rejected (nuking %ENV is drastic)
Its interesting the op tracked down a solution for him, but not a simple test case
| [reply] |
Re: Security: Dancer Session cookie swap
by Anonymous Monk on Jun 05, 2014 at 10:17 UTC
|
A website user will suddenly swap sessions to another user! :-( What does that mean (technical details)?
| [reply] |
Re: Security: Dancer Session cookie swap
by locked_user sundialsvc4 (Abbot) on Jun 06, 2014 at 07:15 UTC
|
Here’s what “the great big hole” in this logic is going to turn out to be: JSON-activity, spread out among a number of different servers in the usual manner, given this logic in the way that it is now constructed ... which stores the session information in the cookie.
The hole is probably one that occurs on is_forward, under load: the server that handles the forwarded request is not the same one that handled the previous one, and the start_request whatever-it-is did not go off. So, cached information is re-used, and sent to the client, where it cleanly replaces the previous state ... with someone else’s.
Fundamentally, the fly in this ointment is how-and-where the session state is stored. It appears that in this module the “secure” session storage object is only used as a magic encoder/decoder “wring” ... which is “wrong.” Under no circumstances may host-side state be stored on the client side, even if it is encrypted. There is both a stale-data problem here on the client-side, and a race-condition problem on the server side, as well as ample opportunities for impersonatiion and other exploits.
| |
|
|
wrong again, you can keep polishing sundialsvc4 but shut the front door,
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
| A reply falls below the community's threshold of quality. You may see it by logging in. |