Instead make it clear that what you mean is that the digest is kept at the webserver, and never sent. Of course leaving it static is also a bad idea, you should change it regularly. But what is important is that the CGI script can verify the hidden data, not that the user can.

Another thing that I am noticing. You may want to make some digressions into links, or produce an index at the top. Reading through your document is very different from referring back to it, and as it grows it could be hard for someone to track down interesting things you said.

--
$you = new YOU;
honk() if $you->love(perl)

How to call a .pl file in cgi. Is it possible or not? Note: I don't need to download the .pl.

Variables aren't tainted. Scalar values are tainted. Thus, portions of a hash can be tainted while other parts aren't. (Or an array.)

Once a variable is tainted, Perl won't allow you to use it in a system(), exec(),

Second nit, I haven't tested this but according to Perlsec, you can use the LIST form of system and exec and taint-checking is bypassed.

Good comments. On the sysopen() issue, I'd like to note that you can also just use something like:

    open( FILE, "< $filename\0" )
[download]

The leading mode ("<" in this case but can be many other modes like ">>" or "+<"), the separating space (between the mode and the file name), and the trailing null ("\0"), when all present together, prevent interpretation of the file name. So pipes ("|") or greater thans (">") in the $filename string won't cause Perl to spawn a subprocess or write to a file that you wanted to read from. This works even in Perl4.

Checking the documentation for this I find that modern versions of Perl also support:

    open( FILE, "<", $filename )
[download]

I find no reference to the old method that I described above. I suspect that this is because it has been removed from the documentation not because it has been removed from Perl (because the latter would be sad, replacing a solution that ports to old versions of Perl with one that doesn't). I'll have to do some checking and report back.

Using these can be more convenient than using sysopen() while still closing the same security holes.

        - tye (but my friends call me "Tye")