Fatal error: 1048:Column 'value' cannot be null :: insert into sessions (sesskey, ex

You are correct Lat9 I did not edit the log, that was part of the session key and I thought it was odd too. I'll make the change you've suggested CarlWhat and see if that will at least curb the activity. When the error does happen it usually generates 100+ logs at a time, but it only happens very sporadically, so I suspected it was some sort of attack, but looking at server logs, I could never really match it up.

Thank you for your assistance! Hopefully this will help others and perhaps those function changes should be permanently implemented in a future release.

lat9:

16-Oct-2017 14:41:43 America/New_York] Request URI: /catalog/metal-wine-racks-c-34_41/?zenid=2ebs3mmgmrqas9h520lq6enla1UNIONALLSELECTNULL--mXuy, IP address: 91.247.38.57

> Did you edit that log, or was the portion I've highlighted above part of the log?  If that was part of the log, then that's the root of the issue.

i am circling back around to this problem....

i am experiencing the same thing on my test machine.  no google-bot; nothing....  private IP address, behind a firewall with very limited ability of code compromise....  although it is a downloaded vagrant box, so it may have started from there.

to be very clear about the problem, i am getting the following error:

PHP Fatal error:  1048:Column 'sesskey' cannot be null

now, my session key is not NULL.  however when you execute a bindVars using string it becomes null due to the $key being something similar to above, ie:

4ebs3mmgmrqas9h520lq6enla1UNIONALLSELECTNULL--mXuy

so when ZC bindVars to string, it becomes NULL.  if you bindVars to stringIgnoreNull, it remains the same, ie:

4ebs3mmgmrqas9h520lq6enla1UNIONALLSELECTNULL--mXuy

so, now the error is resolved, however you have a session key similar to above.

my question is where does this session key come from, and how can i track it down to how it became the above?

i find it interesting that it has happened on my test machine, as well as another machine out in the wild.  using the stringIgnoreNull type is a bandaid, and not something that i see committed to any newer versions of sessions.php.  now whether the above string is in fact NULL, is hardly debatable.  it contains the word NULL but i would venture that is not NULL; so why ZC bindVars functions would treat it as such....  well, i'm sure there is a reason, but alas i digress...

again, my very specific question is from where i can track down this key and see how it got to be the above value?

thanks in advance.

I did a quick search on a ZC 1.5.5e site and the only occurrence of **union **(other than a comment in the Mobile_Detect script) was in the admin's developers_tool_kit.php, so that's being injected from somewhere external.

Does the issue always surface with the same IP address? Perhaps clearing out the existing session keys (in case there's a rogue link out there) would help?

lat9:

I did a quick search on a ZC 1.5.5e site and the only occurrence of **union **(other than a comment in the Mobile_Detect script) was in the admin's developers_tool_kit.php....

did you use grep? .... oh wait a minute.... don't you develop using windows?? ;)

ok, here is my latest opinions on this situation...

as i previously stated, stringIgnoreNull may address this issue, but it is a bandaid, and the datatype is not really an accurate description of what it does. another topic... and not integrated into the latest versions of the sessions.php script.

deleting the data in the sessions table does nothing.

the problem is in the browser's cookie; it seems to me the browser cookie zenid somehow got compromised and perhaps will use the sessionID to execute some sort of attack. if you look at my post #42 above, you can see how close my sessionID is to the one reported by gwynwyffar. coincidence? i don't think so...

if you delete record in the sessions table, it will just get re-created by the browser cookie (assuming you have changed to stringIgnoreNull), which is why i'm not sure that is such a great idea. and which is why the problem keeps popping up.

until the cookie gets deleted, the problem will remain. that's my latest thinking on this situation....