|
Re: Re: the search string and me
by Corion (Patriarch) on Sep 12, 2003 at 07:42 UTC
|
Your code dosen't handle urls that use ; as the parameter separator, and it dosen't properly handle multiple values for one parameter name.
It also presents a huge backdoor, as it will allow any attacker to overwrite any global scalar variable in your script by sending a carefully crafted query against it. You don't show the tokenise subroutine, but I see that using a parameter name of {main::foo} will set/overwrite the global variable $main::foo.
Furthermore, any query with the string *amp* in it (for example in a search) will mutilate the whole query string - this must at least be documented, and is poor practice. The same goes for *plus*, and there even is no reason for that.
There is a reason why people use CGI.pm or its lighter cousin, CGI::Lite, as it presents a safe and relatively foolproof way of decoding script parameters.
perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
| [reply]
[d/l] |
|
|
dosen't handle urls that use ; as the parameter separator, and it dosen't properly handle multiple values for one parameter name
Neither of those things is needful, generally, and
since this is his own function, which he is using in
his own scripts, he has complete control over whether
the scripts use those esoteric features.
It also presents a huge backdoor
Yes, absolutely. Rather than assigning directly to
global variables, he should be storing the input in
a hash.
Furthermore, any query with the string *amp* in it
Indeed. See my obfuscated version above, which handles
this correctly. (Its larger, unobfuscated prototype,
the function I normally use, also handles some things
that I stripped out for brevity, such as file uploads,
but those things are not needed for most CGI scripts.)
There is a reason why people use CGI.pm or its lighter cousin, CGI::Lite
Yes, but as came up in a recent unrelated thread, there
are also good reasons, especially for scripts that
may be deployed in various locations under various
circumstances, to avoid using any non-core modules
(or, in fact, anything that hasn't been in core at
least since 5.003). Also there are good reasons for
generating all the HTML yourself, as it allows you
to guarantee certain things about its structure.
It is of course certainly possible to use a module
for fetching the input and still generate the output
yourself, however.
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
| [reply]
[d/l] |
|
|
can you give me a link to your "See my obfuscated version above.." you mentioned in relation to parsing & and the use of "*amp*"
Thanks for the comments,
___
/\__\ "What is the world coming to?"
\/__/ www.wolispace.com
| [reply]
[d/l] |
|
|
|
|
|
|
|
Thankyou for your comments
If a variable were overwritten by a crazy, deranged or plain curious person, could that have more serious effect than stop the code from working?
If I never try to execute a scalar variable as a command, the worst it can do it perhaps display incorrect values.. yes?
Or could some clever trick be performed at my initial eval statement?
As for the *amp* stuff.. that was for resolving a particular issue I had at one stage and has remained as it has not caused problem since :-)
___
/\__\ "What is the world coming to?"
\/__/ www.wolispace.com
| [reply]
[d/l] |
|
|
I think you take the wrong approach to interaction on the internet: Your users should never be regarded as crazy, deranged or plain curious, but as malicious. And yes, I do think that overwriting a global value can have severe effects. But you use eval to set that string. So if I would craft a query parameter named [system q(rm -rf /)], that code would be executed by your eval statement. You could do some dereferencing via a hash to fill the variable with the parameter to get around the eval statement, but let's face it - CGI.pm and its cousins already do that and in a tried and tested way.
perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
If a variable were overwritten by a crazy, deranged or plain curious person, could that have more serious effect than stop the code from working?
Potentially, if crafted in malice, depending on what
your code does with global variables. (Bear in mind
also that the special variables are vulnerable under
your implementation.) You could think through each
and every global variable and each special variable
to determine whether anything your script does could
have bad effects if one of these variables holds a
malicious value, or you could store the input in a
hash and save yourself that effort. Running under
taint mode would also help to curb this threat or at
least make it much harder for anyone to exploit.
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
| [reply]
[d/l] |