Perl: how to stop users from executing commands from browser

N

Nick

I'm working on an HTML file that calls cope of Perl scripts with
parameters.
If you take your cursor over to the link, you can see the command that
will be send to the perl script and at this point user can modify that
and execute it from web browser. How can i prevent this from
happening?????
Anyway to block users from executing any commands from web browser????

Thanks in advance.
Nick
 
T

Tony Curtis

On 22 Sep 2003 16:08:14 -0700,
I'm working on an HTML file that calls cope of Perl
scripts with parameters.

I don't know what "cope of" is supposed to mean.
If you take your cursor over to the link, you can see
the command that will be send to the perl script and at
this point user can modify that and execute it from web
browser.

.... can pass the specified arguments to a server-side
process ...
Anyway to block users from executing any commands from
web browser????

Never pass code from client to server. Always pass a
token that the server-side code looks up in a table and
then executes code based on the token. An unknown token
generates an error.

perldoc CGI
perldoc -q server

hth
t
 
M

Mina Naguib

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm working on an HTML file that calls cope of Perl scripts with
parameters.
If you take your cursor over to the link, you can see the command that
will be send to the perl script and at this point user can modify that
and execute it from web browser. How can i prevent this from
happening?????
Anyway to block users from executing any commands from web browser????

Rule #1 when developing a server-client program (including web server -> web browser relationship):
NEVER TRUST THE CLIENT
Rule #2:
Never trust the data the client sends you.

You have to be extremely meticulous in which data you accept from a client and what format it's in,
and validate and re-format it very carefully to make sure it's safe.

Accepting a commandline command (or even argument) submitted from a web browser is just a disaster
waiting to happen.

Instead, you should have a list of valid commands like so in your CGI:

%validcommands = (
"foo" => {
"command" => "/path/to/foo.bin",
"validarguments" => {
"fooarg1" => "-s",
"fooarg2" => "-Wall",
},
},
"bar" => {
"command" => "/path/to/bar.bin",
"validarguments" => {
"bararg1" => "-X",
"bararg2" => "--n",
},
},

);


And then only accept command references from the client and check them against the above structure:

exists $validcommands{ $cgi->param("command") } || die "Error: Invalid command\n";

# Same goes for allowed parameters:

exists $validcommands{ $cgi->param("command") }{"validarguments"}{ $cgi->param("parameter") } || die
"Error: Invalid argument for command\n";

# Then, form actual command to execute from known trusted data, never from direct client input

system($validcommands{ $cgi->param("command") }, $validcommands{ $cgi->param("command")
}{"validarguments"}{ $cgi->param("parameter") });


Finally, try to do whatever you're doing with just perl or Perl modules if possible, and at all
costs avoid using system(), exec() and `` from a CGI program. Also always enable strict and taint
checking, and log everything that you do in sensitive areas including timestmp and IP addresses.

The above is probably a lot more work than you're used to, but it just might save you from an
unpleasant "rm -rf /" by mr. anonymous cracker someday.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/b7K9eS99pGMif6wRAnmQAKD9OjRIXJ6QvLHpAIudmNTduCZQjwCgpwgt
ccqk6D6SVVgjzzzFSjAW94E=
=BIgO
-----END PGP SIGNATURE-----
 
E

Eric J. Roode

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(e-mail address removed) (Nick) wrote in
I'm working on an HTML file that calls cope of Perl scripts with
parameters.
If you take your cursor over to the link, you can see the command that
will be send to the perl script and at this point user can modify that
and execute it from web browser. How can i prevent this from
happening?????
Anyway to block users from executing any commands from web browser????

I am not sure what you mean by "cope of". Maybe "a couple of"?

You also are using the word "command" in a very fuzzy manner. Exactly what
do you mean by "command"? URL? CGI script name? Perl operators and/or
code? Shell commands?

If you require the user to click on some link or button in order to perform
some action, there is no way to prevent the user from seeing what is the
underlying data the browser will send to the server.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP3Anr2PeouIeTNHoEQK93ACeOF4+6WumqCuMfrs/uP/8PdBwWdQAoMlE
yAnz40IVcJEHeVqqbQIwwsG3
=cBr9
-----END PGP SIGNATURE-----
 
C

C. Olive

I'm working on an HTML file that calls cope of Perl scripts with
parameters.
If you take your cursor over to the link, you can see the command that
will be send to the perl script and at this point user can modify that
and execute it from web browser. How can i prevent this from
happening?????
Anyway to block users from executing any commands from web browser????

Thanks in advance.
Nick

Aside from all the necessary warnings and help concerning ideas to
keep arbitrary user commands from being sent to and executed on your
web server, I *think* what you are saying is you don't want ANYTHING
that you have for your HREFs to show up on the client's browser in
their status window. For instance, if you have this in your HTML:

<a href="/cgi-bin/foo.pl?idx=3&config=foobar">Click me</a>

When you run your mouse over the link, you see this in the status
window of the browser on the client side:

[http://www.somewhere.com/cgi-bin/foo.pl?idx=3&config=foobar]

And you don't want them to see that... That's what you mean right?

Understand first, there is no way you can block a truly technically
astute person from *finding* this information. There are a number of
stratigies you can use to block this from the average user and/or make
it difficult to find. Before mentioning some however, understand
this: The effort you make here is somewhat and largely in vain because
a non-technical user doesn't know enough about what they are seeing to
do something damaging with it ANYWAY, and for the person that DOES
know what to do with that kind of information, they also have the
ability, in most cases, to *find* it even if you take pains to hide
it. So that's the delimma in this situation.

I like to "hide" this kind of information for two reasons: (1) I think
seeing a real message in the status window instead of some URL
information adds to the polish of the site, and (2) simply because
seeing a real message at least doesn't plant any ideas in someone's
head (that DOES know what they are doing) in the first place that
could happen if the URL/script information showed up in the status
window (eg. "Hey, did you see THAT??!! I wonder what would happen if
I did THIS...!") So a minimal effort has some reward; a huge effort
is not worth the time.

Strategy #1: Use onMouseOver events for your anchor tags:

<a href="/foo.pl?idx=3&config=foobar" onMouseOver="parent.status='Show
Membership Details'; return true;" onMouseOut="parent.status='';
return true;">Show Membershp Details</a>

When the mouse hovers the link, then instead of the actual URL script
showing up, all they see is the very friendly message "Show Membership
Details" in their browser status window.

Cons: Relies on JavaScript support on the client-side browser being
turned on; User can still see the script call using "View Source" in
the browser.

Strategy #2: To block URL from reforming in the address window:

Use frames. A variation on this is to use a hidden frame of size 0.
A further variation is to place client-side JS wrappers to server side
calls inside the hidden frame and have client-side wrappers make the
real server-side calls. So even an inspection with "View Source" in
the non-hidden frame shows only client-side calls, not server calls.
Combine with strategy #1 and this is pretty good although I don't make
this large of an effort myself. I use hidden frames (almost always)
and onMouseOvers; anything beyond and it seems like a waste of time
because...

Like I said, you are only delaying the inevitable from the truly
technical user. There is no way to completely hide your call. I
believe strategy #1 is worth doing because it takes minimal effort and
at least disallows ideas from initially forming in the minds of those
that know what they are doing. For the person that doesn't know a
cgi-bin URL from an internet email address, it doesn't matter anyway
other than for the polish of your site.

Beyond this, any other precautions are simply security precautions and
don't answer your question directly. You've been offered a few of
these solutions. There are a few more -- some of them again with
minimal effort that are worth the time to implement -- but none that
block the information from being seen on the client side as you asked.
In brief, onMouseOver events are your best bet.

chris
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top