[ic] turn off error loggin for specific MySQL query (Form Security)

[Paul Jordan]

> Paul replied to Jeff:
> > Thanks Jeff
> >
> > I am glad you brought this up becuase I have been wanting
> to audit my
> > site for some time. Does this seem satisfactory (in example)?
> >
> >     [cgi name=n_name filter="textarea_put entities"]
> >
> > I also set my inputs to the bare minumum maxlenght. The ones in the
> > above are all < 20.
> >
> > Thanks in advance
> >
> > Paul
>
> You might wish to tailor your filters a bit.  I could be
> wrong here, but
> those filters might do more than you wish.  That is, do you
> really want
> & encoded if someone enters "John & Mary" for a first name?  (That's
> assuming n_name is not part of a URL or whatever.)  Also, textarea_put
> looks like it encodes quite a few characters.
>
> If you find that those are indeed encoding things more than you wish,
> and some combination of the many supplied filters isn't doing
> it for you,
> consider building your own filter.  You can add your own entry to the
> ~interch/code/Filter directory.  Perhaps:
>
> CodeDef whateverfiltername Filter
> CodeDef whateverfiltername Routine <<EOR
> sub {
>         my $val = shift;
>         $val =~ s/([\\'"?%])/\\$1/g;
>         return $val;
> }
> EOR
>
> If it's mainly just SQL queries for which you are filtering,
> the quotes
> are most important, but adding % to that could be helpful if the cgi
> variable goes into a query which uses LIKE.
> There is a built-in filter definition (see Interpolate.pm or
> ictags.txt) called 'sql',
> which just handles single-quotes.
>
> If you are building queries in Perl, either use placeholders
> ( blah = ? )
> or dbh->quote() to help protect your queries.
>
> An alternate method of designating filtering is with:
>     Filter cgivar "filter1 filter2 ..."
> in catalog.cfg.  For instance:
>     Filter n_name "strip 20 whateverfiltername"
>
> IMO, the nice thing about that approach is that you're covered if you
> forget to use [filter] in a page (you don't need both).

Thanks for this John,


I have learned alot from this. I actually don't care for most special
characters so I made my own filter. I was almost tempted to ONLY leave
letters and digits, but I came to this median:

CodeDef mb_rip Filter
CodeDef mb_rip Routine <<EOR
sub {
   my $val = shift;
   $val =~ s/(['"?%\\])//g;
   $val =~ s/\n/\\n/g;
   $val =~ s/\s+//g;
   $val;
}
EOR

This will strip OUT harmful characters, some special characters and
spaces. This should cover me. The user should only really be typing in
some sort of word, word/like name anyways.

As I was sprinkling these filters around I came to the conclusion that I
should filter ALL [cgi foo] within the [query] it self... is this
correct?

I not only have user enter data [cgi foo] that obviously could be
harmful, but I also have [cgi foo2] which maybe a value from a <select>
box. So, even though I have control of those [cgi] values, I get the
impression that a hacker can "override" my <select> box generated
cgi's?? and circumvent the value, thus pretty much making all [cgi
foo]'s within a query suspect.

I have also learned that using WHERE username = '[data session
username]' should also be filtered, I suppose because a hacker could
somehow fake-post an altered username??

I guess you can tell I am new to this :) I really was not aware of the
'reach' a hacker has via forms. I read the latest OpenHack results, and
once again the most vulnerable was the web application FORMS.

Ahh well, I hope this thread helps others someday, as it probably saved
me a lot of future grief :)

Thanks

Paul