----- Mensaje Original ----- Fecha: 08/Ene/2004 07:52:44 PM De: [EMAIL PROTECTED] Para: [EMAIL PROTECTED] Asunto: Re: Perl 5.8 IIS 5.0 hangs on script failure
>[EMAIL PROTECTED] wrote: > >> Yes, I understood that in the very first email you adviced me to use eval. In >fact, I replied to you saying that the script printed the error and PerlIS did >not hang. But... what if I have dozens of scripts I have coded in years and all >of them use one or more lines of ''require''? do I have to recode all of those scripts >that worked just fine on every earlier version of Perl just because of this bug >? Well, Im not sure if this is a bug, but it is very annoying. :) >> >> To put this more visible. Some of my scripts call external files depending on >query string. >> For example, if you type http://myhost/script.pl?page=start >> then start.ext is required from scripts.pl using: >> >> $page=param('page'); >> require $page; >> >> So if some visitor, just for curiosity or for fun, types http://myhost/script. >pl?page=kakahs7ehendn (which does not exist) then with this error Perl is throwing >on this version, the user would crash the server instead of receiving an error >like ''kakahs7ehendn.ext was not found in @INC''. See what I mean? > >It would be silly to allow a user supplied parameter to cause your script to fail. > >You could easily check the parameter before actually using it in a do/require. >eg: if (-f ''$page.ext'') { do $page; } # check for plain file before using > >You should probably also make sure you remove any /s etc from a path before >shelling out or using that path in a manner that would allow the user to >access other directories on the computer. An ideal solution would be to >have a list of all the possible allowed pages in a hash anbd check for >existence in the hash. > >Lack of defensive coding can only hurt you in the long run. Well, you are right but it would hurt because it would always put the extension after the file name. For example, in this code: require 'e:/mysite/mydir/'.$page.'.reqfile'; In this case if a user types whatever on the query string say to gain access to executables, for example "http://mysite.ext/?page=perl.exe"; the script actually would look for 'e:/mysite/mydir/perl.exe.reqfile'. So, even if the executable file (in this case "perl.exe") was located in that dir (which wouldnt be), the user would receive an error because the script is looking for "perl.exe.reqfile" and no "perl.exe". Also if the user gained access to other directory different from "e:/mysite/mydir/", he couldn't get access to any file different from a file with ".reqfile" extension. The ".reqfile" extension will always get in front of the path. Am I right or wrong? > >> Also, imagine that I have no admin control over the server my scripts are running >and this happened? what could I do? The would I have to fix every script I have >coded before because I didn't use eval? I mean, is it normal to enclose require >with eval? I have seen a lot of other people's scripts and none of them use eval >when requiring an external file. >> >> That is my point and the real reason why I posted this. Is that I dont get why >PerlIS behaves like this in this version when earlier versions didnt act like >this. I have never enclosed ''require'' lines with ''eval'' before and PerlIS never >did this even if I didnt use ''eval''. > > >-- > ,-/- __ _ _ $Bill Luebkert Mailto:[EMAIL PROTECTED] >(_/ / ) // // DBE Collectibles Mailto:[EMAIL PROTECTED] > / ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/ >-/-' /___/_<_</_</_ http://dbecoll.tripod.com/ (My Perl/Lakers stuff) > >_______________________________________________ >Perl-Win32-Users mailing list >[EMAIL PROTECTED] >To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > > > _______________________________________________ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
