On Sun, Jun 19, 2016 at 8:30 PM, Walter Parker <walt...@gmail.com> wrote:
> Good, then we do agree, as what I said was what I DID NOT want to see in > the documentation. > > This should be documented as shortcut for <? echo htmlspecialchars(string) > ?>. It should be further pointed out that while this will be useful in > catching many XSS and other HTML issues, it will not catch all of them, so > care and attention to proper data hygiene is still required. > > > Walter > > On Sun, Jun 19, 2016 at 8:22 PM, Михаил Востриков < > michael.vostri...@gmail.com> wrote: > > > > "Use '<?~' and it will solve your XSS and other escaping problems with > > outputting HTML that was stored in a DB." > > I don't think this is a good phrase for documentation. This form should > be > > considered exactly as htmlspecialchars, with taking into account any > > language and encoding-specific issues, and this should be pointed in > > documentation. This is a shorcut for often operation, like '??' for > isset() > > check. And it can really improve security, not in 90% but about 99.9999% > > cases. > > > > 2016-06-20 4:41 GMT+05:00 Walter Parker <walt...@gmail.com>: > > > >> > >>> > >>> > 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()? > >>> > >>> What could happen is this getting sold/documented as a general purpose > >> security feature: > >> "Use '<?~' and it will solve your XSS and other escaping problems with > >> outputting HTML that was stored in a DB." What it solves is a subset, > >> which is escaping characters stored in a data that have special > meanings to > >> HTML. My concern is that the remain security issues might get > overlooked or > >> ignored because '<?~' is considered good enough. There are issues with > >> htmlspecialchars, UTF-8 and certain language-specific characters (non > >> English). There were also issues with quotes in the past. > >> > There will never be a way to make this operator useful to a majority of users or use cases; similar ideas have been discussed many times in the past. If we get annotations then you might be able to hook something in from userland transparently that understands your specific context and application. This would be much more feasible IMO. - Davey
