Re: New escaped output operator

2016-06-20 11:12 GMT+02:00 Lester Caine <lester@lsces.co.uk>: > On 20/06/16 07:00, Niklas Keller wrote: > >> Now ... I want to add content that includes > >> > <script>alert("xss")</script> it needs to be in the format > >> > &lt;script&gt;alert(&quot;xss&quot;)&lt;script&gt; so > >> > that it never > >> > appears in the 'dangerous' format, but if $user['about_me'] > >> > is > >> > designated a simple text string, then any attempt to add > >> > <script>alert("xss")</script> via an input should be > >> > blocked! > > > > No, it shouldn't be blocked. It should just be escaped on output. What if > > that's a comment to a tech blog, where we talk about these things instead > > of trying to find a vulnerability? > > Re-read what I wrote! > I read it and I fundamentally disagree with that. > You should ALWAYS sanitise simple text such as short descriptions, and > even user names and other simple text fields and I would always do that > with strings like $user['about_me'] ... > '<?~' creates a false sense of > security You're right. But it's the case because it doesn't obey the output context. It's not because it escapes on outpu > when users should be educated as to the risks that NOT > validating data can create. Such as overflowing field sizes and creating > text which internally can cause problem even before outputting to a > browser Data validation is a totally different topic and not what this thread is about. > such as quotes in combined strings. > Where's that an issue? > ( Rowan sums up the output side nicely ... ) > >