ID: 51050
User updated by: pecoes at gmail dot com
Reported By: pecoes at gmail dot com
Status: Bogus
Bug Type: Filter related
Operating System: WinXP
PHP Version: 5.3.1
New Comment:
The issue is not, what my job is.
The issue is, how difficult it is, to figure out, what my job is.
I did a bit of googling and apparently there are a number of people who
use the URL-filter incorrectly - like I did. Others give detailed
examples, how to properly test for validity, without detailing what
"validity" means. And those, who are fully aware of this filter's
pitfalls, recommend not to bother with it and use a regex instead.
This may end up as one of those things, that those in the know won't
use and those who don't know, will shoot themselves in the foot with.
Reminds me a bit of safe mode or magic quotes. It's a well-intentioned
attempt to simplify things, that makes things more complicated, because
it obscures the parts of the problem, it can't solve.
Maybe I'm operating from a sample of 1 here and so I will shut up now,
but it did fool me.
Previous Comments:
------------------------------------------------------------------------
[2010-02-15 08:29:56] degeberg@php.net
It is hardly within the scope of the manual to cover all possible
attack vectors. http://php.net/security.variables
already states a
number of things you should always consider when dealing with user
submitted data.
Whether or not something is "safe" is entirely circumstantial and
highly dependent on how trustworthy the user is. It's not the manual's
job to figure that out, but your job as a programmer.
------------------------------------------------------------------------
[2010-02-15 07:58:17] pecoes at gmail dot com
Yes. You're perfectly right. Forget that last suggestion. But I still
think, it would be helpful to clearly state in the documentation, that
valid != safe.
------------------------------------------------------------------------
[2010-02-15 07:52:06] rasmus@php.net
But that wouldn't make it safe and as such would be worse than the
current state because people would think it was. It takes more than
just filtering out or encoding certain characters to make a user-
supplied URL safe for direct display. Generally you need to apply some
application-level logic to determine which domains and which primitives
are valid. For example: javascript:alert(1) is a perfectly valid URL
that has no special characters in it. Or file:/// can also cause
problems. Even http://localhost/ can cause issues. There is a long
list of things that can be problematic if you allow users to supply
entire URLs. Usually all you want to accept from users are url
fragments and you prepend the primitive and base domain and path.
------------------------------------------------------------------------
[2010-02-15 07:39:45] pecoes at gmail dot com
Personally, I don't like sanitizing. I prefer to either accept or
reject. I don't think modifying a user's input is a good idea.
How about adding an optional FILTER_FLAG_ALLOW_SPECIAL_CHARS to
FILTER_VALIDATE_URL?
Or an optional FILTER_FLAG_DISALLOW_SPECIAL_CHARS, if that's what you
prefer...
Because, you know, using URLs in an HTML context is not such an exotic
scenario. :0)
------------------------------------------------------------------------
[2010-02-15 07:26:07] rasmus@php.net
What you are after is a filter for the html-context. There is nothing
wrong with your URL. You only have an issue with it if you use it in
an HTML context. It is your target context you should be filtering
for. The URL sanitizer is very explicitly documented as:
Remove all characters except letters, digits and $-
_.+!*'(),{}|\\^~[]`<>#%";/?:@&=.
Have a look through:
http://php.net/manual/en/filter.filters.sanitize.php
What you are looking for is FILTER_SANITIZE_SPECIAL_CHARS
------------------------------------------------------------------------
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
http://bugs.php.net/51050--
Edit this bug report at http://bugs.php.net/?id=51050&edit=1