Security Scanner Component and Best Practices
This group has two major purposes:
-
Looking at the Security Scanner tool. Security scanner is a crawler and could be used to perform multiple types of scans.
-
Discussion security best practices in general. This is NOT a place to discuss vulnerabilities in released versions of specific public modules nor Drupal core. Please only ask questions before releasing a module or phrase them generally. If you find a security vulnerability in publicly available code the proper thing to do is report it to the Security Team.
SSL officially insecure?
A zero-day flaw in the TLS and SSL protocols has been made public and man-in-the-middle attacks have been demonstrated. I caught wind of this off of ZDnet.
http://news.zdnet.co.uk/security/0,1000000189,39860592,00.htm
Thoughts?
Login Security for Drupal 6 1.0 release is out
It took some time, but finally the 6.x-1.0 version of Login Security module is out. For a brief introduction to the module features please go to the module documentation. The README file included in the module explains the different options for the module settings and a configuration example.
Hope you enjoy the module!
How long should we wait to disclose explanations/proof of concept
Login Security, closing last stint for 1.0 release
I'm happy to announce that Login Security module release 6.x-1.0 is about to born. Currently, there is only one issue open. This issue takes care about string consolidation and english grammar. I'm not an english natural speaker, so probably there will be some words and corrections to be done. I would appreciate any help in this issue.
There is a new feature included for this 1.0 release: ongoing bruteforce attack detection that could easily be expanded for more paranoid settings.. probably in the 2.0 :)
You can check current roadmap status and (I hope) participate in the english correction.
Filtering User Generated CSS
There are several modules which allow for user/admin generated css to be injected into the page.
CSS can contain cross site scripting attacks and the use of url() helps make it a means to exploit CSRF. What can we do to filter user generated CSS so that it is safe?
One strategy seems to be something like the way color module/garland work: users are limited to choosing specific colors which are inserted into specific pieces of the CSS. This is also what a lot of other sites do (twitter, bebo, etc.). That's great, but limiting.
"Login Security" module uses and roadmap for a 6.x stable release
Hi, I'm in process of creating stable release of the "login security" module, and would like to inform current users of this module about it to recall their ideas and most used features, and remove (or not) the rest of them.
Don't know how to make a public call about it, and would not like to create a release to make this kind of notice so everyone will have to update their module version, so I've decided to create it here.
If you have any consideration or would like to know about this stable release please go to:
Securing your admin area with SSL in drupal (and other systems)
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.
Vulnerabilities and tools
This wiki page is build to coordinate the research of vulnerabilities and to provide a little explain of anyone of these.
The vulnerabilities reported here are the most common vulnerabilities found into web applications (source: OWASP top ten 2007).
After any of this vulnerabilities we should add a little description of what it is and a list of tools/ways-to-find-that.
Feel free to add something or mark that something was already been tested.
Cross Site Scripting
Injection Flows
Malicious file execution
Security, this unknown
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.
Security Audit or 3rd party Review
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/
New SA-CONTRIB-2009-XXX style security announcements
Yesterday was the first security release of 2009 and the first ever for the Drupal project that used the new naming convention: SA-CONTRIB-YYYY-NNN. The security team had a discussion late last year about the common confusion among outsiders to the project - mainly media reporters and evaluators of Drupal - that any SA announcement is from "Drupal." We often have security announcements about contributed modules that are only used on a couple dozen sites that are then interpreted to be problems in core.
"safe" (or safer) autologin module
There's recently been some discussion about the autologin module and the "feature" it provides.
I'd like to examine ways to make it safer. So, we start with the stated use case:
Naming the required permissions - see SA-2008-069
You may have noticed in SA-2008-069 for CCK that it names specific permissions required to exploit the vulnerability. Often in the history of Drupal's security announcements we have simply stated that there was a weakness and that it was a certain level of "critical."
Starting with this release we are testing out the idea of also stating specifically what kind of permissions are required to take advantage of a bug.
Xss from URL...
Hi all,
The scanner is tested to find XSS vulnerabilities inside a drupal installation. These could be found only searching into the forms of the website. There's no way right now to add an exploit as a parameter of the url of the page.
Something like
http://www.example.com/?q=<script>alert(xss);</script>
This is something I wanna add as new feature, but make it automatic is not so trivial.
Suggestions?
Crawler new use and crawler reorganization
Hi,
the security scanner is first of all a crawler. It could run into the pages of a drupal installation and perform multiple tasks.
The first use of it was about security, we used that to seed patterns inside a form and to find if these patterns were not checked by drupal filters. I developed it with this intent, but while developing I see that everyone could use it to run other tasks, simpy changing some lines of code. Other task could be search for other patterns (moderation?) or something other.
