Case Sensitive Regex
Robert
I am trying to secure my mailer script from those who might try to hijack it
by adding "To:" etc fields in the form fields.
Currently I am using this:
my $name = param('name');
if ($name =~ /To:/) { &spamattempt; }
if ($name =~ /to:/) { &spamattempt; }
Basically if the "name" fields contains either an upper or lower case To or
to the script will direct to a subroutine where the process is terminated.
This all works fine. My Question ... is there an easier way to write the
regex above that looks for To:/to: etc? I was thinking maybe it could be
done with a single regex where is searches for either an upper or lower case
T or O followed by a : I did some research on regex case sensitivity and
found that the "i" operator is needed but couldn't make it work. Thanx all
in advance.
Robert
Robert
news:SI05f.228445$tl2.1110@pd7tw3no...
>
> Basically if the "name" fields contains either an upper or lower case To
or
> to the script will direct to a subroutine where the process is terminated.
> This all works fine. My Question ... is there an easier way to write the
> regex above that looks for To:/to: etc? I was thinking maybe it could be
> done with a single regex where is searches for either an upper or lower
case
> T or O followed by a : I did some research on regex case sensitivity and
> found that the "i" operator is needed but couldn't make it work. Thanx all
> in advance.
Year ok, I feel stupid:
if ($name =~ /To:/i) { &spamattempt; }
Robert
Gunnar Hjalmarsson
How could you not make it work? Please post a short but complete script,
that people can copy and run, and that illustrates the issue.
( /to:/i should do what you want. )
OTOH, I'd think that a simpler and safer way to prevent that kind of
abuse is to ensure that none of the email header fields includes linebreaks.
$name =~ s/\s+/ /g;
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
John Bokma
> Hello,
>
> I am trying to secure my mailer script from those who might try to
> hijack it by adding "To:" etc fields in the form fields.
Much better is to define what exactly is allowed v.s. to think up bad
cases, and check for those.
> Currently I am using this:
>
> my $name = param('name');
> if ($name =~ /To:/) { &spamattempt; }
> if ($name =~ /to:/) { &spamattempt; }
Why do you use & in front of the sub?
--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
I ploink googlegroups.com :-)
Dave Weaver
Normally you call subroutines like this:
spamattempt();
Using the '&' on a subroute call has side effects that, if you don't
know what they are, you don't want.
Your whole line is, IMHO, better written as:
spamattempt() if $name =~ /To:/i;
John Bokma
Gunnar Hjalmarsson
> "Robert" <rbutche...@hotmail.com> wrote:
>>I am trying to secure my mailer script from those who might try to
>>hijack it by adding "To:" etc fields in the form fields.
>
> Much better is to define what exactly is allowed v.s. to think up bad
> cases, and check for those.
Sometimes that's better.
As regards a name field: Don't think so.
Brian Wakem
Case insensitive regexs are very slow. I try to use index where
possible, with a case modifier, which when I last did some benching on
this issue was 6 times faster than a regex on my test machine IIRC.
spamattempt() if (index(lc $name, 'to:') != -1);
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
Joe Smith
>> if ($name =~ /To:/) { &spamattempt; }
>
> Case insensitive regexs are very slow. I try to use index where
> possible, with a case modifier, which when I last did some benching on
> this issue was 6 times faster than a regex on my test machine IIRC.
>
> spamattempt() if (index(lc $name, 'to:') != -1);
A floating regex can be slow, but I expect the anchored regex
if ($name =~ /^To:/i) { spamattempt(); }
to be on par with index().
-Joe
John Bokma
> John Bokma wrote:
>> "Robert" <rbutche...@hotmail.com> wrote:
>>>I am trying to secure my mailer script from those who might try to
>>>hijack it by adding "To:" etc fields in the form fields.
>>
>> Much better is to define what exactly is allowed v.s. to think up bad
>> cases, and check for those.
>
> Sometimes that's better.
>
> As regards a name field: Don't think so.
I think it's not that hard to come up with a nice definition of what is
allowed in a name, even when unicode is allowed. It's a bit harder if
handles/nicks, etc are allowed, since then stuff like 733+h@><0r could be a
"name", but even then :-)
Gunnar Hjalmarsson
> Gunnar Hjalmarsson wrote:
>>John Bokma wrote:
>>>Much better is to define what exactly is allowed v.s. to think up bad
>>>cases, and check for those.
>>
>>Sometimes that's better.
>>
>>As regards a name field: Don't think so.
>
> I think it's not that hard to come up with a nice definition of what is
> allowed in a name, even when unicode is allowed. It's a bit harder if
> handles/nicks, etc are allowed, since then stuff like 733+h@><0r could be a
> "name", but even then :-)
Even if it would be _possible_, how on earth could it be _better_ if the
purpose is to prevent abusers from adding extra mail headers?
See http://groups.google.com/group/comp.lang.perl.misc/msg/02a2892e2f4705ef
John Bokma
>> I think it's not that hard to come up with a nice definition of what
>> is allowed in a name, even when unicode is allowed. It's a bit harder
>> if handles/nicks, etc are allowed, since then stuff like 733+h@><0r
>> could be a "name", but even then :-)
>
> Even if it would be _possible_, how on earth could it be _better_ if
> the purpose is to prevent abusers from adding extra mail headers?
Even if all possible exploits is a subset of all invalid names, I would
prefer to deny all invalid names over all possible exploits.
Tad McClellan
> I am trying to secure my mailer script
Then you should have taint checking turned on.
perldoc perlsec
--
Tad McClellan SGML consulting
ta...@augustmail.com Perl programming
Fort Worth, Texas