Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
comment.module
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
19 Dec 2005 at 00:43 UTC
Updated:
10 Oct 2013 at 12:11 UTC
Jump to comment: Most recent file
Comments
Comment #1
killes@www.drop.org commentedcan verify this.
Comment #2
paddy_deburca commentedpatch to common.inc to include the @ sign
as in, replace
with
Comment #3
markus_petrux commentedJust wanted to point that adding the atsign, as it is the current regexp used for URL validation, might be dangerous, or at least opens up something that it was not possible.
The atsign, if entered just after the protocol (ie. part of the domain) is used to specify username:password. Sometimes this is used to fool people with crafted URLs such as:
http://www.example.com\use-a-long-enough-string-here@www.badguy.com/malware.php
Comment #4
paddy_deburca commentedI am changing the priority to Minor.
According to http://www.ietf.org/rfc/rfc1738.txt the atsign is a reserved character.
To embed the atsign in a url, a percent sign followed by the hexadecimal code should be used. Infact this URL coding standard should be enforced/required for all special characters.
So
could be replaced by
In my opinion the code, as is _without_ patch works by design and should _not_ be patched to resolve this issue.
However, the same RFC points out that there is more than a couple of potocols. The list includes
and that these protocols normally have the following schemes
To be more correct the valid_url should be compatible with this scheme. As a practical example adding mailto support would allow the weblink module to maintain e-mail addresses.
Paddy.
Comment #5
paddy_deburca commentedI have developed on the valid_url to be more compliant with the IETF RFC (http://www.ietf.org/rfc/rfc1738.txt).
The code is as follows
The resultant regular expression is
so I would be loath to simplify the code.
It works for the test cases
I will continue to test and debug.
I will provide a patch when thouroughly tested and working as expected.
Paddy.
Comment #6
paddy_deburca commentedSorry - please remove the call to watchdog().
Comment #7
chx commentedBut we have the code for this already... no need to reinvent the wheel.
Comment #8
edmund.kwok commentedChanged $path to $url in valid_url and patch works againts HEAD.
Both:
http://www.flickr.com/photos/16637594@N00/
and
http://www.flickr.com/photos/16637594%40N00/
are accepted as valid_url now.
Comment #9
chx commentedthen it's RTBC
Comment #10
edmund.kwok commentedPrevious patch was not rolled againts head. This should be final.
Comment #11
dries commentedLooking at this patch; don't we declare $allowed_characters twice?
Comment #12
chx commentedevery patch but the latest contained this line:
- $allowed_characters = '[a-z0-9\/:_\-_\.\?\$,~=#&%\+]';so yes, now we define it twice but it should not be so.
Comment #13
edmund.kwok commentedMy bad, missed out one line when rerolled. This hopefully is the final final..
Comment #14
drummThis doesn't seem to fix the actual issue, @ not being allowed.
The relevant RFC, http://www.ietf.org/rfc/rfc2396.txt ("revises and replaces" 1738) states @ is allowed in path segments.
Comment #15
edmund.kwok commentedChanged $path to $url in valid_url.
Comment #16
edmund.kwok commentedRerolled from root to latest HEAD.
Comment #17
drummpatching file includes/common.inc
Hunk #1 FAILED at 689.
Hunk #2 succeeded at 1141 with fuzz 2 (offset 121 lines).
1 out of 2 hunks FAILED -- saving rejects to file includes/common.inc.rej
I'm confused about why this isn't simply adding @ to the allowed characters list. What do all of the code changes do?
Comment #18
edmund.kwok commentedRerolled for HEAD.
From #3, just adding @ to the allowed character list might open up a security loophole. And for the whole purpose of the patch, I don't get the whole idea either; just fixing syntax errors with what chx came up with.
Comment #19
Steven commentedPhishing is not a reason to disallow valid URLs blindly. Flickr is a perfect example of legit sites using @.
Also, filter_xss_bad_protocol() does not guarantee anything other than the protocol. We should still at least validate the characters in absolute URLs to ensure at least a high degree of URL validity.
Comment #20
drummI'd like to see this solved on the development version first.
Comment #21
catchOne out of two hunks failed.
Comment #22
mfer commentedI just ran into this. We should solve in in D7 and then backport the fix.
Comment #23
dave reidI wonder if the '@' character would pass the PHP-5 function that we used to replace the internals of valid_email_address:
Comment #24
mfer commented@Dave Reid I believe you mean the issue #308977: Replace valid_url with filter_var and FILTER_VALIDATE_URL
I'm wondering the same thing. What level of url checking do we expect out of valid_url()?
Comment #25
mfer commentedThis was fixed when #308977: Replace valid_url with filter_var and FILTER_VALIDATE_URL went in.
Comment #26
dave reid@mfer That didn't actually get committed, it was won't fix. :)
Comment #27
mfer commentedoops, I meant #124492: valid_url() does not support all valid URL characters fixed this issue.
Comment #29
thesurger commentedWhy won't this url work????
Figured out that it is the "=\" in the following url
http://wirelessweek.com/rss.aspx?type=cat&path=\carriers
Confused with what to use from the above comments...
Can someone please help me out?
Thank you.
Using Drupal 7 - Aggregator (Core module)
Found this in "common.inc"
Comment #30
thesurger commentedHelp, tried all of these, cannot get the "=\" to work in the query portion of the url
What I need=
http://wirelessweek.com?type=cat&path=\carriers
What I tried
---------------
http://wirelessweek.com?type=cat&path=%92carriers --> ascii
http://wirelessweek.com?type=cat&path=&92;carriers --> html
http://wirelessweek.com?type=cat&path=0x5Ccarriers --> hex
None of these will pull a feed from the above source.
Willing to make a change to the common.inc file, but don't understand all the short hand used in the drupal 7 version of this file.
Comment #31
thesurger commentedBTW: just edited common.inc and set value $url="http://example.com" and was able to pass validation.
HOWEVER, now when I run the aggregator update it now gives a message saying "Mismatched tag" on line 143.
Module I am using is Core Drupal 7 - Aggregator.
Note: this same link worked in Drupal 6.22
What do I have to get it to work now that I upgraded to Drupal 7?
Comment #32
pasquallethe original issue was fixed, for further discussion see #295021: Expand/augment UrlHelper::isValid() to improve correctness and handle more URL types