Hi Stas,
On Mon, Feb 3, 2014 at 5:17 PM, Stas Malyshev <[email protected]>wrote:
> > Users can do
> >
> > <tag attr='<?php echo htmlentities($str)?>' >
>
> They also can do <? echo $str; ?> and <? eval($_GET['f']); ?>.
> That's
> not what they _should_ be doing, but they _can_ do it. That doesn't mean
> there's something wrong with echo or PHP compiler.
>
> > and this is valid. I think there is no reason not to escape ' by default.
> >
> > I agree that user should not use unquoted attributes in general.
> >
> > '/' escape could be still useful. For example, user may have validation
>
> I don't see how it would be useful.
>
> > code that allows printable ASCII chars w/o spaces. '/' escape may protect
> > apps from generating invalid tag in this case.
>
> This seems to be a very contrives scenario invented to fit your point.
> If they already pre-filter input, they could also remove / or other
> special characters. The fact is that htmlentities is useless as security
> feature in this context, and removing / does not make it useful. Saying
> "we'll add escape so that it would be safe" is magic-quotes kind of
> mistake - it gives the users wrong impression that it's OK to do things
> that they should not be doing.
>
> > There is no reason not to escape these chars by default. IMHO.
>
> There is a reason - there's no reason to escape them. In every scenario
> that htmlentites should be used, escaping them is useless. In every
> scenario where espacing / is useful, htmlentities should not be used. By
> promoting usage of htmlentities in scenarios where it should absolutely
> not be used, we are only doing the users a disservice.
I think we have different perspectives.
Some users has to confirm standard like PCI DSS.
PCI DSS requires to follow security standards and guidelines from OWASP,
SANS, etc.
Why not make PHP standard compliant?
It does not hart existing applications at all and this is simple enough
change.
Regards,
--
Yasuo Ohgaki
[email protected]