in reply to What if the bad-guys send nonsense as a session-id?

Let me try to explain myself a little better:   as a bad-guy I notice that you'll take CGISESSIONID (or whatever) and, without further checks as to its format, use it to query the session-database.

So what if I “inject” that?

What if, instead, I post an obfuscatory value there, in hopes of breaking your session-layer? (How about a CGISESSIONID that's 1,024 characters of garbage?) Perhaps I'll be rewarded with an error-message that will tell me more about what session layer you're using. Bad-guys can download code from CPAN and inspect it at their leisure, but I sometimes wonder how much we “inspect it” ... at all?

Replies are listed 'Best First'.
Re^2: What if the bad-guys send nonsense as a session-id?
by shmem (Chancellor) on Dec 16, 2007 at 17:22 UTC
    without further checks as to its format

    If I do that, I'm doomed, so I won't do that. There's taint mode, and untainting.

    Header checking, parameter validation and untainting has to happen (and in a reasonable setup happens) before any database query.

    So what if I “inject” that?

    You can do that only if I let you. My CGISESSIONID matches /^[0-9A-z]{32}$/; if what you are trying to inject doesn't conform to that, you're out. Matching a nonsensical cookie against that pattern won't execute anything.

    Then, for database queries, I use DBI and placeholders, so no SQL injection here either.

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}