Perl: how to stop users from executing commands from browser

Discussion in 'Perl Misc' started by Nick, Sep 23, 2003.

  1. Nick

    Nick Guest

    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
    Nick, Sep 23, 2003
    #1
    1. Advertising

  2. Nick

    Tony Curtis Guest

    >> On 22 Sep 2003 16:08:14 -0700,
    >> (Nick) said:



    > 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
    Tony Curtis, Sep 23, 2003
    #2
    1. Advertising

  3. Nick

    Mina Naguib Guest

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

    Nick wrote:
    > 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-----
    Mina Naguib, Sep 23, 2003
    #3
  4. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    (Nick) wrote in
    news::

    > 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-----
    Eric J. Roode, Sep 23, 2003
    #4
  5. Nick

    C. Olive Guest

    (Nick) wrote in message news:<>...
    > 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
    -----
    Chris Olive
    chris [I'm at] technologEase [dot] com
    http://www.technologEase.com
    (pronounced "technologies")
    C. Olive, Sep 23, 2003
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mitchley
    Replies:
    0
    Views:
    612
    Mitchley
    Jun 10, 2004
  2. FyinsFlip
    Replies:
    4
    Views:
    3,476
    bruce barker
    Dec 29, 2004
  3. Ben Pfaff

    Re: man pages for C commands (GCC commands)

    Ben Pfaff, Jun 24, 2003, in forum: C Programming
    Replies:
    4
    Views:
    3,967
    Thomas Stegen
    Jun 28, 2003
  4. Tim Stanka
    Replies:
    1
    Views:
    795
    Jeff Epler
    Aug 2, 2004
  5. Murugesh
    Replies:
    5
    Views:
    185
Loading...

Share This Page