Re: isset question

How does echoing back to the page make it vulnerable? This does not go to a DB if that makes any difference. Gary "Paul M Foster" <paulf@quillandmouse.com> wrote in message news:20090621032151.GB14822@quillandmouse.com... > On Sat, Jun 20, 2009 at 12:20:56PM +0100, Ashley Sheridan wrote: > >> On Sat, 2009-06-20 at 00:19 -0400, Paul M Foster wrote: >> > On Fri, Jun 19, 2009 at 07:52:40PM +0100, Ashley Sheridan wrote: >> > >> > > On Fri, 2009-06-19 at 12:36 +0100, Ford, Mike wrote: >> > > > On 18 June 2009 20:25, LAMP advised: >> > > > >> > > > > using !empty() instead isset() will work if you don't care for >> > > > > PHP >> > > > > Notice: Undefined variable... If you want to avoid PHP Notice >> > > > > you have >> > > > > to use both: >> > > > > >> > > > > $msg.= (isset($_POST['mort']) and >> > > > > !empty($_POST['mort'])) ? "The >> > > > > mortgage amount is $mort\n" : " "; >> > > > >> > > > Absolute rubbish -- as it says at >> > > > http://php.net/empty, >> > > > "empty($var) is >> > > > the opposite of (boolean)$var, except that no warning is generated >> > > > when >> > > > the variable is not set." -- so "protecting" empty() with an >> > > > isset() is >> > > > a total waste of time, space and cpu cycles. >> > >> > <snip> >> > >> > > > >> > > To be honest, you're still opening yourself up to attack that way. >> > >> > Why and how? >> > >> > Paul >> > >> > -- >> > Paul M. Foster >> > >> I've only done a little reading on this, but you're opening yourself up >> to a XSS attack. If someone posted '<script>//malicious code >> here</script>' to your PHP script, you'd essentially be printing that >> right back out onto your page. > > I see. You're not talking about being vulnerable because of isset/empty, > but by echoing it back to the page. Yes, I agree there. You have to > sanitize it first. > > Paul > > -- > Paul M. Foster