Hello Folks,
There are some simple standard problems which crowd my brain 
- creating a session using a hidden field like cgi[‘sess_id’] instead
of a cookie … or first try the cookie and if it’s rejected, go
the other way
This should be easy to achieve. Either put automatically a hidden field
after each with the content that would be otherwise written into
the cookie. This is somewhat kludge, but in PHP it works very well. At
least ERuby should be able to do that.
Or override “cgi.form { … }” to “old_form { hidden { … } }”
The better way would be to give the programmer a chance to manage
the sess_id for himself … having an option not to store the sess_id
into a cookie and having an attribut like Session.sess_id
… but as far as I see, none of these ways are implemented. Why not?
- since session files are mostly readable by other scripts/users,
passwords shouldn’t be stored directly. So it should be stored
encrypted. This is especially useful if the CGI script doesn’t
contain any passwords (the ideal case ;-)) and uses the password
the user entered to authorize against LDAP, a database, or whatever.
The best way would be to created a random key and encrypt the entered
password with it. The one is stored in the session (at the server),
the other is stored in a cookie or a hidden field (at the client).
So the attacker must catch the session file and have access to the
browser of the user. And both, the session file and the cookie, are
removed after the session, so the attacker must catch these two
during the session. As long as HTTPS is used, and noone can be
at two places at the same time, this would be secure.
An even better way would be to automatically encrypt the whole
session, so that the sess_id consists of two parts: The id of
the session file (to find it), and the (initially) random key
used to encrypt/decrypt the session file. At least this could
be possible in a transparent way. A kind of
CGI::Session::EncryptedFileStore should be possible, isn’t it?
Probably CGI::Session::MemoryStore is already the solution of this
problem, but it’s only shortly mentioned in the Ruby Book. So
I don’t know …
Of course, using SuExec the session file would have another owner
etc., so then it would be secure, too. But secure sessions should
be possible without an extra user for each CGI script
So my thoughts about these issues. Does anyone know in what way
they are implemented or why they better shouldn’t?
Thanks,
···
–
Volker Grabsch
—<<(())>>—
\frac{\left|\vartheta_0\times{\ell,\kappa\in\Re}\right|}{\sqrt
[G]{-\Gamma(\alpha)\cdot\mathcal{B}^{\left[\oint!c_\hbar\right]}}}
