Good question. The official max length of a cookie is 4K, which should be policed for you by Apache, such that a cookie larger than this will not be accepted as a valid request (and so not passed to your Perl script).

In terms of a large (eg. 4K) fake session ID breaking anything, this sounds unlikely, since CGI::Session will try to match this against your existing server-side cookie store (may be files or database depending on your settings), and when it fails to find a match it will ignore it and generate a new session ID instead.

I don't believe that simply testing for the existence of a (non-existent) 4K filename/database key will do any harm in itself, unless anybody knows otherwise?

When a session expires (in other words it is no longer on the list of active sessions) I re-direct the user to a log-in page to renew his log-in.

And if you employ something like Apache::AuthChecker too many failed log-ins from the same IP-address will automatically block that IP-address for a given time.

Too much time, I guess, to feel that I can “trust” anything.

Time well spent. It's not just a good practice to Trust No One, it's a necessity.
I sometimes write:

use strict;
use warning;
#use mistrust qw(paranoia);
[download]

I use something like this in my code:

my $id = $cgi->param('user_id');
my $query = $dbh->prepare("SELECT columns FROM users WHERE id = ?");
$query->execute($id);
[download]

Since DBI handles the argument passing for me, the worst thing that can happen is that the type of the URL parameter doesn't match that of the column in the database, and the database handler dies with an error. (But since the user tried to subvert my page, I don't really care).

There is another problem though: You have to store the session. If your sessions live rather long, a malicious user agent could just request pages over and over again, and each time a new session is stored on disk.

The client simply discards the cookie, and your application will happily generate new cookies.

To ward against these kinds of attack you simply have to read your log files on a regular basis.

What oxone said: cookies can't be long enough to cause problems; a bad or random id will find nothing in your DB. You are in the right neighborhood for a real problem though. If you have a POST form -- GET, again, typically has limits configured in the webserver to the size it will accept -- someone could POST form fields with megabytes of data. In CGI.pm you can help prevent this kind of attack with $CGI::POST_MAX=1024 * 100;  # max 100K posts, you can check the request body length manually, and it can be set in most webservers' configs too. Then again, one could just write an LWP::Parallel::UserAgent script in about 10 lines that would work quite well as a DoS against just about any small site. That requires access based throttling, or denial, to combat.

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?

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}