Hi all,
This RFC for improving HTML escape by confirming OWASP recommendation.
PCI DSS suggests to follow their guidelines.
https://wiki.php.net/rfc/secure-html-escape
It makes escape OWASP recommended chars always.
It simplifies coding a little, too.
Thank you for voting!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
This RFC for improving HTML escape by confirming OWASP recommendation.
PCI DSS suggests to follow their guidelines.https://wiki.php.net/rfc/secure-html-escape
It makes escape OWASP recommended chars always.
It simplifies coding a little, too.Thank you for voting!
I see the point to change the default value, but I don't think PHP
should ignore the flags requesting a specific behavior.
Hi Angel,
I see the point to change the default value, but I don't think PHP should
ignore the flags requesting a specific behavior.
It's better to escape all chars always. IMHO. It's safer. Code will be a
little simpler, too.
However, it is understandable. We have
-
ENT_NOQUOTES(skip escaping quotes - this is NOT deprecated) -
ENT_COMPAT(escape only " - deprecation is proposed) -
ENT_QUOTES(escape " and ' - deprecation is proposed)
Deprecation can be dropped and it's possible to honor all of these. I
proposed deprecation since I could not think of use case other than test
program compatibility. Are there use cases?
I don't mind adding
- ENT_SINGLE(escape only ')
- ENT_DOUBLE(escape only ". Same as ENT_COMPAT, but better name)
as HTML5 supports ", ' and no quotes for attributes. It seems good for
completeness. This would be issue for new RFC, though. I may write new RFC
for this when this is over if many of think this is better to have.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi All,
I don't mind adding
- ENT_SINGLE(escape only ')
- ENT_DOUBLE(escape only ". Same as ENT_COMPAT, but better name)
as HTML5 supports ", ' and no quotes for attributes. It seems good for
completeness. This would be issue for new RFC, though. I may write new RFC
for this when this is over if many of think this is better to have.
Correction.
To control escape fully, we need
- ENT_SINGLE(escape only ' )
- ENT_DOUBLE(escape only ". Same as ENT_COMPAT, but better name)
- ENT_AMP(escape only & )
- ENT_SEMI_COLON(escape only ; )
- ENT_SLASH(escape only / )
It seems too much...
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
I don't mind adding
- ENT_SINGLE(escape only ')
- ENT_DOUBLE(escape only ". Same as ENT_COMPAT, but better name)
as HTML5 supports ", ' and no quotes for attributes. It seems good for
completeness. This would be issue for new RFC, though. I may write new RFC
for this when this is over if many of think this is better to have.Correction.
To control escape fully, we need
- ENT_SINGLE(escape only ' )
- ENT_DOUBLE(escape only ". Same as ENT_COMPAT, but better name)
- ENT_AMP(escape only & )
- ENT_SEMI_COLON(escape only ; )
- ENT_SLASH(escape only / )
It seems too much...
Yasuo
I think the problem here is that there is not a single 'good' answer here? If
there was a single combination that worked for everything then there would not
be a problem, but some legacy installations will be broken by htmlspecialchars()
and htmlspecialchars_decode() now returning different results? Some changes were
only introduced in 5.4.0 and need to be assimilated to allow further changes to
happen cleanly?
--
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
Hi Lester,
Yasuo Ohgaki wrote:
I don't mind adding
- ENT_SINGLE(escape only ')
- ENT_DOUBLE(escape only ". Same as ENT_COMPAT, but better name)
as HTML5 supports ", ' and no quotes for attributes. It seems good for
completeness. This would be issue for new RFC, though. I may write new
RFC
for this when this is over if many of think this is better to have.Correction.
To control escape fully, we need
- ENT_SINGLE(escape only ' )
- ENT_DOUBLE(escape only ". Same as ENT_COMPAT, but better name)
- ENT_AMP(escape only & )
- ENT_SEMI_COLON(escape only ; )
- ENT_SLASH(escape only / )
It seems too much...
Yasuo
I think the problem here is that there is not a single 'good' answer here?
If there was a single combination that worked for everything then there
would not be a problem, but some legacy installations will be broken by
htmlspecialchars()andhtmlspecialchars_decode()now returning different
results? Some changes were only introduced in 5.4.0 and need to be
assimilated to allow further changes to happen cleanly?
Decoding should be a problem, but I'll be careful about it.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
This RFC for improving HTML escape by confirming OWASP recommendation.
PCI DSS suggests to follow their guidelines.https://wiki.php.net/rfc/secure-html-escape
It makes escape OWASP recommended chars always.
It simplifies coding a little, too.Thank you for voting!
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I've updated the voting end date to today from 22th, as the minimum voting
period required by the voting RFC is one week.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi all,
This RFC for improving HTML escape by confirming OWASP recommendation.
PCI DSS suggests to follow their guidelines.https://wiki.php.net/rfc/secure-html-escape
It makes escape OWASP recommended chars always.
It simplifies coding a little, too.Thank you for voting!
--
Yasuo Ohgaki
yohgaki@ohgaki.netI've updated the voting end date to today from 22th, as the minimum voting
period required by the voting RFC is one week.
Is this vote still in-progress? The end date, mentioned on the RFC page,
for voting has been and gone.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi Peter,
On Mon, Mar 3, 2014 at 7:57 PM, Peter Cowburn petercowburn@gmail.comwrote:
Is this vote still in-progress? The end date, mentioned on the RFC page,
for voting has been and gone.
I was too busy. It's closed and declined 4 vs 10.
I'll create new RFC just make ENT_QUOTES the default.
Escape functions should work safely by default. IMHO.
Is RFC needed for this?
It's too trivial.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net