Welcome to WebmasterWorld Guest from

Forum Moderators: coopster & jatar k & phranque

Message Too Old, No Replies

Web Security



3:47 am on Aug 30, 2011 (gmt 0)

5+ Year Member

I have some questions concerning the use of security measures in a CGI script. I've been researching this one quite extensively.
One thing I see much of is restricting what kind of characters can be entered into a form field and I've also seen the reasons why. I was wondering if maybe using a regex to replace meta chars would be okay, i.e., $name =~ s/</&#60;/; and make a list of regex replacements for all of the punctuation & meta chars? I realize this would slow things down a slight and be alot of replacement codes to search but the user could still use all characters at will. If this is not a good idea whay should be allowed? Users need to be able to use question marks, periods and a few other punctuation chars. All info is sent directly to a MySql db and column names have been set different than form field names. I am going to research security issues for mysql. Another thing that crossed my mind was, since the forms will probably be run from the application (displays things in the same manner as a guestbook) was upon arrival at the url write a cookie and in the cookie have a password which is created on the fly which must validate against a variable in the processing end of the script seeing how HTTP_REFERER seems to be so undependable. Leave the cookie with no expiration date so it is a fresh code each time the form opens.--just a thought as the password would be different in every case. Maybe I'm just nervous about going live with the script.


4:17 am on Aug 30, 2011 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member

Generally you need to avoid two attacks: sql injection and html injection.
sql injection is basically the idea, that somebody highjacks your database query, which can happen if you don't escape special characters, mostly the ' which is used to encapsulate strings in mysql. to make sure that's taken care of, use placeholders:

my $sth_insert = $dbh->prepare("INSERT INTO my_table (field1, field2) VALUES (?, ?)");
$sth_insert->execute( $value_for_field1, $value_for_field2 );

and DBI will take care of it for you.

html / code injection should, imho not be defended against by deleting or replacing certain characters in the messages before you enter them into the database, but rather to replace them when you output them. I'd use HTML::Entities. Also, most templating systems have an easy way to escape that.

Setting a Cookie will not defend you against a malicious person that is acting out the attacks himself, but it will help protect against form attacks on your users, where people unknowingly submit a form on your website. there are other measures as well -- how far you go really depends on how much trouble you expect and how many people you think are out to hurt you / your users ;)


5:06 am on Aug 30, 2011 (gmt 0)

5+ Year Member

Thanks a million. I like the HTML::Entities and the way it removes things. Only thing is I'll need to be able to allow things like question marks and a few other things which is why I was considering the replacement regex's.

Also, the placeholders for entering into mysql is great---I've spent time searching for an error that was a missing 'for a value.

I was always going with
$sth_insert = $dbh->prepare("INSERT INTO my_table (field1, field2) VALUES ('?', '?')");

and had to put all those little single quote marks in.

HTML::TEMPLATE is a definite on the todo list(like next on the list). I really value the recommendations I get from you and have never been steered wrong here.

As far as what I was saying about the cookie with a password the order of operations is as follows:
&password;#sub that writes the passwords
$pword=&password;#just a variable holding &password output

#form in same script that does processing so easy to put the value in the script
&writecookie;#sub that writes cookie--no exp date...cookie value is $pword
&getcookievalue;#cookie value named cookieword
if($cookieword ne $pword){print"Error 403...You don't have permission blah blah";exit(0);}#draw up a 403 type response

This all relies on tha fact that the variable holding $pword is in the script and hacker/cracker not knowing what it is but is mainly to prevent the form not being submitted from the site. The password changes each time the form is opened. Just a thought for later "rainy days"

Thanks again


3:49 pm on Aug 30, 2011 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member

Yeah, I understand the rationale behind the cookies, and it will most likely protect you / your users from the form not being submitted from your site. On the other hand: checking the referer will do that aswell. Yes, the referer can easily be faked by a malicious user, but you can't just put a form on a website that automatically fakes the referer when it is submitted.
While the user himself (if he is experienced enough) can fake the referer: he could just as easily build a bot that visits the form-page on your website, gets the cookie and then sends a request to the script that processes the form and send the correct cookie with it.

Btw: I did not mean to recommend HTML::Template. I've used it, and I think the Template Toolkit is much better, so if you're not decided yet and haven't invested time into learning any template language / syntax, I recommend TT. You should probably open a thread for that and ask for more opinions when you're ready to dive in.


11:50 pm on Aug 30, 2011 (gmt 0)

5+ Year Member

I'm sure you have already seen this one, but, for the bots....I've put a field in a form and gave it a common name like name and using css made it invisible, that is, i.e., .inv{display:none;} and in the form used that to hide the input(using a regular text input). When it gets to the form processing if just have a statement like:
if($name ne ""){&thanx;} with the thanx page being the one that says "We have recieved your information, yak blah blah.


5:54 am on Sep 4, 2011 (gmt 0)

5+ Year Member

I have a question regarding the HTML::Entities pm. At cpan in the synopsis for the module it says:

use HTML::Entities ();
my $decoded = HTML::Entities::decode($a);
my $encoded = HTML::Entities::encode($a);
my $encoded = HTML::Entities::encode_numeric($a);

I tried some different things but always getting the same results. Using this module shouldn't the html source code read the &#36; instead of displaying a $ sign after the form is submitted. I like the idea but just not sure how to use it. I tried replacing the $a with the form field variables---placing them in the arguements () spot after use HTML::Entities drew an error with the -T switch. I've been trying to find information which explains using "layman's term" on how to use the module. Is there something I'm supposed to config in the code I listed above?

Software error:

Can't locate /home/deploy/webmasterworld/code_format-v6.lib in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at decode-post-v6.lib line 27, <THREADDAT> line 8.

For help, please send mail to the webmaster (it@imninjas.com), giving this error message and the time and date of the error.