Thread

HI:
I have a question regarding the error message “Disallowed Key Characters” that can pop up in place of a template when viewing it. I just ran into such a problem- the template page contained a regular form with a frontend JavaScript that stores some of the field values to persist them (so users don’t have to fill it out again). Now, from what I understand the “Disallowed Key Characters” error is triggered by a security check in EE when it detects suspicious cookies being set. That’s all good, but I’m very concerned due to the following reasons:

1) The error potentially can be triggered by something very innocent by me, the admin, while editing a template that contains a script that stores/accesses cookies.

2) The result is an error that basically never goes away unless the affected user explicitly tries to fix it (clear all browser cookies?) For example, I’ve been stuck viewing the “Disallowed Key Characters” error for several days now in both IE and Firefox, because I used both browsers to view the broken template. If 100 people happened to have stumbled upon the template before it was “fixed” by me, 100 people will now forever be condemned with seeing this error message. And of course most of these people would simply assume the site is down and move on, instead of try to clear their cookies. I This is very scary to me, the fact that certain pages within a EE site can become inaccessible to certain people and remain totally undetected by me, the admin.

I guess what I’m asking is, is there any way to disable this security feature, or at least have it toned down somehow?

It’s really not something you want to disable, though the code isn’t encrypted so you could do it.  I really wouldn’t, though.  Are you doing a lot of editing that result in it being at all likely visitors would have a cookie set that triggers it?  Could add code to delete the cookie and refresh in a global header, if that’s the case.  Though in truth- it isn’t something we run into very often.  But if I did run into it- that would probably be the approach I’d take.

Would that work?

I’m more interested in what cookie you are setting that is causing ExpressionEngine to consider it potentially malicious.  Do you not agree that the better solution would be to not construct and use such a cookie instead of disabling built in security checks?

Thanks guys for the breakdown. Is the “Disallowed Key Characters” error triggered by server side cookies only, or client side JavaScript cookies as well? This leads into my answering Derek’s question- if it’s the later, I think we’re looking at a situation where the error can be triggered more often that one thinks. Any JavaScript that accesses/ manipulates a cookie can become potential culprits.

Any JavaScript that accesses/ manipulates a cookie can become potential culprits.

And that is precisely why we have such security checks in place.  Cookies can be accessed by both server and client side scripting languages, with the exception of HTTP-only cookies, which are not yet supported by all browsers.  Any cookie you set with Javascript can be read by a server-side script such as PHP.  What are the keys you are using?  You should not be using any keys that have characters other than alpha-numeric : _ / or -.

If you aren’t sure, you can reveal the offending key by modifying core.input.php, line 410, to read:

exit('Disallowed Key Characters: '.$str);

We had a rash of these problems this week. The offending string was:

useremail@parisjc_edu_iFolderListSize

The underscore instead of a period before “edu” was the problem, I guess.

So far as I can tell, it only happened for users on IE6 and IE7. Deleting the cookies fixed ‘em up.

Our IT folks have said they’ll send me a copy of the offending cookie text so I can try to figure out what set it.

The underscore is allowed, the period is not, nor is the @ symbol.  Safe characters for keys are a-z 0-9 : _ / -

There’s not any reason to have any other characters as the key of a cookie, POST, or GET item.  The value (the content) of the cookie, GET or POST item can of course contain anything (cookie and GET values are sanitized for XSS, but will not result in a fatal error).  But an email address for a key?

Our IT folks forwarded a copy of the offending cookie this morning after a machine repeated this error. A quick Googling turned up a few things, and it looks (to me, anyway) that it’s something set by the browser (IE) itself. I’m not a Windows user, so I can’t say for sure.

Know anything about this?

CulturePref
en-us
parisjc.edu/
1024
2379992320
37222205
1143973024
29874831
*
[i]user[/i]@parisjc.edu_iFolderListSize
207
parisjc.edu/
1024
3825090432
37222208
2572661136
29874834
*
[i]user[/i]@parisjc.edu_iMsgListSize
275
parisjc.edu/
1024
2489992320
37222205
1242403024
29874831
*

EDIT: I did not these are different from yesterday’s, where here there is a period before “edu.”

Browsers don’t add their own cookies for things, even the dastardly IE.  _iFolderListSize and _iMsgListSize look like proprietary names used by the campus.  Are there other scripts or web technologies being used on this domain?  ASP pages perhaps?  Or even other PHP scripts?

Nothing of that kind on the site itself. Our site is hosted by Engine Hosting and serves only our main Web site.

However, <memory kicks in> IT just switched on a new mail server this week (including new Web mail), so I’m wondering if it’s setting this cookie. The Web site is hosted by Engine Hosting, but our mail system is local, the domain name being simply without the “www” of the URL. Could be that this system is now setting that cookie. The problem started at the same time the new mail system came up, now that I think about it.

Sounds quite plausible, considering the key names being used, too.

I just emailed IT about the possibility and have asked them to check on it. I’ll post an update when I hear back from them. Thanks, Derek!