bbs problem

[Robin]

I do not see at the moment how you are protecting against the
possibility that someone might deliberately include html in their
posting. You seem to take in whatever the user sent, and output it
directly. So if someone puts in <blink>Hi, mom!</blink> then you'd
output exactly that and the browsers are going to react to it.
Even if it's javascript or if the user included </form> and
started a new <form> and so on.

: if ($FORM{'name'} && $FORM{'email'} && $FORM{'post'} && $FORM{'name1'} !~
:/\./ && $FORM{'name'} !~ /<.*>/ && $FORM{'email'} !~ /<.*>/ && $FORM{'post'}
:!~ /<.*>/ && $FORM{'name'} !~ /^\s*$/ && $FORM{'email'} !~ /^\s*$/ &&
:$FORM{'post'} !~ /^\s*$/)

I see there that you do match $FORM{'post'} against /<.*>/ but
that is not going to work if the string has embeded newlines.
You would need /<.*>/s for that case. (The s modifier is not
available in perl4 though.)

Thanks for this and thanks for the email, I'll actually get that code fixed
so its less of a security loop....

-Robin

 

[Joe Smith]

Bad idea.

Good idea.

How would I do this without using cgi?

Why would you want to avoid CGI.pm?

Oh, I see:
Post - Welcome to the Perl 4 Beginners BBS

The world does *NOT* need any more Perl 4 Beginners.

Perl 5 came out at the end of 1994. That's almost
ten years! Come on, Robin, get with the program!
Learn to use perl 5. Your life will be better for it.
-Joe

 

[Joe Smith]

Here's what it looks like now, why isn't it printing it to the files...?
use CGI qwstandard);
require ('lib.cgi');
&data_cgivars;

Your main problem is that you can't use CGI and 'lib.cgi' in the
same program. The CGI module does everything that lib.cgi used
to do, the function calls and variable names have changed.
-Joe

 

[Robin]

Bad idea.


Good idea.


Why would you want to avoid CGI.pm?

Oh, I see:
Post - Welcome to the Perl 4 Beginners BBS

It was supposed to say perl4beginners-I do use perl 5 if you really have to
know. I wanted to use my library because I still dunno how to work CGI.pm,
but I'm learning it.

The world does *NOT* need any more Perl 4 Beginners.

Perl 5 came out at the end of 1994. That's almost
ten years! Come on, Robin, get with the program!
Learn to use perl 5. Your life will be better for it.
-Joe

peace,
-Robin

 

[Robin]

Your main problem is that you can't use CGI and 'lib.cgi' in the
same program. The CGI module does everything that lib.cgi used
to do, the function calls and variable names have changed.
-Joe

huh, it seemed to work using both of them...
I guess I'll just use cgi for the beta...peace,
-Robin

 

[Uri Guttman]

R> It was supposed to say perl4beginners-I do use perl 5 if you really
R> have to know. I wanted to use my library because I still dunno how
R> to work CGI.pm, but I'm learning it.

that is pathetic. your lib is HARDER to use than cgi.pm. cgi.pm has to
be one of the easiest to use modules in existance given the complexity
of what goes on behind the curtain.

please take up some other hobby. programming is not for you. do you
realize how much you don't know and at the rate you seem to absorb stuff
you might be able to code on your own in 30 years.

uri

 

[Randal L. Schwartz]

Robin> It was supposed to say perl4beginners-I do use perl 5 if you
Robin> really have to know. I wanted to use my library because I still
Robin> dunno how to work CGI.pm, but I'm learning it.

Really? How tough is it to learn this:

use CGI qw(param);

my $name = param('name'); # get param field named 'name'
my @options = param('options'); # get multi-field (all values)

That's *it*. That's all you need to know about CGI.pm and you can
throw away *everything* you've seen from the Perl4 days. Really. You
can. You can do it. You don't have to use any of the other shortcut
things, or sticky fields, or anything else. Just please please please
use CGI.pm to read the params in a portable, safe fashion.

print "Just another Perl hacker,"

 

[Robin]

please take up some other hobby.

yeah well... maybe if you didn't post at all you'd be coding on your own...



-Robin

 

[Uri Guttman]

R> yeah well... maybe if you didn't post at all you'd be coding on your own...

i code plenty as it is. i also read and think plenty too. that is the
difference between my work and the scribbling you do. you have
reinvented many wheels and they come out very square.

uri

 

[Robin]

please take up some other hobby.

R> yeah well... maybe if you didn't post at all you'd be coding on your own...

i code plenty as it is. i also read and think plenty too. that is the
difference between my work and the scribbling you do. you have
reinvented many wheels and they come out very square.

uri

Yeah well, I read a lot of non-tech stuff and some tech, but probably not as
much as you...I think, else how would I write code at all even if I my code
sucks, don't mean to be overtly defensive... peace,
-Robin

 

[Joe Smith]

huh, it seemed to work using both of them...

You *CANNOT* use both and have competent programming.
There are many examples of incompetent programming that "appear"
to work, but are extremely flawed.

When you actually use CGI.pm, it means a lot more than simply
putting 'use CGI' in your program. It means using the methods
and functions that come with that module. In particular, it
means replacing home-grown routines that print "Content-type:"
with routines that provide a full and proper set of HTML headers.
If you were really using CGI, you would not have a call
to data_cgivars().

-Joe

 

[Gunnar Hjalmarsson]

When you actually use CGI.pm, it means a lot more than simply
putting 'use CGI' in your program. It means using the methods and
functions that come with that module.

It should be noted that very few people choose to use everything that
comes with the giant CGI module.

In particular, it means replacing home-grown routines that print
"Content-type:" with routines that provide a full and proper set of
HTML headers.

Well, CGI.pm abstracts quite a few trivial things without cause. It
may be a few more characters to type:

print "Content-type: text/html\n\n";

compared to:

print $query->header;

but printing the header directly has a pedagogic advantage, since you
learn what it looks like and are more likely to find out _why_ it's
printed. Prompting beginners not to do that is ill-advised IMO.

If you were really using CGI, you would not have a call to
data_cgivars().

Okay, on _that_ we can agree. ;-)

 

[Alan J. Flavell]

Well, CGI.pm abstracts quite a few trivial things without cause. It
may be a few more characters to type:

print "Content-type: text/html\n\n";

compared to:

print $query->header;

Except that the second one will (at least by default in recent CGI.pm
versions) follow the good practice recommended by security alert
CA-2000-02, irrespective of whether the script author is aware of this
recommendation or not.

but printing the header directly has a pedagogic advantage,

It can, indeed, but only if the candidate is willing to learn why
CGI.pm wants the header to be:

Content-Type: text/html; charset=ISO-8859-1

(or whatever other character coding is being used).

And then there's the consideration of what if an NPH script is
required? Here again, CGI.pm adapts calmly to the situation, whereas
the hand-knitter needs to explore a fresh area of the CGI spec.

since you learn what it looks like and are more likely to find out
_why_ it's printed. Prompting beginners not to do that is
ill-advised IMO.

Ideally, one would do both: learn what's happening under the covers,
_and_ use CGI.pm at the core of production CGI code.

 

[Gunnar Hjalmarsson]

Except that the second one will (at least by default in recent
CGI.pm versions) follow the good practice recommended by security
alert CA-2000-02, irrespective of whether the script author is
aware of this recommendation or not.

Okay, it was kind of embarrassing to miss the charset in that example. ;-)

But is there really security considerations behind CGI.pm's default
setting of a character set? Isn't the reason rather to simply increase
the chances that the script generates valid HTML/XHTML?

The document you refer to addresses security issues in connection with
generated web content. But by referring to it in connection with a
discussion whether it's advisable to use CGI.pm for generating HTTP
headers, I think you make the mistake to give the impression that
CGI.pm takes care of all sorts of security issues. Unfortunately, a
lot of comments in this group about CGI contribute erroneously to that
impression.

Security is a good reason to learn enough to understand what you are
doing when dealing with CGI, rather than a reason to apply CGI.pm's
high degree of abstraction.

Ideally, one would do both: learn what's happening under the
covers, _and_ use CGI.pm at the core of production CGI code.

Maybe.

 

[Alan J. Flavell]

But is there really security considerations behind CGI.pm's default
setting of a character set?

My recollection is that it was introduced in response to CA-2000-02,
although he doesn't say so in so many words in the change log.
However, Google will find some security-related discussions in Feb.
2000 about CGI.pm which followed from the alert (and the amended
Apache version).

IIRC it was introduced in CGI.pm 2.57 (deceased) and released in
CGI.pm 2.58 dated 23-Mar-2000.

CA-2000-02 is dated 2 Feb 2000. This is no mere co-incidence.

How many programmers fixed their hand-crafted scripts within that
space of time?

The document you refer to addresses security issues in connection with
generated web content.

It's a complex issue. I'm aware of other places where the use of
CGI.pm by default takes care of security-relevant mistakes which users
regularly make in hand-knitted code.

But by referring to it in connection with a
discussion whether it's advisable to use CGI.pm for generating HTTP
headers, I think you make the mistake to give the impression that
CGI.pm takes care of all sorts of security issues.

If that is so, then I would emphatically like to dispel that
impression. It does take care of some issues, but by no means does it
replace many other precautions that need to be taken for secure and
reliable scripts. Its author, after all, maintains a web security
FAQ, and that FAQ says much more than simply "use the module, Luke".
And rightly so.

 

[Gunnar Hjalmarsson]

[CGI.pm's] author, after all, maintains a web security FAQ, and
that FAQ says much more than simply "use the module, Luke".

Yes, it does. I just wish that also those, who frequently prompt
beginners to use CGI.pm, would say more.

 

[gnari]

[CGI.pm's] author, after all, maintains a web security FAQ, and
that FAQ says much more than simply "use the module, Luke".

Yes, it does. I just wish that also those, who frequently prompt
beginners to use CGI.pm, would say more.

beginners aready have enough to worry about.
as they advance in skills and knowledge, they can study
the modules they rely the most on, but mainly to be more
aware of what is going on. only when they have mastered
the art of reading the perldocs and faqs, should they go on
to learn to read the HTTP specs.

gnari