filter_xss_bad_protocol error line 304

The only time that this is called is if it is creating an external link. But the times when filter_xss_bad_protocol() is not available is during the boot sequence and secure pages is checking the current page, and it never passes a full url (ie http://example.com)

I am not sure why you would be getting this. If you can provide more information on how to replicate this.

My logs are showing repeated errors, too:

PHP Fatal error:  Call to undefined function filter_xss_bad_protocol() in /path/sites/all/modules/securepages/securepages.module on line 312

The relevant portion of code from the module is here:

  if (!isset($options['external'])) {
    // Return an external link if $path contains an allowed absolute URL.
    // Only call the slow filter_xss_bad_protocol if $path contains a ':' before
    // any / ? or #.
    $colonpos = strpos($path, ':');
    $options['external'] = ($colonpos !== FALSE && !preg_match('![/?#]!', substr($path, 0, $colonpos)) && filter_xss_bad_protocol($path, FALSE) == check_plain($path));
  }

I haven't been able to replicate it but know it's a problem because we've been getting calls from folks who are trying to renew a membership on a CiviCRM contrib page and they end up with the white screen and the transaction goes through but the membership isn't renewed. When I check the error log at the time the transaction goes through, this is the error that I find. I've tried renewing memberships myself and haven't had this happen, so I'm not sure what is triggering it. I also have/had the anti-hijack module installed, not sure if that could have anything to do with it.

Any ideas?

I've also noticed this in my logs. I'll try to debug it if I get the chance.

We had these errors in our logs, too. It seems to be caused by a mal-formed URL.

https://www.example.com/https://www.example.com will cause the error.

https://www.example.com/http://www.example.com does not cause the error, but gives a page not found (as it should).

the double "https://" seems to be the culprit, causing filter_xss_bad_protocol() to be called during hook_init(). The function is defined in the filter module (core, always enabled), but the filter module itself does not have a hook_init(), so the module itself has not been loaded at that time. This is what is causing the PHP fatal error.

Note - In case there is someone reading this that is not familiar with the way modules are loaded:

1. at the beginning of the page load, only modules with a hook_init() are loaded.
2. all hook_init()'s are processed.
3. All other modules are loaded.
4. all hook_boot()'s are processed.

Of course, there are other things that take place, too, but this illustrates why the hook_init() causes the error when it calls a function that is defined in a module that does not also have a hook_init(). I also assume that the module author also knows this, because he does try to keep this scenario from happening in the module, but unfortunately the double "https://" circumvents the logic. I only include the explanation for the benefit of others.

It looks like many of the hits come from bots, but where they came up with that URL is anyone's guess. Improper use of the l() function (or not using it!) could result in these bad links being exposed to the public.

Hope the info helps.

I am getting this error in Views when I try to delete a field.

We have these appearing when our automated Mcafee scan hits the site with querystrings like this:

?q=http://www.mcafeesecure.com/help/scanner/5/rfi?

Adding this line right above the problem line solves the error:

module_load_include('module', 'filter', 'filter');

Here's the solution in patch form. The reason for the bug is simple: securepages_boot() -> securepages_redirect() -> securepages_goto() -> securepages_url() -> filter_xss_bad_protocol(), and filter module hasn't been loaded yet in the boot phase, because it doesn't implement hook_boot(). I guess the real question is why this bug doesn't show up more often.

I had this same problem with the automated McAfee security scanner. The above patch worked great for me.

The problem code was removed entirely by http://drupalcode.org/project/securepages.git/commit/2ca9c149541c01a1b2b..., which was included in 6.x-1.9.