script attack

Discussion in 'Perl Misc' started by Alexandre Jaquet, Sep 9, 2005.

  1. Alexandre Jaquet, Sep 9, 2005
    #1
    1. Advertising

  2. Alexandre Jaquet

    Guest

    Alexandre Jaquet <""alexjaquet\"@[no spam]msn.com"> wrote:
    ....

    > doesn't work


    Worst Description Ever.

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Sep 9, 2005
    #2
    1. Advertising

  3. Alexandre Jaquet <""alexjaquet\"@[no spam]msn.com"> writes:
    > 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
     
    Eric Schwartz, Sep 9, 2005
    #3
  4. Alexandre Jaquet

    Brian Wakem Guest

    Eric Schwartz wrote:


    >> 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'.



    'local our' is common use in mod_perl.

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



    --
    Brian Wakem
    Email: http://homepage.ntlworld.com/b.wakem/myemail.png
     
    Brian Wakem, Sep 9, 2005
    #4
  5. Brian Wakem <> writes:
    > '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
     
    Eric Schwartz, Sep 9, 2005
    #5
  6. Alexandre Jaquet

    Brian Wakem Guest

    Eric Schwartz wrote:

    > Brian Wakem <> writes:
    >> '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."



    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.



    --
    Brian Wakem
    Email: http://homepage.ntlworld.com/b.wakem/myemail.png
     
    Brian Wakem, Sep 9, 2005
    #6
  7. On Fri, 09 Sep 2005 13:09:53 -0600, Eric Schwartz wrote:

    > Brian Wakem <> writes:
    >> '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.


    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.

    --
    Benjamin Franz
     
    Benjamin Franz, Sep 12, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Onur Bozkurt

    Attack a page to a mail

    Onur Bozkurt, Jun 30, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    448
    Onur Bozkurt
    Jun 30, 2003
  2. Sati
    Replies:
    6
    Views:
    417
    Dino Chiesa [Microsoft]
    Nov 19, 2003
  3. sati
    Replies:
    1
    Views:
    423
    Chris Jackson
    Nov 18, 2003
  4. TCORDON

    Injection Attack

    TCORDON, May 24, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    502
    Steve C. Orr [MVP, MCSD]
    May 25, 2005
  5. vMike
    Replies:
    7
    Views:
    592
    Hans Kesting
    Sep 14, 2005
Loading...

Share This Page