Lester
> there is NO need to simply slap htmlspecialchars() onto
> properly built data
There are many cases when user data can contain quotes or other html
entities.
<img title="<?= $book['title'] ?>" />
// $book['title'] = 'When we say "Hello"';
<div><?= $user['about_me'] ?></div>
// $user['about_me'] = 'I am a programmer. I like to write
<script>alert("xss")</script> in "About me" field';
Walter
> where getting it 90% correct is worse that not doing anything at all.
> Things like this will cause people to be blindsided when the uncaught
escapes
> cause the next major security problem.
Why do you think so? What real problems can happen if there will be a short
operator for htmlspecialchars()?
2016-06-19 22:48 GMT+05:00 Walter Parker <walt...@gmail.com>:
> From your story Scott, it looks like the failure was bad input filtering,
> not input filtering in general. If sites are really trying to be secure,
> they should follow both Lester's and your ideas and filter on input and
> escape on output.
>
> Given your second link the better suggestion is to stop taking raw HTML.
> Assuming user generated HTML is ever safe to re-render in an output page
> has been a bad idea for years. Ebay/paypal once thought that stripping all
> letters and numbers from JavaScript was enough to make it safe, it wasn't.
> Somebody used just things like (){}[]=+ to build functional attack scripts.
>
> While a simple method of output escaping seems like a good idea, I agree
> with the others that point out that is one of those security systems where
> getting it 90% correct is worse that not doing anything at all. Things like
> this will cause people to be blindsided when the uncaught escapes cause the
> next major security problem.
>
>
> Walter
>
> On Sun, Jun 19, 2016 at 10:28 AM, Scott Arciszewski <sc...@paragonie.com>
> wrote:
>
> > On Sun, Jun 19, 2016 at 1:14 PM, Lester Caine <les...@lsces.co.uk>
> wrote:
> >
> > > Well we have to disagree ... simply expecting htmlspecialchars() to fix
> > > all your problems without proper handling of the input text is 'the big
> > > mess' and there is NO need to simply slap htmlspecialchars() onto
> > > properly built data so the idea that <?= should automatically add it is
> > > totally pointless!
> > >
> > > --
> > > Lester Caine - G8HFL
> > > -----------------------------
> > > Contact - http://lsces.co.uk/wiki/?page=contact
> > > L.S.Caine Electronic Services - http://lsces.co.uk
> > > EnquirySolve - http://enquirysolve.com/
> > > Model Engineers Digital Workshop - http://medw.co.uk
> > > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> > Let me tell you a story.
> >
> > Once upon a time, WordPress decided to escape user input to protect
> against
> > XSS attacks. Then this happened: https://klikki.fi/adv/wordpress2.html
> > (Stored XSS via MySQL Column Truncation vulnerability.)
> >
> > Escaping against XSS attacks should happen on output, not on input. Dead
> > stop.
> >
> > You MAY cache the escaped output for performance gains, but keep the
> > unescaped data in the database in case you need to adjust your escaping
> > strategy without mangling existing data.
> >
> > Further reading:
> >
> >
> https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know
> >
> >
> > Scott Arciszewski
> > Chief Development Officer
> > Paragon Initiative Enterprises <https://paragonie.com/>
> >
>
>
>
> --
> The greatest dangers to liberty lurk in insidious encroachment by men of
> zeal, well-meaning but without understanding. -- Justice Louis D.
> Brandeis
>
