1

Thanks good people here, I have create a simple module which generate two blocks as follows:

function myblockmodule_block_info(){
    $block['myadblocks'] = array(
        'info' => t('My first ad blcoks'),
        'cache' =>  DRUPAL_CACHE_GLOBAL,
    );

    $block['myadblocks2'] = array(
        'info' => t('My second ad blcoks'),
        'cache' =>  DRUPAL_CACHE_GLOBAL,
    );
    return $block;
}

/**
 * Define what our block is going to look like.
 * Implements hook_block_view().
 */
function myblockmodule_block_view($block_key){
    $block = array();

    if($block_key == 'myadblocks'){ //We only want to define the content of OUR block
        //This is the title of the block.
        $block['subject'] = '';

        //Define the block content.
        $block['content'] = '<script>some ad js comes here</script>';
    }
    elseif ($block_key == 'myadblocks2') {
      $block['subject'] = '';
      $block['content'] = '<script>some other ad js</script>';
    }

    return $block;
}

My intention is to user these blocks instead of my current blocks that were volnurable to to script injection.

However, I am not sure the new module-based blocks will be more secure than the old admin-generated blocks. So appreciate your critical review of the module above.

2 Answers 2

1

Is this block safe from code injection exploit?

Essentially yes.

You're hardcoding the javascript, so there's no vector by which an attacker can inject code from the client side. This will of course change if you're interpolating variables into the JS code that have come from a potentially insecure source (i.e. the user). Those will need to go through filter_xss().

That's a bit over-simplified, there could of course be other vectors outside of this context which would allow an attacker to manipulate the PHP file itself, which could theoretically be invoked from the client. But in-and-of-itself, the method you've chosen is secure against XSS attempts.

2
  • So, regarding that the pages are being cached and served through cloudflare, do you suggest that it'd be safer to enclose the scripts in filter_xss()?
    – edi
    Jan 15, 2015 at 15:24
  • Well no, they won't work any more if you do that, as they'll strip the JS. If you want to include remote JS in your page you simply have to make the decision to trust it, you don't have another option. Unless you implement a JS processor in the back end which parses out any potentially bad code. But you're in the realms of startups-getting-millions-of-dollars-to-try-it territory there. The decision you need to make has nothing to do with Drupal and everything to do with whether or not you can trust the remote data. Drupal can't help you to make that decision, no framework could
    – Clive
    Jan 15, 2015 at 15:29
0

It seems from your older question that your problem with old blocks was mainly the fact that someone was able to log in and edit admin-only things, wasn't it? If so, then no. This will not make you safe. If someone hijacked your admin account, he will be able to switch these off and create new, abused ones.

And if problem was with the JS itself, then switching from Full HTML block to module-provided one, and leaving the same script in it, will not help, either.

7
  • Well, I am not sure the admin being hijacked. If it was I expect to have much worse damage. So please ignore that possibility. I use usual 3rd party js scripts provided by known ad markerter. How do they allow appending malacious js?
    – edi
    Jan 15, 2015 at 14:28
  • @bili Until you know the source of danger, we can't for sure know if you stopped it. And for damage - they do what's profitable. Keeping your site in good condition but abusing your visitors privacy and your ads may be most profitable, plain and simple. Mindless destruction does not pay for itself.
    – Mołot
    Jan 15, 2015 at 14:30
  • You are right. I am worried to deploy this module because comment by Clove who was skeptic that such module can be any secure: drupal.stackexchange.com/questions/144234/… . And if no block is secure to code injection, so bad for drupal!
    – edi
    Jan 15, 2015 at 14:35
  • @bili nothing is secure if admin account is hijacked or if you import insecure 3rd party scripts. No matter if it's Drupal, Wordpress, Joomla, or Ruby on Rails app you hacked all by yourself.
    – Mołot
    Jan 15, 2015 at 14:37
  • 1
    @bili I was under the impression you wanted to input the JS through the UI when I made that comment on your previous post - if you're hardcoding the script in a PHP string, then there's no attack vector for XSS, unless someone has server-side access. i.e., you're safe.
    – Clive
    Jan 15, 2015 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.