I don't know much about web apps, so you tell me. Is there any way that input from a user via a web app will be used by <>, without the programmer explictly assigning it to @ARGV? Even then, shouldn't all cgi scripts have taint mode enabled?
If the programmer is going to ignore taint or detaint and then assign unvetted filenames from an unknown user into @ARGV, do you think that changing the magic open to use the 3-arg variant will stop them?
Aren't they just as likely to use the 2-arg open themselves, or a piped open, or IO::Pipe or $secretInfo = `cat $filename`;?
Also, don't most cgi scripts run under userids that have specifically restricted privileges, and rooted to heavily restricted portions of the server directory space specifically to prevent or severally restrict the possibility of this kind of damage?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
I don't know much about web apps, so you tell me. Is there any way that input from a user via a web app will be used by <>, without the programmer explictly assigning it to @ARGV?
Since no one else has, I'll tell you. Yes, there is. It's sort of a holdover from back when ISINDEX was actually common. When called with a query string not containing an equals sign ("=") the query string is supplied to the script via argv. If the query string contains one or more plus signs ("+") then the string is split on those and each fragment becomes a separate argument in argv.
For example... put this in a cgi script...
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print while (<>);
And then open http://yourhost/path/to/that/script.cgi?script.cgi+script.cgi
And you should see the source of the script printed twice.
Don't leave that on your server, of course.
-sauoq
"My two cents aren't worth a dime.";
| [reply]
[d/l]
[select] |
I'm not sure how @ARGV and <> came into the picture, but your points are well-made. I was just suggesting one possible way the three-arg open was superior to the two-arg version. And again, the example was a bit contrived. :)
| [reply]
[d/l]
[select] |
Sorry, the context switched between your original post in this subthread and my post to which you replied.
Bart's post, mentioned the refusal of p5p to modify the magical open (eg. <>, which automagically opens the filename(s) contained in @ARGV), from the 2-arg variant to the 3-arg variant. I was questioning whether there was any need or benefit in making that change, for the magical open, rather than for the general case.
I was agreeing with bart that for the OPs use, the 2-arg version is preferable, and suggesting that for similar reasons, the 2-arg open was also appropriate for the magical open.
For the general case, and especially for use where security concerns are relevant, the 3-arg open is safer, but it also loses some functionality with respect to the 2-arg variant. That functionality, used correctly in secure environments makes perl script more flexible for the users and saves the programmer time (and his company money), by providing a rich set of facilities that are not only tried and tested (proper code reuse), but that also work in concert with the languages built-in security features (taint) to protect against the common programmer errors.
If you remove that functionality, either physically, or through misguided mandates (like suggesting that all uses of the 2-arg open are prohibited), then you force every programmer that needs that functionality to re-create it. Most will not do anywhere near as good a job as the p5p guys, and if previously unknown vulnerabilities do come to light, they will not be fixed and maintained with the timeliness and diligence that the p5p guys have historicaly shown.
The chorus of "thou shalt not use the 2-arg open" levelled against the OP's use exactly mirrors the fears I expressed in the subthread at Re^2: RFC: Perl-Critic policy: ProhibitInlineSystemArgs, when the Perl::Critic module was originally announced.
I won't repeat my arguments, but laws are complex beasts. You start with the incontrovertible "Thou shalt not kill", and then have to make exceptions--like you're a soldier defending your country; or a mother defending her child; or a policeman defending the general public; or a security guard defending your employers property; or a pious person defending your religion--and you are very soon on the slippery slope.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
