Security

The Sophos article on the Drupageddon followup PSA makes a solid argument for an auto-upgrading system built into Drupal, as an effective means to reduce the impact of things like Drupageddon.

Wordpress already has such a thing. Drupal already has a self-upgrading system, but it is not automated or promoted as a useful tool for securing a website. It also doesn't support patching (though that might not be necessary).

Thoughts?

Hi All,

I recently received an email from my host (Arvixe) stating that they had disabled a script on one of my D7 sandbox sites due to large quantities of spam email emanating from there.

Upon investigation I found an encrypted PHP file called "sql91.php" in my modules/field/modules/options folder. I later discovered a second bogus file called "sraynr.php" in a different folder. Both of these files have been called from Russian IP addresses:

146.185.239.52
146.185.239.51

In an ideal world, what is the best time for a security release to happen?

Sometimes the security team doesn't have control because a project maintainer commits and makes the release node at a specific time. We can, of course, try to make it more clear that they need to commit and make releases before a specific time.

And often there is some control.

So, in our ideal world, what time would people want it to be released?

Can we do something to pre-release in different parts of the world?

Here are the slides from the talk from klausi and pwolanin

I just pushed an initial commit for a module that can help module developers and site owners test for XSS vulnerabilities: https://www.drupal.org/sandbox/matthew.donadio/2319347

The module does a form alter to add two buttons to forms. The buttons will prefill inputs and textareas with simple XSS, <script>alert('XSS')</script>, for testing purposes. The actual alert message will contain the $form_id and the element name in the message.

hook_menu has an item argument for 'access callback' which allows people to define permissions on a router path. Normally, paths have some sort of check on them, usually user_access + a permission, but sometimes a check specific to the path (cf, the node paths).

The API also allows "naked" menu items that don't have any access check. This is done by setting the 'access callback' key to TRUE. Mistakes with this can lead to access bypass problems.

I have seen it in two instances in the wild, but I am sure there are others.

Hi folks, so I have a site with honeypot installed and it is doing a great job of blocking spam. Problem is though the site is doing a lot of work to block these malicious bots and it would be nice to ban them. Blocking their IP is useless since they come from all over the place, is there anything that could be done to try and get the site less inundated with spending clicks processing fake users all the time?

Thanks,

Raz.