> e.g. it won't protect you from XSS if you ever place user-controlled data
in HTML attributes.
As I've found, such an XSS can have a place in the code like this:
$xss = "');your_code_here();//";
<div onmouseover="alert('<?php echo htmlspecialchars($xss, ENT_QUOTES,
'UTF-8') ?>')">
I think this is more architectural problem, not an escaping problem. This
is very special case when we really need it.
> If you are in a HTML context you need different escaping than you need in
a CSS or JS block.
For JS it's better to use json_encode(). And I've never met CSS+PHP output,
this is some special case.
> would be misleading people into thinking this operator is generic and can
be used in all contexts safely.
I don't think that many programmers can think so. Anyway, this can be
menthioned in documentation.
> The escaping should also be aware of the content encoding.
For special cases - e.g. when we use one encoding and need to output a
value in another encoding - htmlspecialchars() still can be used.
> Sure you can implement that in userland, but people don't do it or make
it too complicated,
> so you get every day code with unescaped stuff.
Yes. This is the main problem.
Almost each echo operator is an output of data from database, usually this
is an entity property if the ORM is used or an array key if isn't. I'm not
talking about fully functional escaping operator for all cases, just for
most often case - output a value into HTML document. If we have a shorcut
for "<?php echo $value; ?>" then we also need a shortcut for "<?php echo
htmlspecialchars($value, ENT_QUOTES); ?>", because PHP is a web-programming
language. I think this operator can make many projects more safer.
2016-06-18 3:32 GMT+05:00 Thomas Bley <ma...@thomasbley.de>:
> Sure you can implement that in userland, but people don't do it or make it
> too complicated,
> so you get every day code with unescaped stuff.
>
> Regards
> Thomas
>
> Ryan Pallas wrote on 18.06.2016 00:27:
>
> >
> >
> > On Fri, Jun 17, 2016 at 2:23 PM, Thomas Bley <ma...@thomasbley.de
> <mailto:ma...@thomasbley.de> > wrote:
> >> you can simply add the context to the current output operator:
> >> <?=html($str) ?>
> >> <?=attr($str) ?>
> >> <?=text($str) ?> (=strip_tags)
> >> <?=js($str) ?>
> >> <?=css($str) ?>
> >
> >
> > Look at that. Add a couple parens and its completely implementable in
> userland now with no language changes required.
> >
> >
> >> Regards
> >> Thomas
> >>
> >>
> >> Stanislav Malyshev wrote on 17.06.2016 22:14:
> >>
> >> > Hi!
> >> >
> >> >> Most of output code is an output of properties of database entities,
> and
> >> >> only in some cases it's needed to concatenate HTML into string and
> then
> >> >> print it with unescaped output. Escaped output operator can be
> useful. Also
> >> >> we output data not into the void and not into simple text file, but
> into
> >> >> HTML-document which has a certain format (markup). Also this is
> logical -
> >> >> to have both forms, escaped and unescaped.
> >> >
> >> > This has been discussed on the list a number of times. Main issue with
> >> > this kind of proposals is that escaping is context-dependent. E.g.
> >> > htmlspecialchars() would not help you in many scenarios - e.g. it
> won't
> >> > protect you from XSS if you ever place user-controlled data in HTML
> >> > attributes. Having operator for each of the possible contexts does not
> >> > really looks feasible, and having it for only one of them and not the
> >> > others would be misleading people into thinking this operator is
> generic
> >> > and can be used in all contexts safely.
> >> >
> >> > --
> >> > Stas Malyshev
> >> > smalys...@gmail.com <mailto:smalys...@gmail.com>
> >> >
> >> > --
> >> > PHP Internals - PHP Runtime Development Mailing List
> >> > To unsubscribe, visit: http://www.php.net/unsub.php <
> http://www.php.net/unsub.php>
> >> >
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php <
> http://www.php.net/unsub.php>
> >>
> >>
>
