security

Finally after several weeks of preparation the Drupal Security Module Packages are available.

About the Security Package:

This article is here to start a discussion about this topic, and maybe go on making this into a GSOC proposal or a new module.

Securing your admin area with SSL in drupal

Setting up a secure administration environment in drupal is still complicated, and might even be an important security flaw in several configurations. A large part of this is due to the architecture of drupal that does not have a dedicated admin area and not much difference between normal (unprivileged) users and admin users.

Hey all,
I have some questions about how security vulnerabilities are researched inside the classic Drupal development plan and about where are we and where are we going, about security obviously. That's because I noticed that if someone wanna help testing Drupal for security vulnerabilities, he founds a very low number of informations, that means:
- no idea about what's already tested
- no idea about what could be useful to do

Some things obviously needs to be secret, but this level of secrecy is maybe too much.

Hej!

Finns det någon modul som gör att man kan låsa så att man har vissa användare som har användning till "sina" filer.

Ex.

Om man driver en sida där man har en kundavdelning. Olika kunder har olika login och där kan dom lista sina "avtal" och ladda ner och beskåda (fast andra användare kan inte se deras filer utan bara sina egna)

?

Tack på förhand

Joomla has announced availability of new ACL: http://is.gd/iA5B and they seem pretty excited about it. Is that something for Drupal community to be jealous of?

If you come from a Java/J2EE background the clear answer is: NO (yes, in capital letters). You have to actually suffer from a structured, strict ACL to really appreciate the simplicity of a security system like that of Drupal.

Now, you may argue that Drupal security is slightly over-simplistic and too code-oriented (makes us, the developers happy) for "business" use.

I'm doing more and more work within the government and am running into a lot of MS IT Departments who really don't understand open source, Linux and really can't get their heads around Drupal.

I've been looking around for some reports or analysis for Drupal 6's security. There are lots of good howto's:
- http://justin.madirish.net/node/241

Nice to see Google's Radproxy as a nice evaluation tool (has anyone run that against Drupal core?):
- http://code.google.com/p/ratproxy/

Hi all,

I hope this is a good place to talk about this subject.

WYSIWYG editors such as TinyMCE are great, but when it comes to provide a secure method to filter what such a tool allows to users, I have the feeling that Drupal core filters do not help much.

If we use Full HTML, then we can do anything with our great WYSIWYG editor, however this is no no solution if we need to allow WYSIWYG capabilities to users we cannot trust. So, Full HTML filter might only be a valid solution for personal sites, or sites where all contributors can be trusted 100%.

Submitted for perusal by the group, as passed to me by a fellow developer.

"[Google ratproxy is a] semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments.

I'm working on a D6 site that could be considered an Intranet style site for members of our ministry. It is accessible from anywhere on the Internet, but should have very little content available without logging in.

How do I best lock down the site so that people have to log in before getting information without showing an "Access Denied" page at the first page where they log in? I envision a future where blogs with some public facing content could occur so I don't want to lock out that option in solving this problem.

For those who don't get the Security email announcements:

------------SA-2008-038 - SERVICES - ARBITRARY CODE EXECUTION------------

 * Advisory ID: DRUPAL-SA-2008-038

 * Project: Services (third-party module)

 * Versions: 5.x and 6.x

 * Date: 2008-June-18

 * Security risk: Highly critical

 * Exploitable from: Remote

 * Vulnerability: Arbitrary code execution

------------DESCRIPTION------------

The Services module package was created out of a need for a standardized
solution to integrate external applications with Drupal. It builds on concepts
from Drupal core's XMLRPC interface, but abstracts service callbacks so that
they may be used with multiple interfaces such as XMLRPC, SOAP, REST, and AMF.
This enables a Drupal site to provide web services via multiple interfaces while
using the same callback code.

Unfortunately, the access control system is not sufficiently granular; Users
with access to use a services have access to all provided services. With the
provided node services, or the system services enabled, it allowed arbitrary
code execution for those users.

Access to services can optionally be limited to certain ip addresses or
configured to need an API key, somewhat mitigating the issue.

------------VERSIONS AFFECTED------------

 * Versions of Services for Drupal 5.x prior to 5.x-0.9

 * Versions of Services for Drupal 6.x prior to 6.x-0.9

If you do not use the Services module, there is nothing you need to do.

------------SOLUTION------------

Install the latest version:

 * If you use Services for Drupal 5.x upgrade to Services 5.x-0.9 [
http://drupal.org/node/272203 ]

 * If you use Services for Drupal 6.x upgrade to Services 6.x-0.9 [
http://drupal.org/node/272202 ]

Review the new security features within the module, and upgrade all of your
remote service calls to authenticate a user session ID before making any Service
calls requiring secure communication.

See also the Services project page [ http://drupal.org/project/services ].

------------REPORTED BY------------

Scott Nelson [ http://drupal.org/user/31156 ], Gerhard Killesreiter [
http://drupal.org/user/227 ], Heine Deelstra [ http://drupal.org/user/17943 ].

------------CONTACT------------

The security contact for Drupal can be reached at security at drupal.org or via
the form at [ http://drupal.org/contact ].