[drupal-devel] Question on valid_input_data()
In 4.6 includes/common.inc, in the function valid_input_data(), there is a check for various entities. Among these entities, there is a check for "style". http://drupaldocs.org/api/4.6/function/valid_input_data I use the banner module with text ads, and I use things like: <div style="some-style-definitions">some text</div> This check causes the above to be flagged as a security breach attempt and is logged to the watchdog as such. http://drupal.org/node/20608#comment-29106 My question is: Can the "style" element be used in malicious attacks? If yes, then how? Thanks in advance.
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 I have banners that rely on using onclick to redirect to an ad serving page/script, and these are being blocked by Drupal, what can be done about them? On 5/7/05, K B <kbahey@gmail.com> wrote:
In 4.6 includes/common.inc, in the function valid_input_data(), there is a check for various entities. Among these entities, there is a check for "style".
http://drupaldocs.org/api/4.6/function/valid_input_data
I use the banner module with text ads, and I use things like:
<div style="some-style-definitions">some text</div>
This check causes the above to be flagged as a security breach attempt and is logged to the watchdog as such.
http://drupal.org/node/20608#comment-29106
My question is: Can the "style" element be used in malicious attacks? If yes, then how?
Thanks in advance.
On 08 May 2005, at 05:41, K B wrote:
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 I have banners that rely on using onclick to redirect to an ad serving page/script, and these are being blocked by Drupal, what can be done about them?
You can check the 'bypass input data check' permission. -- Dries Buytaert :: http://www.buytaert.net/
On 5/8/05, Dries Buytaert <dries@buytaert.net> wrote:
On 08 May 2005, at 05:41, K B wrote:
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 I have banners that rely on using onclick to redirect to an ad serving page/script, and these are being blocked by Drupal, what can be done about them?
You can check the 'bypass input data check' permission.
Since this problem occurs with the banner module when it runs its cron function, it is run under anonymous. Hence it is not an option to change the permissions, since it will open more security holes that way.
On 7 May 2005, at 8:13 PM, K B wrote:
In 4.6 includes/common.inc, in the function valid_input_data(), there is a check for various entities. Among these entities, there is a check for "style".
http://drupaldocs.org/api/4.6/function/valid_input_data
I use the banner module with text ads, and I use things like:
<div style="some-style-definitions">some text</div>
This check causes the above to be flagged as a security breach attempt and is logged to the watchdog as such.
http://drupal.org/node/20608#comment-29106
My question is: Can the "style" element be used in malicious attacks? If yes, then how?
Hi K B, yes, the style element can be used in attacks. If an attacker can place CSS on your page, arbitrary elements can be moved, or hidden; images can be replaced, or tiled to completely render the page useless; images can be used in information leak attempts and some browsers extend CSS to allow the execution of scripts. A little Google search for "style element css attack" should yield more details. Regards, Djun
Thanks in advance.
On 5/8/05, puregin <puregin@puregin.org> wrote:
Hi K B, yes, the style element can be used in attacks. If an attacker can place CSS on your page, arbitrary elements can be moved, or hidden; images can be replaced, or tiled to completely render the page useless; images can be used in information leak attempts and some browsers extend CSS to allow the execution of scripts.
Thanks. It turned out that style is not the issue, but the on* javascript events.
Guys. Thanks for all the replies. However, some of the answers do not apply in this case, such as giving the permission to bypass input filters, or to set to Full HTML. The module in question here is banner.module, and this particular problem happens when it is configured to use files, and has to write the a cache of the ad banners. This happens when cron runs only, and not from any user screens. It uses file_save_data() http://drupaldocs.org/api/4.6/function/file_save_data Which in turn calls valid_input_data() http://drupaldocs.org/api/4.6/function/valid_input_data I changed the text ads to say <span href="blah">...</span> Instead of <span onclick="parent.blah='/blah'">...</span> This solved the problem. There is no way to set the filter to Full HTML for cron, and it is extremely unwise to bypass input check for anonymous users. Thanks to all.
K B wrote:
[...] There is no way to set the filter to Full HTML for cron, and it is extremely unwise to bypass input check for anonymous users.
yet another reason to `introduce a "cron" user` [1]. any opinions on that issue? [1] http://drupal.org/node/5380 -- ax "Amoris vulnus idem sanat, qui facit - Die Wunden der Liebe kann nur heilen, wer sie zugefügt hat." (Publilius Syrus)
participants (5)
-
Axel Kollmorgen -
Dries Buytaert -
K B -
puregin -
Steven Wittens