After upgrading to Drupal 4.6, and banner module cvs (April 15 tarball), it seems that Drupalk does not like something about banner when cron runs.

The following problem appears in the log whenever cron is executed:

Possible exploit abuse: invalid data.

And

Terminated request because of suspicious input data: a:3:{i:0;a:1:{i:0;a:2:{i:0;s:1:"1";i:1;s:1:"3";}}i:1;a:2:{i:1;O:8:"stdClass":8:
{s:5:"views";s:5:"16586";s:9:"day_views";s:1:"1";s:13:"day_max_views";
s:1:"0";s:10:"week_views";s:1:"1";

(the message has more data in it, such as the HTML of the ads, ...etc, but I truncated it for brevity.

Both are flagged as security in the log.

Otherwise, the banners display fine. Had to refresh the cache manually first.

Comments

kbahey’s picture

kbahey commented

Jeremy

I traced that to this call

file_save_data($data, $cache_file, 1);

in the function _banner_refresh_cache() which is called from the _cron hook.

My ad is a text ad, with HTML tags, but no javascript or anything like that.

When I manually refresh the cache, there is no such error.

What could this be?

jeremy’s picture

jeremy commented

The banner module is not yet patched to work with 4.6. You might want to try applying this patch on your local installation. I hope to work on an official 4.6 release soon.

kbahey’s picture

kbahey commented

Any guesstimate on when a 4.6 release should be expected?

jeremy’s picture

jeremy commented

Not really. Hopefully soon. Maybe this week. I'm looking at it now, but still doing a little work on the 4.5 branch, which I'm currently still using.

kbahey’s picture

kbahey commented

I tested the patch you mentioned. The cron security error is still there.

I did not expect it to fix it, since the problem is in file_save_data() which is called from _banner_refresh_cache().

What is puzzling to me is that this same function is called elsewhere in banner.module, but no errors are reported.

Anyway, a week should be fine.

kbahey’s picture

kbahey commented

I tested the latest cvs tar ball (downloaded today), and the suspicious input error still occurs in the log.

jeremy’s picture

jeremy commented

I still haven't forked the module for 4.6.

kbahey’s picture

kbahey commented

Sorry to keep asking, but do you have an estimate for when a 4.6 version will be available?

kbahey’s picture

kbahey commented

I have traced this problem to be the validation done in the valid_input_data() function.

This function checks for the element "style" in the passed info, among many other things, and if it is present, it will terminate and log a security error.

I am using this tag in text ads, such as the following:

Some text

Does the use of style pose a security risk that I am unaware of?

kbahey’s picture

kbahey commented

Actually, after some more tracing, the "style" element was the not the culprit. It was the "on[a-z]+" regexp. I think this filters the javascript on* events.

If the banner module relies on using onclick to redirect to an ad serving page/script, and these are being blocked by Drupal, what can be done to prevent this, without opening up more possible security exploit points?

kbahey’s picture

kbahey commented

I am closing this issue.

It is not a problem with banner module itself, but rather with 4.6 being more strict about what input it accepts.

The use of OnClick events in the text ad was the cause of this. When I removed it, everything is fine, and cron does not report any security issues.