more stripping

[Sherm Pendley]

I should hope we've all tried it once
or twice, just to see what it's like..

I've done it in C. Doing CGI in C is what got me started with Perl, thinking
"There's GOT to be a better f**king way to do this..."

I've ever had (and they really weren't that great
of 'reasons') were times before CGI.pm was standard

My biggest beef with CGI.pm is that it isn't focused. It takes a "shotgun"
approach of providing everything that might be useful in the most common
case of input from and output to HTML forms. Thus, it includes a boatload
of HTML form-generation methods that have *nothing* to do with the Common
Gateway Interface.

As I understand it, those methods are autoloaded, so there's hardly any
penalty for them at run-time. My dislike of them is conceptual - a module
called "CGI.pm" should focus on CGI, while something that concerns itself
with a particular type of markup that can be generated and sent to a client
belongs in a separate module. And the HTML-related methods *do* clutter up
the documentation, even though they don't cause any performance penalty.

So, I prefer to use CGI::Lite when that's available.

sherm--

 

[Gunnar Hjalmarsson]

My biggest beef with CGI.pm is that it isn't focused. It takes a
"shotgun" approach of providing everything that might be useful in
the most common case of input from and output to HTML forms. Thus,
it includes a boatload of HTML form-generation methods that have
*nothing* to do with the Common Gateway Interface.

As I understand it, those methods are autoloaded, so there's hardly
any penalty for them at run-time.

Well, whatever is causing it, the penalty for using CGI.pm for parsing
a simple querystring is striking:

http://groups.google.se/[email protected]

That benchmark showed that CGI.pm causes 0.2 seconds additional time.
You may argue that it *typically* doesn't matter for plain CGI
scripts, but there may be cases when it does.

 

[Eric Schwartz]

They are. But once again a thread in this group has degenerated into
giving the impression that you are automatically protected from such
problems if you use CGI.pm, which AFAIK is not true. Such issues
reasonably need to be addressed irrespective of the method for parsing
CGI data.

CGI.pm handles clients POSTing more data than you're expecting (server
limits restrict GETs similarly), so that's one thing you're up on by
using it.

And yes, validating data has to happen anyway. But why make your
situation worse by inviting other bugs that have already been fixed in
the standard solution?

-=Eric

 

[Gunnar Hjalmarsson]

CGI.pm handles clients POSTing more data than you're expecting
(server limits restrict GETs similarly), so that's one thing you're
up on by using it.

Only if you tell it to do so by enabling one or two special variables.
And you must enable them in the right spot in your program, or else
they have no effect... In other words, also that problem needs to be
addressed by the programmer irrespective of whether you use CGI.pm or
not. Please do not contribute to giving some other impression!

But why make your situation worse by inviting other bugs that have
already been fixed in the standard solution?

I'm not advocating the use of buggy code. Actually, I'm using CGI.pm
in a few cases because I find it convenient. In particularly one case
I'm not using it for efficiency reasons (se my reply to Sherm's post
in this thread).

 

[Eric Schwartz]

Only if you tell it to do so by enabling one or two special variables.

Meaning that people who don't need the overhead don't have it, and
people who do can use it. I fail to see the problem. And it's only
one special variable, and it's clearly documented. I suppose you can
point to clear documentation telling hand-rollers how to do the same
safely?

And you must enable them in the right spot in your program, or else
they have no effect... In other words, also that problem needs to be
addressed by the programmer irrespective of whether you use CGI.pm or
not.

Addressed, yes-- no-one disputes that. The question is how to address
it. Doing everything yourself means that you have to understand the
CGI spec, decide that $ENV{CONTENT_LENGTH} is what you want, figure
out what units it's specified in, and so on. Using CGI.pm means you
read the docs, see $CGI:OST_MAX, set it, and you're done. I know
which approach I'd rather take.

Please do not contribute to giving some other impression!

I didn't, and please stop trying to imply I did.

I'm not advocating the use of buggy code.

I have yet to see handrolled CGI code posted here that did not contain
at least one bug fixed in CGI.pm. So by advocating rolling your own,
you are advocating buggy code.

Actually, I'm using CGI.pm in a few cases because I find it
convenient. In particularly one case I'm not using it for efficiency
reasons (se my reply to Sherm's post in this thread).

That's fine, too. Just don't expect anyone to care if you have
troubles with it.

-=Eric

 

[Gunnar Hjalmarsson]

Meaning that people who don't need the overhead don't have it, and
people who do can use it. I fail to see the problem.

In my comment, to which you initially responded, I emphasized that by
using CGI.pm you are not *automatically* protected from problems of
the kind Jamie mentioned. The problem here is that you for some reason
lost the context, and by doing so I still think that you - hopefully
unintentionally - contributed to giving the wrong impression about
what it is you actually gain by using CGI.pm.

I suppose you can point to clear documentation telling hand-rollers
how to do the same safely?

No. Did I claim that I can? Don't think so.

Addressed, yes-- no-one disputes that. The question is how to
address it. Doing everything yourself means that you have to
understand the CGI spec, decide that $ENV{CONTENT_LENGTH} is what
you want, figure out what units it's specified in, and so on.
Using CGI.pm means you read the docs, see $CGI:OST_MAX, set it,
and you're done.

Sure, doing it by help of CGI.pm is more convenient. In the same way
as making use of other Perl modules is typically more convenient than
reinventing various wheels. To me, CGI.pm is a toolkit with quite a
few things for dealing with CGI and forms. Tools that you are free to
use or refrain from using depending on the task and your personal
preferences as regards programming style.

That's fine, too. Just don't expect anyone to care if you have
troubles with it.

Why on earth do you sound as if you were personally insulted by my
choice in that case? Sorry, but I find that comment utterly childish.

 

[Eric Schwartz]

No. Did I claim that I can? Don't think so.

So you're encouraging people to try something that they're very likely
to get wrong, and that you don't know of any clear documentation
telling them how to do right. Um, okay.

Sure, doing it by help of CGI.pm is more convenient. In the same way
as making use of other Perl modules is typically more convenient than
reinventing various wheels. To me, CGI.pm is a toolkit with quite a
few things for dealing with CGI and forms. Tools that you are free to
use or refrain from using depending on the task and your personal
preferences as regards programming style.

I prefer to minimize the number of places where I have the opportunity
to write buggy code. Certainly, that qualifies as 'personal style',
but it's pretty widely shared among professional programmers.

No-one's saying you have to use CGI.pm, and I'm certainly not; I'm
just pointing out that every single piece of hand-rolled CGI parsing
code I've seen posted here has had at least one obvious bug that is
fixed in CGI.pm, and that I personally don't care to spend the time
reading the CGI spec to find the more subtle ones. Perhaps someone
here does care to, but I think you'll find such people very few and
far between.

Why on earth do you sound as if you were personally insulted by my
choice in that case?

Perhaps because you chose to read it that way? That wasn't the case.
I honestly don't care if you use CGI::Gunnar or even cgi-lib.pl in
your code.

Sorry, but I find that comment utterly childish.

That doesn't appear to be a particularly sincere apology, so I'll
discount it for now.

-=Eric

 

[Gunnar Hjalmarsson]

So you're encouraging people to try something that they're very
likely to get wrong, and that you don't know of any clear
documentation telling them how to do right. Um, okay.

I'm not encouraging anybody to do anything if they don't know what
they're doing. I agree that CGI.pm is the natural first choice for
parsing CGI data, and when newbies post their first attempts to CGI
scripts, I too advocate that they use CGI.pm.

Again, I posted in this thread because security aspects were mentioned
in such a way that you falsely could get the impression that using
CGI.pm automatically takes care of them. If those comments hadn't been
posted, I would have kept my mouth shut this time. ;-)

 

[Jürgen Exner]

I'm not asking for a comprehensive listing of security holes using
cgi, but rather inherent security holes because I am using *hand
rolled* cgi instead of the cgi module.

Why the heck are you stealth-CC'ing me? I replied to your email directly.

Now, Usenet ettiquette dictates that you post a summary of the replies you
got via email. I am waiting for this summary.

jue

 

[thumb.one_underscore.42]

My biggest beef with CGI.pm is that it isn't focused. It takes a "shotgun"
approach of providing everything that might be useful in the most common
case of input from and output to HTML forms. Thus, it includes a boatload
of HTML form-generation methods that have *nothing* to do with the Common
Gateway Interface.

That is/was my problem with CGI.pm as well. Far too many html-ish features,
while not bad should probably go to something like HTML or have something
like CGI::HTML inherit CGI for the folks who want it.

Having said that, I think it's absolutely wonderful that people have the
freedom to write CGI any darn way they feel like it.

As I understand it, those methods are autoloaded, so there's hardly any
penalty for them at run-time. My dislike of them is conceptual - a module
called "CGI.pm" should focus on CGI, while something that concerns itself
with a particular type of markup that can be generated and sent to a client
belongs in a separate module. And the HTML-related methods *do* clutter up
the documentation, even though they don't cause any performance penalty.

True, it's usually a conceptual thing with me too. I'm not slamming CGI.pm
for any reason, I've heard Lincoln Stein give presentations and I respect
him very much. The impression I got was that he wanted it to be the best
possible general-purpose module available for CGI work, at the time it was
written, CGI generally involved writing HTML code.

So, I prefer to use CGI::Lite when that's available.

I'm lazy. I either use CGI, or I roll my own.

Sometimes I think it'd be a "neat thing" if I could use 'event handlers' when
parsing CGI, especially when uploading files. (say you're uploading a huge tab
file, the event handlers could parse it while it's being uploaded and insert
it into a DBM or something, but ONLY for certain specific variables.)

Or, it'd be kind of cool to have your own CGI module that accepts weird
content-type's so that (for example) it could accept an XML-RPC type of
document and convert it into the familiar param(), or the other-way-round,
take urlencoded data and by way of naming conventions and such, convert it
into an XML-RPC style message.

I could probably think of many many more uses for doing it yourself, perhaps
the main reason is simply because you find it fun.

This whole thread really degrades into the 3 camps, those who like using
modules in their code, those who perfer to get their hands dirty, and those
who want to explore alternative ways.

As far as posting buggy code to this newsgroup, if I'm reading it, I'd rather
NOT look at all the checks for content-length and so forth unless it is the
heart of whatever problem there is. One might post a:

# .. check input for security problems ..

Just to make people aware that you're aware of it, but I'd perfer to cut out
all irrelevant code where possible to make it easier to focus in on a problem.
(this is my preference, I know others disagree, thats the cool thing about
freedom, we're allowed to do that. )

Jamie

 

[Michael Hill]

Again, I posted in this thread because security aspects were mentioned
in such a way that you falsely could get the impression that using
CGI.pm automatically takes care of them. If those comments hadn't been
posted, I would have kept my mouth shut this time. ;-)

And this was why I asked about security because it didn't seem correct.

 

[gnari]

[attribution to Gunnar lost]
Again, I posted in this thread because security aspects were mentioned
in such a way that you falsely could get the impression that using
CGI.pm automatically takes care of them. If those comments hadn't been
posted, I would have kept my mouth shut this time. ;-)

And this was why I asked about security because it didn't seem correct.

see what you have done, Gunnar ?
you have made support for hand-rolled cgi to a newbie that thinks that
POST will make his script more secure

gnari

 

[Joe Smith]

In general I don't see many *security problems* with rolling your own parsing.
(except maybe someone giving you bogus data or posting way more data
than they really ought to, or feeding you data that some how chokes up your
regex's into doing things it shouldn't.)

Where you may run into trouble is in how you use those parsed values, but
the exact same things can be said for CGI.pm, ...

Hand-rolled CGI code is typically looked over by only one set of eyes.
CGI.pm has been gone over with a fine toothed comb many times.

Bugs tend to get fixed quicker (and in a more robust manner) when
under public scrutiny, like CGI.pm is.
-Joe

 

[Gunnar Hjalmarsson]

[attribution to Gunnar lost]

Again, I posted in this thread because security aspects were
mentioned in such a way that you falsely could get the
impression that using CGI.pm automatically takes care of them.
If those comments hadn't been posted, I would have kept my
mouth shut this time. ;-)

And this was why I asked about security because it didn't seem
correct.

see what you have done, Gunnar ?
you have made support for hand-rolled cgi to a newbie that thinks
that POST will make his script more secure

*If* that is a result of this thread, those who

- claim security reasons for not "hand-rolling" and then refer
to Google when OP asks for examples, or

- exemplify with security issues that need to be addressed
irrespective of the method for data parsing

are responsible for that result.

Btw, you were referring to OP's reply to your example with eval()ing
CGI parameters, right? Well, that is undoubtedly an example of
insecure programming, and POSTing data does of course not offer any
protection against it. On the other hand, you can well write similar
stupid code when using CGI.pm:

no strict;
use CGI;
$q = new CGI;
$$_ = $q->param($_) for $q->param;

If you *really* want to fight stupid behaviour among the Perl users,
you'd better show them, in a manner you would expect among decently
educated people, that you respect their intelligence and trust their
judgement. Doing so is by far the best way to teach a responsible,
secure programming style.

As regards CGI.pm: There are good, valid reasons for using it, some of
which have (also) been mentioned in this thread. Those reasons are
applicable to quite a few modules, btw.

If you want to *convince* people about the advantages with using
modules in general and CGI.pm in particular, please stick to those
reasons.

 

[Joe Smith]

And how does the cgi.pm module help there?
If those params are unsafe the developer should be using 'post' instead
of a 'querystring'.

You missed the whole point of gnari's post.

Some hand-rolled code does something as stupid as
/(\w+)=([^&])/ && eval '$'.$1."=$2";
to set '$foo=1' and '$bar=x';

CGI.pm does the right thing by putting the parameters into
a hash. The unsafeness of the parameter names are not affected
in any why by using POST.
-Joe