script attack

[Alexandre Jaquet]

Hi

I found an very interesting article at
http://groups.google.com/group/Soft...l+sql+injection&rnum=8&hl=en#9b4d0ce0070fa2a4

and would like to use the regex described

but how to use it if I have for exemple :

local our $article = $query->param ('search_name');
if ($article =~ /((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|()/i) {
$article = '*';
}
doesn't work

any help thanks

 

[xhoster]

doesn't work

Worst Description Ever.

Xho

 

[Eric Schwartz]

I found an very interesting article at
http://groups.google.com/group/Soft...l+sql+injection&rnum=8&hl=en#9b4d0ce0070fa2a4

and would like to use the regex described

A) You should explain what the regex is for those of us who don't care to
read the referenced article.
B) There are 8 specifically cited regexes in that article, and several
more mentioned inline with the paragraphs. Please specify *which*
one.
C) You need to tell us *why* you want to use the regex you want to
use, what that regex is supposed to accomplish, and ideally why you
think it should accomplish that.

but how to use it if I have for exemple :

local our $article = $query->param ('search_name');

Okay, whoah, stop right there. I think, if prompted by sufficient
quantities of tequila, I could come up with a justification for
declaring a variable with 'local' AND 'our', but I'd have to work very
hard to do so, and even then I doubt I'd believe myself. If you don't
have a very good reason for doing that, I'd stick with 'our', or
preferably 'my'.

if ($article =~ /((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|()/i) {
$article = '*';
}
doesn't work

"doesn't work" is completely useless when describing a problem. You
need to create a short program that:

* Defines $article so that we can see, at a glance, what its contents
are.
* Explains what the regex is supposed to do
* Shows what the regex actually does, and most importantly:
* How that differs from what you expect.

We are not mind-readers. We don't know, unless you tell us, what your
data looks like.

any help thanks

CLPM helps those who help us help them. (are you confused yet?

-=Eric

 

[Brian Wakem]

Eric Schwartz wrote:

Okay, whoah, stop right there. I think, if prompted by sufficient
quantities of tequila, I could come up with a justification for
declaring a variable with 'local' AND 'our', but I'd have to work very
hard to do so, and even then I doubt I'd believe myself. If you don't
have a very good reason for doing that, I'd stick with 'our', or
preferably 'my'.

'local our' is common use in mod_perl.

http://perl.apache.org/docs/1.0/guide/porting.html#The_First_Mystery

 

[Eric Schwartz]

'local our' is common use in mod_perl.

http://perl.apache.org/docs/1.0/guide/porting.html#The_First_Mystery

Okay, fair enough; all the mod_perl I've done has been with Mason,
which hides all that with the MasonAllowGlobals Apache directive.
Even so, I look at those examples, and think, "You know, if they just
passed variables around, instead of using globals, they wouldn't need
'local our' at all."

But thanks for the correction; if I find myself using mod_perl with
other templating engines, I will remember that.

-=Eric

 

[Brian Wakem]

Okay, fair enough; all the mod_perl I've done has been with Mason,
which hides all that with the MasonAllowGlobals Apache directive.
Even so, I look at those examples, and think, "You know, if they just
passed variables around, instead of using globals, they wouldn't need
'local our' at all."

Yes it's best put to use when porting a load of existing mod_cgi scripts to
mod_perl. Wacking a load of 'local our's in can save hours, and time is
money.

Even so, a global my (and many scripts will have one) will not be shared
correctly between subs, so you use our, but in mod_perl it will hold on to
the memory it used after the script has finished. local our therefore
helps keep memory usage down.

 

[Benjamin Franz]

Okay, fair enough; all the mod_perl I've done has been with Mason,
which hides all that with the MasonAllowGlobals Apache directive.
Even so, I look at those examples, and think, "You know, if they just
passed variables around, instead of using globals, they wouldn't need
'local our' at all."

But thanks for the correction; if I find myself using mod_perl with
other templating engines, I will remember that.

I'd have to agree. I've been using mod_perl for several years and
never needed 'local our' because I'm adverse to using globals
for any case that I don't have to use them. And there just
aren't a lot of times you _have_ to use them.

I was also startled by the porting guide's comment about seeing so
many warnings that they couldn't tell which ones were important and
which ones weren't: Warnings are nearly always important. If your
code _normally_ outputs tons of warnings, you have a serious
problem and very likely a number of outright bugs.

If you _must_ to do something that generates warnings, turn them
off in a scoped block so you don't have warnings about something
that is intended and understood behavior. I've found that fixing
warnings has a very close relationship to fixing bugs in general.