Perl CGI executing command line functions

Discussion in 'Perl Misc' started by Nick, Oct 1, 2003.

  1. Nick

    Nick Guest

    I am just starting out with Perl and am trying to figure out how to
    setup a CGI script to perform some command line functions. I work
    with some people that need to run some command line functions but we
    do not want to give them command line access. I thought that if I
    write a Perl CGI script that executes some of the commands for them,
    it would solve our problems.

    I have found tons of examples and tutorials that show you how to get a
    Perl CGI to write to files, display HTML pages and print lines. What
    is the correct syntax for backticks in Perl? My goal was to give them
    allow
    them access to some HTML pages with some forms where they enter the
    options for certain commands.

    For example, if I had this as my HTML form and the user entered "-al"
    <form action="dosomething.cgi" method="GET">
    Enter an #ls option: <input type="text" name="commd" size=30><p>
    <input type="submit">
    </form>

    How would I get Perl to run that #ls command with the user's option
    values (#ls -al) and display the end result of that command?
    Would it be something similar to
    `ls` $commd;
    How would I show the end result?

    Thanks in advance,
    Nick
     
    Nick, Oct 1, 2003
    #1
    1. Advertising

  2. In article <>,
    (Nick) wrote:

    > I am just starting out with Perl and am trying to figure out how to
    > setup a CGI script to perform some command line functions. I work
    > with some people that need to run some command line functions but we
    > do not want to give them command line access. I thought that if I
    > write a Perl CGI script that executes some of the commands for them,
    > it would solve our problems.
    >
    > I have found tons of examples and tutorials that show you how to get a
    > Perl CGI to write to files, display HTML pages and print lines. What
    > is the correct syntax for backticks in Perl? My goal was to give them
    > allow
    > them access to some HTML pages with some forms where they enter the
    > options for certain commands.
    >
    > For example, if I had this as my HTML form and the user entered "-al"
    > <form action="dosomething.cgi" method="GET">
    > Enter an #ls option: <input type="text" name="commd" size=30><p>
    > <input type="submit">
    > </form>
    >
    > How would I get Perl to run that #ls command with the user's option
    > values (#ls -al) and display the end result of that command?
    > Would it be something similar to
    > `ls` $commd;
    > How would I show the end result?
    >
    > Thanks in advance,
    > Nick


    the most naive way would be this:

    #----------------------------------------
    #!perl -w

    use strict;
    use CGI qw/:standard/;

    $|++;

    print header();

    my $commd = param('commd');

    print `ls $commd`;
    #----------------------------------------

    however... think of what would happen if the user entered "; rm -fr *.*"
    !!!!!!!

    you might wanna constrain what is allowable...
    --
    Michael Budash
     
    Michael Budash, Oct 1, 2003
    #2
    1. Advertising

  3. It was a dark and stormy night, and Nick managed to scribble:

    > I am just starting out with Perl and am trying to figure out how to
    > setup a CGI script to perform some command line functions. I work
    > with some people that need to run some command line functions but we
    > do not want to give them command line access. I thought that if I
    > write a Perl CGI script that executes some of the commands for them,
    > it would solve our problems.


    Use the 'system' command. You will probably nned fully qualified paths if you use CGI.

    gtoomey
     
    Gregory Toomey, Oct 1, 2003
    #3
  4. Nick wrote:
    > I work with some people that need to run some command line
    > functions but we do not want to give them command line access. I
    > thought that if I write a Perl CGI script that executes some of the
    > commands for them, it would solve our problems.


    *Some* of the commands? Do they have access to upload and run their
    own CGI scripts? In that case, what prevents them from uploading a
    script and executing *any* system command?

    Just a thought.

    > For example, if I had this as my HTML form and the user entered
    > "-al"
    > <form action="dosomething.cgi" method="GET">
    > Enter an #ls option: <input type="text" name="commd" size=30><p>
    > <input type="submit">
    > </form>
    >
    > How would I get Perl to run that #ls command with the user's option
    > values (#ls -al) and display the end result of that command?
    > Would it be something similar to
    > `ls` $commd;
    > How would I show the end result?


    An example:

    $result = `ls $commd 2>&1`;

    The '2>&1' part makes it capture also possible error messages in $result.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Oct 1, 2003
    #4
  5. Nick <> wrote:

    > I am just starting out with Perl and am trying to figure out how to
    > setup a CGI script



    You should learn Perl itself first, before moving on to a
    complicated application area such as CGI programs.


    > to perform some command line functions. I work
    > with some people that need to run some command line functions but we
    > do not want to give them command line access.



    Why is it that you do not want to give them command line access?


    > I thought that if I
    > write a Perl CGI script that executes some of the commands for them,
    > it would solve our problems.



    It seems much more likely to me to _cause_ more problems
    that it solves.

    I think we have an XY problem.

    If you can answer the question above, we will be in a much better
    postion to give good advice...


    > How would I get Perl to run that #ls command




    What is the "#ls" command?


    > with the user's option



    You better turn taint checking on (-T) and check the user's input
    very very carefully. You have lots of chances of opening up a
    security hole with your idea. Be careful.


    > values (#ls -al) and display the end result of that command?
    > Would it be something similar to
    > `ls` $commd;



    Assuming that $commd has somehow gotten the corresponding value
    from the form, hopefully by calling CGI::param():

    my $result = `ls $commd`;


    > How would I show the end result?


    print $result;

    If it is in a CGI program where the output is supposed to go
    to STDOUT anyway, then you do not need to capture the output
    at all:

    print "Content-type: text/plain\n\n";
    system "ls $commd";


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Oct 2, 2003
    #5
  6. Nick

    Nick Guest

    Thanks guys.

    (Tad McClellan) wrote in message
    > You should learn Perl itself first, before moving on to a
    > complicated application area such as CGI programs.


    sounds like a fine idea and I intend to do this but I was hoping I
    could pick up enough to write this CGI program
    >
    > Why is it that you do not want to give them command line access?
    >

    Our company has a policy that does not allow departments other than IT
    to have command line access to the app servers. Another department in
    our company uses a program that makes additions/changes to one of our
    app servers & database and the only current way to make these specific
    changes is for them to put in a request with the IT department to
    manually type in this application's script.
    >

    Gunnar Hjalmarsson <> wrote in message news:<blfh4d$bgeu8$-berlin.de>...
    > *Some* of the commands? Do they have access to upload and run their
    > own CGI scripts? In that case, what prevents them from uploading a
    > script and executing *any* system command?
    >

    Yes, they do have this control but since they are part of our company
    we trust them and the app server and database is their equipment, we
    just run/houses/configure so it is unlikely they will do harm to their
    own machines
    >
    >
    > An example:
    >
    > $result = `ls $commd 2>&1`;
    >
    > The '2>&1' part makes it capture also possible error messages in $result.


    Thanks!

    Gregory Toomey <> wrote in message news:<1211198.pjaMW0z05n@gregs-web-hosting-and-pickle-farming>...
    > It was a dark and stormy night, and Nick managed to scribble:
    >

    Aaaaah, the story of my life.

    Michael Budash <> wrote in message news:<>...

    > the most naive way would be this:
    >
    > #----------------------------------------
    > #!perl -w
    >
    > use strict;
    > use CGI qw/:standard/;
    >
    > $|++;
    >
    > print header();
    >
    > my $commd = param('commd');
    >
    > print `ls $commd`;
    > #----------------------------------------
    >
    > however... think of what would happen if the user entered "; rm -fr *.*"
    > !!!!!!!
    >
    > you might wanna constrain what is allowable...



    We would restrict them to only certain commands. While that doesn't
    mean that they couldn't put a pipe in the options and enter a 2
    commands at once but it is unlikely they would try to do any harm.
    Thanks for the help!
     
    Nick, Oct 2, 2003
    #6
  7. On Thu, 2 Oct 2003, Nick wrote:

    > sounds like a fine idea and I intend to do this but I was hoping I
    > could pick up enough to write this CGI program


    As others have already warned you in various ways: you seem to be
    setting yourself up for a security compromise.

    Don't misunderstand me: there's nothing wrong with playing around and
    exploring the capabilities of your various tools, and everybody needs
    to make a start somewhere; but for a serious production application
    you _do_ need a sound grasp of the components (Perl, CGI,
    security...), and it seems to me that you are playing with fire if you
    attempt it with less. I'm not sure that I'd want to trust myself to
    get that sort of thing right without some aggressive peer-review, and
    I've been dealing with computers, off and on, since 1958.

    It isn't a simple matter of "trusting" the users: maybe they hadn't
    appreciated the consequences of their well-intentioned actions, but if
    you haven't screened them effectively enough from the dangerous bits
    them the result would be as bad, irrespective of their intentions in
    the matter. Isn't that why the company policy is to keep them away
    from the command line in the first place, after all?
     
    Alan J. Flavell, Oct 2, 2003
    #7
  8. (Nick) writes:

    > (Tad McClellan) wrote in message


    > > Why is it that you do not want to give them command line access?
    > >

    > Our company has a policy that does not allow departments other than IT
    > to have command line access to the app servers.


    This reminds me of something that I've heard of happening in a number
    of places in one form or another.

    The basic senario comes down to this.

    Someone in a company decides that some resource needs to be protected
    from the masses. So the rooms containing that resource have their
    locks changed. The minions are not given keys to the rooms where the
    valuable resource is housed.

    However, in order to do their jobs the minions need to use the
    resource. The solution is to hang a key to the secure rooms in a
    place where everyone (including visitors without even the minions'
    keys) can get to it.

    --
    \\ ( )
    . _\\__[oo
    .__/ \\ /\@
    . l___\\
    # ll l\\
    ###LL LL\\
     
    Brian McCauley, Oct 2, 2003
    #8
  9. Nick

    Phil Meyer Guest

    In article <>,
    (Nick) writes:
    > Thanks guys.
    >
    > (Tad McClellan) wrote in message
    >> You should learn Perl itself first, before moving on to a
    >> complicated application area such as CGI programs.

    >
    > sounds like a fine idea and I intend to do this but I was hoping I
    > could pick up enough to write this CGI program


    This can all be done, and has been done safely before, and even presented
    in this forum before. But the basics are:

    By allowing an input field for a user to type into, you are subject to
    stuff like this:

    enter arguments to ls: -l ; cat /etc/passwd

    See what I mean?

    The best way to do this is with a pull down list, checkboxes, or something
    similar. If you allow an input field, you have just allowed acces to the
    system. If the list of things that they need to do is larger than the
    scope of a list, then you need to provide them an account. At LEAST a
    web account that they must log in with before using your tool. You would
    also want your tool to log actions taken by userid.

    Collecting process accounting for individual accounts is MUCH safer than
    trying to figure out which IP was connected to the web server at the time
    of the 'problem'.

    Some years ago I did an application for the help desk that allowed them to
    run common commands on any system in the data center by clicking on a web
    page. It was used for first level system check before escalation. It
    used secure shell from a trusted host, and some of the commands needed to
    be run as root (vxdisk list, for example). The only way that this can be
    done safely, is to define a finite set of commands that they will use, and
    build forms that allow options by selection ONLY. Never an input field.

    The cgi scripts that run these commands must have rigid checks of the fields
    that they are passed. Even though they were hard coded in the forms, users
    could figure out which cgi scripts are being called and try to pass them
    commands directly.

    Hope this helps.
     
    Phil Meyer, Oct 3, 2003
    #9
  10. Nick

    ko Guest

    Phil Meyer wrote:

    [snip]

    > This can all be done, and has been done safely before, and even presented
    > in this forum before. But the basics are:
    >
    > By allowing an input field for a user to type into, you are subject to
    > stuff like this:
    >
    > enter arguments to ls: -l ; cat /etc/passwd
    >
    > See what I mean?
    >
    > The best way to do this is with a pull down list, checkboxes, or something
    > similar. If you allow an input field, you have just allowed acces to the
    > system. If the list of things that they need to do is larger than the
    > scope of a list, then you need to provide them an account. At LEAST a
    > web account that they must log in with before using your tool. You would
    > also want your tool to log actions taken by userid.


    I have a question about whether an input field is any more secure than a
    pull-down list/checkbox. Even though the form is hard-coded can't
    aynyone submit pretty much anything they want, for example with LWP?

    > Collecting process accounting for individual accounts is MUCH safer than
    > trying to figure out which IP was connected to the web server at the time
    > of the 'problem'.
    >
    > Some years ago I did an application for the help desk that allowed them to
    > run common commands on any system in the data center by clicking on a web
    > page. It was used for first level system check before escalation. It
    > used secure shell from a trusted host, and some of the commands needed to
    > be run as root (vxdisk list, for example). The only way that this can be
    > done safely, is to define a finite set of commands that they will use, and
    > build forms that allow options by selection ONLY. Never an input field.
    >
    > The cgi scripts that run these commands must have rigid checks of the fields
    > that they are passed. Even though they were hard coded in the forms, users
    > could figure out which cgi scripts are being called and try to pass them
    > commands directly.


    This is more what I thought you are supposed to do with CGI - rigidly
    check all fields passed to the form - the person who builds the form
    specifies a set of *acceptable* parameters, and anything that does not
    fall in the defined set gets ignored, calls an error routine, etc. In
    other words, all form element are equally not secure.

    Please correct me if I am making any incorrect assumptions.

    thanks - keith
     
    ko, Oct 3, 2003
    #10
  11. On Fri, 3 Oct 2003, ko wrote:

    > I have a question about whether an input field is any more secure than a
    > pull-down list/checkbox.


    I have an answer, and it would be on-topic for
    comp.infosystems.www.authoring.cgi because there's nothing
    Perl-specific in it...

    > Even though the form is hard-coded can't
    > aynyone submit pretty much anything they want, for example with LWP?


    Correct.

    [...]
    > Please correct me if I am making any incorrect assumptions.


    About the appropriate group to post to, see above.

    About the topic, see Lincoln Stein's web security FAQ.

    But basically, as to content you seem to be on the right lines.
     
    Alan J. Flavell, Oct 3, 2003
    #11
  12. Nick

    ko Guest

    Alan J. Flavell wrote:

    > On Fri, 3 Oct 2003, ko wrote:
    >
    >
    >>I have a question about whether an input field is any more secure than a
    >>pull-down list/checkbox.

    >
    >
    > I have an answer, and it would be on-topic for
    > comp.infosystems.www.authoring.cgi because there's nothing
    > Perl-specific in it...
    >


    [snip]

    >
    >>Please correct me if I am making any incorrect assumptions.

    >
    >
    > About the appropriate group to post to, see above.
    >
    > About the topic, see Lincoln Stein's web security FAQ.


    Thanks for the advice, I've already read the FAQ. I guess my overly
    subtle (bad) attempt to give the OP a hint that he should check *all*
    form element parameters should have been posed as statements rather than
    questions.

    And actually, a little over a year ago you were generous enough to help
    me when I was writing my "First CGI script". Although I admit at least I
    posted snippets of code :)
     
    ko, Oct 3, 2003
    #12
  13. Nick

    Bill Guest

    ko <> wrote in message news:<bljf8i$bg1$>...
    > Phil Meyer wrote:
    >


    > I have a question about whether an input field is any more secure than a
    > pull-down list/checkbox. Even though the form is hard-coded can't
    > aynyone submit pretty much anything they want, for example with LWP?
    >
    > > Collecting process accounting for individual accounts is MUCH safer than
    > > trying to figure out which IP was connected to the web server at the time
    > > of the 'problem'.
    > >


    (OT)

    Linux has Webmin to do all that you are asking in its CGI 'shell'
    feature:

    http://www.webmin.com

    --and I think that some of their code can be adapted to do what you
    want.

    However, this is not really Perl, and, I think allowing anyone out
    there on the Web to use either Webmin or your equivalent of an
    arbitrary command line is __very very__ unwise. IMHO, Webmin is best
    confined _behind_ a firewall.
     
    Bill, Oct 3, 2003
    #13
  14. Nick

    Nick Guest

    Thanks for all your comments. I will definitely look into all the
    possibilities before I commit to anything, everyone has given me a lot
    to look into. Even though there will be someone that reviews and
    corrects any flaws in my CGI script (that person just doesn't have the
    time right now to write the script so I thought I would try it and
    learn a little Perl in the meantime) I will study up on some Perl
    before I attempt to jump into this. A friend gave me a Perl book to
    read, so I will study up on that and then come back with some more
    questions.

    Thanks,
    Nick
     
    Nick, Oct 3, 2003
    #14
  15. Nick <> wrote:

    > A friend gave me a Perl book to
    > read



    Which one?

    There are lots of poor Perl books.

    Tell us which one you have, and we'll tell you if it's good or not.


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Oct 3, 2003
    #15
    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. Arun
    Replies:
    4
    Views:
    332
    anonymous
    Jan 3, 2005
  2. Sharp Tool
    Replies:
    7
    Views:
    19,605
    Andrew Thompson
    Jul 20, 2005
  3. Alain Star
    Replies:
    7
    Views:
    172
    Tad McClellan
    Jan 18, 2005
  4. Ting Wang
    Replies:
    3
    Views:
    197
    Paul Lalli
    Dec 13, 2005
  5. kath
    Replies:
    4
    Views:
    641
    J. Gleixner
    Apr 9, 2007
Loading...

Share This Page