>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:
>
> > On 19/06/16 10:01, Marco Pivetta wrote:
> > > This basically means that you lack basic understanding of how escaping
> > and
> > > user input are to be handled.
> > > Most apps out there about getting a bunch of text from the user, then
> > > rendering it somewhere else in the app.
> > > Cleaning user input just leads to frustration and a big mess in most
> > > scenarios, which is why we're all talking about escaping output
> instead.
> > > This is not "cleaning" either, it's escaping, which is a
> non-destructive
> > > and reversible operation (which is why it works so well).
> >
> > 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
