On Wed, Mar 4, 2009 at 6:27 PM, Eric Butera <eric.butera@xxxxxxxxx> wrote:
> On Wed, Mar 4, 2009 at 8:54 PM, Michael A. Peters <mpeters@xxxxxxx> wrote:
> > Eric Butera wrote:
> >
> >>
> >> So here's some examples of bad behavior.
> >>
> >> = Database =
> >> Bad:
> >> $name = mysql_real_escape_string($_POST['name'], $link);
> >> myql_query("INSERT INTO foo (`name`) VALUES ('". $name ."')");
> >>
> >> $name now contains slashes which means it is corrupt and not able to
> >> be echo'd without a stripslashes. You should never have to call
> >> stripslashes. If you do, you're doing it wrong.
> >
> > No, you are not doing it wrong.
> > You are just doing it a different way.
> > It's a lot easier to audit your code if you clean the input when you eat
> the
> > POST.
> >
> > You should never echo a variable you haven't cleaned anyway because of
> > reflection attacks. Clean it at input and you when auditing you code, you
> > look for _POST and make sure you set the variable you use to the output
> of
> > running the _POST through your filter.
> >
> > As far as having "Bill O\'Really" in your output, that doesn't happen if
> you
> > get your output from the database that "Bill O'Really" was inserted into,
> as
> > the escape has already served its purpose.
> >
>
> Good luck with that.
>
> --
> http://www.voom.me | EFnet: #voom
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Is it really THAT hard to take the extra step, ensure proper application
security and filter both ways? I didn't think so.
Kyle Terry | www.kyleterry.com
Help kick start VOOM (Very Open Object Model) for a library of PHP classes.
http://www.voom.me | IRC EFNet #voom
