Could this at all be related to cookies and proxy servers? I’ve seen more issues come up in relation to proxy servers (for example, with setting the “Number of seconds between searches” in the CP for a user group - it essentially HAS to be zero “0” if you’re going through a proxy…there’s another thread around here about that).

Does that string in any way indicate a cookie? If so, should they look in the CP to see if a cookie domain has been set at all? Might that help?

Here’s a related thread that goes into dead-horse beating detail about some (possibly) related things: Disallowed Key Characters

[Mod edit: Split from This Thread]

I know that this build has been modded (before the existence of Solspace’s User module) to allow email addresses to be used as a username. Could that have anything to do with triggering a “Disallowed Key Character”...if the user is logging in with an email address, and a cookie is being stored for them?

I think the source of the cookie might alternately be a reputable 3rd-party mailing list/email marketing provider. Wouldn’t it be relatively easy to ignore checks on a cookie beginning with “cm_”?

Ryan, you’re just jumping in to help, right? Or having similar issues yourself? Or connected with pbyweb in any way?

I just tried to PM you, Ingmar, but your inbox is full!

Actually, just turned off. Email to ingmar.greil@ellislab.com, please.

I emailed you, Ingmar…don’t know if you updated your signature with the “No PM’s” message after I tried PM’ing you, or I just missed seeing it. Sorry!

I updated my .signature retroactively, so not your fault Received your mail, too.

I got some more info on this issue, as I’ve been enlisted to help solve it.

Here are three cookies in question:
cm.BITQ57B4DJdDB7RU1D$BQTChjchnavtires
cm.BITYdgB4DJdDB7RYtp$BQTChWBh
cm.BIWmfAB4DJdDB7RrGM$BQTChYZh

These get set when someone clicks on a link from an email that ties into customer tracking (or something along those lines). These are perfectly legitimate cookies being set by a 3rd-party vendor for this site. The reason EE is reading them, (I think) is they’re being placed/generated from a subdomain of the main domain (i.e. email.domain.com) - so I think EE is seeing them because of this. Correct me if I’m wrong here.

Another person working on this issue noted this:

In testing the regular expression [the one in the EE’s core.input.php file - ryan] (cm_BITQ57B4DJdDB7RU1D$BQYe2Z4h)” it appears the “$” seems to be the failing character.

They go on to say this:

To allow for this in EE, the following should work:
“^[A-Za-z0-9\:\_\/\-]+$” needs to be “^[A-Za-z0-9\:\_\/\-\$]+$”
(I’ve added a \$ to allow for the “$” in the cookie.)

My main questions are:

1) Is the modification to the Regular Expression correct?
2) Is this a safe thing to do, or will allowing a “$” in cookies expose the site to other problems?

I think we should keep in mind this is not a shared server, and that the company placing these cookies is known.

Help on the above appreciated as users clicking through to the site through the particular emails generated by the 3rd party are running into the dreaded white screen with the string of text - not good user experience.

Yep- looks like that’s the problem.  I’m going to bump to the dev crew for feedback on the security issue.  It’s not just cookies that get run through that function- think it’s any globals/get/post/session.  Any time you muck w/it, it can have security implications.

But- I’m not the one to comment on the proposed alteration- so let me alert the crew.

And nice job of debugging it!

Thanks…I don’t think modifying the core files is a big deal on this build as there have been a number of mods made already (all of which have been meticulously documented). This could be another case of making a small core tweak and documenting it.

I suppose a few lines could be added to say (in English): if the item coming through this function is a cookie that starts with cm, allow dollar sign characters, otherwise, carry on.

I am going to strongly recommend against hacking this.  ExpressionEngine here is protecting you here, not only for itself but for any third party scripts that you may integrate with ExpressionEngine.

Here is what happens: ExpressionEngine sees a cookie in the user’s browser for its domain that might contain malicious code, so ExpressionEngine bails out and doesn’t run.  We protect not only our own code, but code that you might have running while our application is executed.

Circumventing the protections that we put in place is something that you do at your own risk.  Instead, you might discuss with the vendor using a better cookie naming scheme and see if they can work with you on this.

Just to add to this - as always, hacking is not supported; and removing our security protections would be something we strongly recommend against.

Well, I’m not sure if the vendor placing this cookie is open to changing their method for one site, but I could try (the vendor is huge, with a long list of A-list clients who use their service).

The alternative really isn’t acceptable - we can’t have people arriving at a dead page with nothing to do and nowhere to go - they can’t even email the webmaster to ask what is going on.

I’ll start by asking whether the vendor can change their cookies to only include alpha-numeric characters (which, I’m supposing is what is needed here). If they can’t do that, it looks like the only other option is to change the regular expression to at least allow dollar signs.

Lisa Wess - 25 June 2008 11:00 AM

Here is what happens: ExpressionEngine sees a cookie in the user’s browser for its domain that might contain malicious code, so ExpressionEngine bails out and doesn’t run.  We protect not only our own code, but code that you might have running while our application is executed.

So, alternately, instead of getting the email/CRM vendor to possibly rewrite their cookie setting method, we could put the cookie under a different domain that isn’t the EE site’s domain, and EE would not look at it in that case? I think they’re using email.domain.com.

I’m not sure if that’s an option, either, but I just need to get all the info I can on this so it can be remedied with the least amount of headache for everyone.

Another thought: because the bad cookies are coming from email.domain.com - could we specify the cookie domain in the CP as www.domain.com, rather than what I’ve seen before which is something like .domain.com. Would that force EE to only look at the www.domain.com cookies, and skip the other ones?

If your site has separate cookie domains, and EE cannot ever be accessed via the other domain, then neither will be able to read the others cookies.

From what I am understanding, however, If this other product is a PHP application though, that cookie key is still potentially problematic, so I’d bear that in mind no matter how you resolve this.

Well, I don’t think we’re going to get the large vendor to change the way they do cookies.

I think we may need to just go ahead and, unsupported as it is, change that RegExp to allow for a dollar sign. As it stands, there is no other way to solve this because:

1) The cookie needs to be set
2) The cookie is being set on the “same” base domain as EE (email.domain.com)
3) Users are coming to this dead-end with nowhere to go
4) Users keep on comin’

Assuming we wanted to go another route, though, keeping the original RegExp intact: Would it be easy to make a redirect to a more friendly error page? So, rather than the script exiting, the user gets redirected to a page that is easier to understand? I’m thinking something like this:

I have a feeling that, no matter what, we either need to eliminate the dollar signs, or allow them through.

And please feel free to break this thread off and start a new one in the “How To” section, preferably with a very descriptive title like “Help with EE ‘Disallowed Key Characters’ page; RegExp failing on ‘$’ character in 3rd-party cookie string. Alternative?”

I decided to just flat out google “disallowed key characters” (DKC’s) rather than searching for that phrase here in the forums. I came upon an interesting post in the EE Wiki regarding DKC’s and mobile sites: Mobile Site - Disallowed Key Characters

Particularly towards the end:

Replace line 138

$_COOKIE[$this->clean_input_keys($key)] = $REGX->xss_clean($this->clean_input_data($val));

with

if (substr($key, 0, 4) == 'exp_') {
$_COOKIE[$this->clean_input_keys($key)] = $REGX->xss_clean($this->clean_input_data($val));
}

Note this forces Expression Engine to only check cookies with the prefix “exp”. [...] Your alternative is to allow $ inside your forms but this is usually not a good thing from a security perspective.

We’re only running into issues with cookies from this one vendor, and those cookies start with “cm”. I"ve a feeling I could do something like this:

That should hit and clean every cookie that isn’t from that particular vendor. I think.

Sounds good. Would be a hack to maintain, of course, but I think your logic is sound. Have you tried it?

(Thanks for renaming the post…it has a much more descriptive title and should be easier to locate in future searches relating to this problem)

I think we’ll probably try that last “solution”. There is a well-documented hack file for this build, so we’d just have to make sure to explain the what’s and why’s in that file after implementing it.

Thanks, Ryan. Please do keep us posted; also, feel free to log a feature request to change that behavior of EE.