tags:

views:

397

answers:

4

I would like to execute a command on the server by using the system request parameters in the URL. I am running the server.

In the browser ->> //localhost:9009/?comd which is displaying the list of files in the directory as i placed in the code

if (/comd/i )        { print  $client `dir`;      }

How I can parse the request parameters? For example:

http://localhost:9009/?comd&user=kkc&[email protected]

I would like to return -->> hello user please confirm your email [email protected]

How can I parse the request parameters in the url?

A: 

use CGI;

my $cgi = CGI->new();

my $user = $cgi->param( "user" );
my $mail = $cgi->param( "mail" );

print( "Hello $user please confirm your email $mail\n" );
PP
You're not returning a Content-Type header and are not validating the input a user might send. Not validating the input is asking for problems.
Htbaa
mmm, yummy XSS vulnerabilities.
David Dorward
+2  A: 
use CGI;
use HTML::Template;

my $cgi = CGI->new;

my $html = qq{
    <!DOCTYPE HTML>
    <html>
    <head><title>Confirmation</title></head>
    <body><p>Hello <TMPL_VAR USER ESCAPE=HTML>. 
    Please confirm your email <TMPL_VAR MAIL ESCAPE=HTML></p></body>
    </html>
};

my $tmpl = HTML::Template->new(scalarref => \$html, associate => $cgi);
print $cgi->header('text/html'), $tmpl->output;
Sinan Ünür
A: 
#!/usr/bin/perl
$|++;                              # auto flush output

use CGI;                           # module that simplifies grabbing parameters from query string
use HTML::Entities;                # for character encoding
use strict;                        # to make sure your Perl code is well formed

print qq{Content-type: text/html\n\n};  # http header b/c outputting to browser

   main();                         # calling the function

   sub main{
      my $cgi    = new CGI;        # store all the cgi variables
      # the following stores all the query string variables into a hash
      #   this is unique because you might have multiple query string values for
      #   for a variable. 
      #   (eg http://localhost/[email protected]&amp;[email protected]&amp;[email protected] )
      my %params = map { $_ => HTML::Entities::encode(join("; ", split("\0", $cgi->Vars->{$_}))) } $cgi->param;

      #Input: http://localhost:9009/?comd&amp;user=kkc&amp;[email protected]
      #Output: Hello kcc please confirm your email [email protected]

      print <<HTML;
      <html>
         <head>
            <style type="text/css">.bold{font-weight:bold}</style>
         </head>
         <body>
            Hello <span class="bold">$params{user}</span> please confirm your email <span class="bold">$params{mail}</span>
         </body>
      </html>
HTML

      return 1;
   }

I hope this helps.

vol7ron
See comments about XSS on the answer given 4 months ago.
David Dorward
You're downvoting for that? This is an example and not meant to be the most secure thing ever. Your comment is considered noise.
vol7ron
Added some encoding, just to get around your XSS nonsense.
vol7ron
A: 

I only have a few points, so I can't comment on other's answers, but I agree with PP and vol7ron's answers. David's reminder about the XSS security thing is important to keep in mind, but I don't think it has a place here.

This is a simple question and the question was answered in both PP's, Sinan's, and vol7ron's post. They answered the original question, which was not asking about how to echo it securely and it didn't state where it was being echoed to.

The echo might be to a text file, kkchaitu didn't specify. If it was going to a file, or to the terminal, then that would mean that there are no XSS vulnerabilities. BTW, it looks like Sinan and Vol7ron both answered the XSS problem, despite the need to. I've given them both points.

Armando
Answers on stack overflow are expected to pertain to programming. Your writing above is an editorial opinion about other answers -- this is not appropriate. Additionally, your opinion that gratuitous advice on writing secure software is not welcome on stackoverflow.com is wrong. I recommend you delete this answer before it gets voted down to -1.
Heath Hunnicutt
@Heath, thank you. Sorry, I'm still getting used to this site. It wouldn't allow me to comment because I didn't have enough points, so I had to create an answer to comment. It just seems like David was unfairly stating "XSS" exploits, which had nothing to do with the question and then was downvoting my friends' posts because of it. I'm sure they wouldn't mind if they had thousands of points, but I don't think that's fair when they barely have any.
Armando
@Armando, yw. Now that I have read PP and Vol7ron's answers, I can see why they received -1. Posting an XSS vulnerability is good reason for everybody to downvote that answer into oblivion. Some people copy-and-paste code off of this website because they don't have any better coding skills than that. Do you feel comfortable that such a person will recognize the XSS holes in example code and not put them into production? Showing a vulnerability in an answer is awful form. Answering in June a well-answered question from February is slightly rude.
Heath Hunnicutt
@Heath, the asker did not say where it was going to be returned to. It could be returned to the browser or to an email, or even to a file in an FTP location. Downvoting should not be used on valid answers. If there's a problem with an answer, or something to think about... that's what these comments are for. Example: upvote the answer because it was valid, then mention that there could be an XSS hack, so modify it by... -- It looks like vol7ron fixed it, but his answer is still marked down - that's why valid answers shouldn't be discredited.
Armando
@Heath, if David had a better answer, he should have written it up - his upvotes would have won out. Additionally, just to say that there is an XSS problem, but not say where the problem is, is a horrible comment. If his comment weren't helpful, I would have downed it for lack of specifics. -- Really though, Sinan, PP, and vol7ron answered what was asked. They shouldn't have to go beyond what was asked; they could have built a login system, talked about server security, encryptions, .htaccess files, etc. That is a whole other question/topic, so they shouldn't be penalized.
Armando
@Heath, penalizing users will make them less likely to help out elsewhere.
Armando
@Armando, with 22 points you need to type less and read more. You are just wrong about the XSS, don't try to talk to me about it.
Heath Hunnicutt
@StackOverflow Heath doesn't understand what XSS is. If you claim something and aren't able to defend it, then there is no claim. Your only arguement is that I don't have any points. That's funny.
Armando