Special Characters in INPUT field 3

[chipk]

I hope I'm asking this in the correct forum, if not, please point me in the correct direction.

I have an html form, which calls a perl cgi script. Everything works until I enter certain data in the fields. Specifically, I have an input field like so:

<b>Login:</b> <input type="password" name=login>  <br>

Unfortunately, the data I need to enter in this field begins with a bang (!). The form misinterprets this and my cgi script dies because the ! gets interpreted as something like %21. Anyone have any idea how I can get that special character to work?

 

[mbrooks]

What method are you using to parse the param data? CGI.pm ?

M. Brooks

http://mbrooks.info

 

[chipk]

Yes, cgi.pm, but it doesn't even get passed to the perl script correctly. I can see in the address field after I hit the submit button that the value gets garbled.

 

[mbrooks]

Works fine for me using the CGI.pm. Are you using javascript to POST the form data?

#!/usr/bin/perl -w

use strict;

use CGI;
my $q = new CGI;

my $pass = $q->param('password');

if ($pass) {
    print $q->header, $pass;
}
else {
    print $q->header;

print <<FORM;
<form method="POST" action="test.pl">
<input type="password" name="password">
<input type="submit">
</form>
FORM
}

M. Brooks

http://mbrooks.info

 

[Kirsle]

Try URI::Escape, it turns things like %21 into things like !

use URI::Escape;

my $in = "hello%20world%21";
my $out = uri_unescape ($in);
print "$out\n";
______

hello world!

Web browsers url-encode things passed in through forms (particularly through the GET method), just use URI::Escape to unescape the url-encodings.

 

[chipk]

mbrooks - My code looks different (and messy-er) than yours; I must have something in my syntax that is messing me up if yours works.

Kirsle - I'll try to get that package and try this method out as well.

Thank you both for the suggestions, will let you know what works.

 

[chipk]

mbrooks - using your method worked for me. I was actually using an html form and passing it to my pl script. Doing it your way worked much better.

Kirsle - thanks, but I have ActiveState on WIN32 and URI::Escape isn't available in my ppm. I'm not too familiar with adding packages using other methods.

 

[Kirsle]

I have ActiveState's Perl on my WIN32 box, too. URI::Escape came preinstalled with it.

Try going into command prompt and type this:

perl -MURI::Escape -e exit

If you have URI::Escape installed, it will simply return to the command prompt, else it will complain that URI/Escape.pm is missing. Quickest way to find if you have a module or not. ;-)

 

[chipk]

Kirsle - thanks, that actually works too. I didn't realize that package was built in, but now I've found it in my documentation.

 

[goBoating]

In some shops, accepting anything other than plain vanilla text is frowned upon. If you are using user/form inputs in any kind of system interaction, it is dangerous to allow users to input anything that has some syntactical meaning.

For instance, the semi-colon is a command separator in Unix. You would not want to let users enter something like
'nameHere;rm -rf *' into a text entry field in a form if that text is to be used in a pipe or open statement. There are other security practices that should help protect the machine, but, if the Web server has sufficient priviledges on the file system, passing that string from the form to the CGI code can potentially allow the user to run the 'rm -rf *' command which might be able to delete files.

Long story short, be careful what you allow your code to ingest from a form and be very careful with any content entered into a form.

Always run your CGIs in taint mode.
Always employ 'use strict'.

'hope this helps

If you are new to Tek-Tips, please use descriptive titles, check the FAQs, and beware the evil typo.

 

[chipk]

Thanks for the input, goBoating. I'm not familiar with "taint mode", could you explain what you mean by this?

 

[feherke]

Hi

While in this mode, Perl takes special precautions called taint checks to prevent both obvious and subtle traps. Some of these checks are reasonably simple, such as verifying that path directories aren't writable by others; careful programmers have always used checks like these. Other checks, however, are best supported by the language itself, and it is these checks especially that contribute to making a set-id Perl program more secure than the corresponding C program.

You may not use data derived from outside your program to affect something else outside your program--at least, not by accident. All command line arguments, environment variables, locale information (see perllocale), results of certain system calls (readdir(), readlink(), the variable of shmread(), the messages returned by msgrcv(), the password, gcos and shell fields returned by the getpwxxx() calls), and all file input are marked as "tainted". Tainted data may not be used directly or indirectly in any command that invokes a sub-shell, nor in any command that modifies files, directories, or processes, with the following exceptions:

[gray]...[/gray]

http://www.perl.com/doc/manual/html/pod/perlsec.html

Feherke.

http://rootshell.be/~feherke/

 

[goBoating]

What ferke said (typed).

Using taint mode is a little tedious, but, worth the annoyance. In taint mode, if you accept input from outside of your program, like from a web form, you must 'untaint' the variable before 'taint mode' will allow you to use that variable in a dangerous way. To untaint a variable you must pass it through a regex and catch the match.

For instance, if your form has quantity input from which you'd expect to get an integer, you check to see that it is an integer.

#!/usr/bin/perl -Tw
use strict;
use CGI;

my $cgi_object = new CGI;
my $quantity = $cgi_object->param('quantity');
# $quantity is tainted at this point.

# if $quantity is start with, is one or more digits, 
# and ends with digits(/^\d*$/),
# then set $quantity to be the pattern matched ($&)
if ($quantity =~ /^\d*$/) { $quantity = $&; }

# $quantity is now untainted.  You have made sure that
# the form input is safe to play with.

'hope this helps

If you are new to Tek-Tips, please use descriptive titles, check the FAQs, and beware the evil typo.

 

[chipk]

You guys have been very helpful. Thanks for all the input.