Edit report at https://bugs.php.net/bug.php?id=61354&edit=1
ID: 61354
Comment by: jbolder42 at yahoo dot com
Reported by: hufeng1987 at gmail dot com
Summary: htmlentities and htmlspecialchars doesn't respect
the default_charset
Status: Not a bug
Type: Bug
Package: Strings related
Operating System: Linux/Windows/
PHP Version: 5.4.0
Block user comment: N
Private report: N
New Comment:
I was wondering if someone could enlighten me by explaining why this:
htmlspecialchars($str, ENT_QUOTES, "ISO-8859-1");
... would be considered any more secure than something like this:
ini_set("html.default_charset", "ISO-8859-1");
htmlspecialchars($str, ENT_QUOTES);
Thank you!
Previous Comments:
------------------------------------------------------------------------
[2013-06-15 22:22:58] unvetted at gmx dot com
QUOTES:
[2013-01-05 04:20 UTC] [email protected]
You will need to update your code to be compatible with PHP 5.4 either by
explicitly providing the charset, or by passing in "" to pick up the default
one. Anything short of that is a security issue. Code that didn't do this in
PHP 5.3 is potentially insecure depending on which charset is being used, so
no, nothing will be fixed here. We will not revert to 5.3 behaviour.
[2013-01-05 04:40 UTC] [email protected]
Code that is currently likely to be insecure, yes. We only make changes like
this when we are forced to for security reasons.
[2013-01-05 15:17 UTC] [email protected]
I have explained that a few times. We can't default it automatically because
the encoding may not match the output encoding. Only the developer knows that.
If we did that automatically it would break even more sites. The sites where
the encodings differ need to set it explicitly.
===End QUOTES!
"It's not a bug; it's by design." ROFL. Yea, bad design. More specifically,
a really bad decision showing lack of foresight.
I think [email protected] and team made a big booboo, didn't realize it, started
off saying it's not a bug, realized how bad a booboo it was, and then started
making justification excuses concerning security to try to cover-up the mistake.
So, you make such in important default behavior change, don't document it with
emphasis in the upgrade, and don't provide a mechanism(i.e. config option) to
keep it as it was. That's some serious lack of planning.
The interesting part of it is the lack of character displayed by those who
continue to deny and defend the decision, instead of fixing it to give the
option of legacy code to run unmodified. I had to laugh as Rasmus kept trying
to justify such a moronic decision as being necessary for "security reasons."
I hope the PHP team finally learns their lesson on this one. Before any
default change is ever done to a firmly established method, there should always
be a config option to override it to allow code to run unmodified if desired.
That's just common sense in an old programming world.
Egos, stubborn natures, fear of making mistakes...it just gets in the way of
progress. Just admit the booboo, fix it and move on. Please. Thank you.
------------------------------------------------------------------------
[2013-05-20 18:14:25] kstirn at gmail dot com
@minder at ufive dot unibe dot ch
Yes, this can be done, but still means we would have to manually modify
hundreds of legacy scripts on the server (many third party and many
obfuscated/encoded) to be able to upgrade to PHP 5.4.
It would be really easy to fix with an ini setting and it would indeed make
sense to have a setting for such a huge default change. I am disappointed that
the PHP dev team has decided to completely ignore the issue.
------------------------------------------------------------------------
[2013-05-19 13:10:13] minder at ufive dot unibe dot ch
For legacy projects in latin1 we substitute htmlspecialchars with the self-made
function htmlXspecialchars according to these instructions:
http://ufive.unibe.ch/?c=php54entitiesfix&q=&l=e
------------------------------------------------------------------------
[2013-02-26 21:29:02] rudibr at gmail dot com
What about my third-party modules? Should I change their code as well? Do I now
need to verify and manually alter code on third-party modules everytime I
upgrade or install them?
If Im using a component with protected code, do I need to go trough their
support staff and wait for a correction? What if they provide no reliable
support or customization, am I now being encouraged to hack and crack in the
source code just so I can fix this?
It is easy , even redundant , and absolutely justfiable to create a new ini
setting to control this behavior, that I feel a little bit offended by the
current attitude of php developers over this issue.
I also feel a little bit offended because the guy who is responsible for this
change EXPLICITLY stated that the change to UTF-8 defaulting have nothing to do
with security. It just sounded like a "better default", according to the
developer. Hardly a seriously thought-trough consideration.
This is becoming quite a sad state of affairs. I guess I will have to consider
moving on from php if it comes to that.
------------------------------------------------------------------------
[2013-01-27 17:32:18] kstirn at gmail dot com
It will soon be a year since the release of PHP 5.4 and there still is no easy
way (read: a global PHP setting) to overcome this huge
backwards-incompatibility.
PHP developers, I understand the security concerns, but please don't be so
stubborn and give us an option to set a default setting without having to
modify *all* legacy code to work with 5.4.
Your action (or lack thereof) is producing the opposite results of desired -
instead of moving to PHP 5.4, thousands of servers (including several we own)
will stay with 5.3.x even after end of life cycle in March 2013.
*Fact*
A simple global setting (an optional php.ini value) would solve the issue for
thousands of users while addressing security issues by explicitly defining the
default charset to be used by affected functions - all without having to
rewrite existing code.
PHP team please do reconsider this and help everyone not using UTF-8 move to
PHP 5.4.
Thank you!
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61354
--
Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
