Cracking Drupal - security

Techniques in Attacking and Defending XML/Web Services

greggles — Fri, 13 Nov 2009 21:33:42 +0000

Mamoon Yunus and Jason Macy gave this presentation with an overview of XML/Web services and how the usual security rules apply to this area.

Review of the problems with XML/Web services

Still have all the normal problems.

Firewalls are not aware of the xml content
Malware and viruses (or xss) can be included in the content depending on what context the xml data is used.
WSDL exposes the schema and message structure
Injection attacks are possible via the XML parameters
Data replay is still possible
Denial of service is still possible, especially with parameters
Authentication methods: Basic auth, SSL auth, WS-Security Tokens
Parameter injection can be used for SQL or filesystem exploits.

Gateways for security

If you have a web service you can use a gateway to help bolt-on protection after the fact. They can provide various forms of authentication, logging, and semantic forgery prevention.

This seems like an interesting idea, but also somewhat flawed. My (admittedly naive) opinion is that the protection should really be included at the application layer.

They then reviewed a bunch of different vulnerabilities and gave examples of how they could be solved with XML gateways.

There's been a lot of discussion at the conference about how "we need to get more developers here" and I think part of the problem is that a lot of the presentations are not developer topics. The presentations cover how to exploit, how to buy a product to put in front of the vulnerabilities to prevent problems, how to use applications to pen-test, what the vulnerabilities are, what a security friendly process looks like, but relatively little about how to write secure code to protect against these vulnerabilities.

Cloudy with a chance of zero day

greggles — Thu, 12 Nov 2009 20:57:12 +0000

This was a presentation by Jon Rose and Tom Leavey of Trustwave. They started off with about 15 minutes worth of cloud background. The problems (and potential problems) they identified were:

Vendor lock in may come up since the Amazon cloud is somewhat different from writing for Google's App Engine which is different from...
Enterprise ready vs. experimental, meaning that most uses of the cloud right now are non-mission-critical.
Forensics in the cloud are somewhat harder to perform since you can't necessarily get the log files.
Compliance is more difficult because you can't do physical visits to the data center.
Misuse is possible because you can not only use the cloud for good but can also fire up a malicious virtual machine.

They reviewed the Google Application Engine

After some discussion of how GAE works, they got into some possible attacks.

You can post data and that counts against incoming bandwidth, even if the application doesn't accept post requests at that URL. So, using XSS to get all the browsers to a site to run a POST against an application can easily blow past a site's incoming bandwidth quota and take them offline.
The task queue has a limit of 5 requests/second can be blown out with an attack.
Create dozens of proxies on GAE as a way to hide who you are when doing an attack.
You can create new versions of your application and switch between them, but using this means any visitor can choose which version of your application they want to run.
GQL Injection - may be possible to do injection, but they couldn't. Seems like it's probably not possible.

Drupal Security presentation slides from BADCamp

Ben Jeavons — Sun, 18 Oct 2009 19:33:49 +0000

At the Bay Area Drupal Camp yesterday I presented on Drupal Security for site administrators and beginners which covered some of the important ways you can protect your site from attacks through configuration of Drupal core. Attached are the slides from the presentation.

Attachment	Size
drupal_security_badcamp09.pdf	465.01 KB

Drupal Security webinar with Acquia roundup

greggles — Mon, 12 Oct 2009 18:01:12 +0000

This past Thursday several hundred folks joined me for a webinar about security in Drupal as part of the Acquia webinar series.

You can now download the Security in Drupal introduction slides which include the speaker's notes and watch the screencast itself:

I also wanted to answer some questions that were posed in Twitter and in the GoToWebinar chat room. I didn't get to answer all of them in the presentation, so, I'm going to try to answer them all here.

Would you consider something as common as RSS publishing as a potential method for people to steal content?

Not in general. Sure, it makes it easier to copy your content but a determined scraper will always get your data. Now, an rss feed can be an access bypass vulnerability if it doesn't respect Drupal core's node access mechanisms, I have seen that.

What do you tell a client who doesn't want to pay you for your time to perform security updates?

We try to insist on it at the contract stage that as long as they are a development or maintenance client we will do site security upgrades ASAP.

Lots of good information in this presentation. Will you share slides? The zero day attack slide could be really useful.

Yes. The slides are attached.

It seems like Wysiwyg editors open a lot of vulnerabilties. Are there any modules you feel are more or less vulnerable

WYSIWYG editors don't open the vulnerabilities - bad configuration of input formats does. It's true that many sites will install a WYSIWYG and open up their input formats inappropriately and that's the real problem.

Can you talk a little bit about how his firm performs a site security audit? How long does it take and what is the cost range?

We have some details on our security review service. As far as pricing, we'd love to hear your feedback on what kind of price seems good. Please contact us to let us know what you think.

In a preprocess function setting up our variables for our designer, do we need to sanitize content in $vars before passing to tpl?

This isn't a simple yes/no kind of question. The answer depends on a lot of factors. While it's not a complete answer either, the Text filtering cheat sheet for Drupal is intended to make it easier for an educated developer to decide which function to use.

Forms input filtering is not recommended - that is the problem with Webform Report - why is maintainer unable to fix it?

This has more to do with them having the time/motivation/understanding and nothing to do with how technically feasible it is to fix the problem. It's actually another new service that we're offering is that we will take a module which has been abandoned for security reasons and fix it. If you'd be interested in sponsoring the work to fix that or any other module please let us know.

Can a lot of this security be built into a theme?? Will any of this be corrected in Drupal 7?

The theme layer is not an appropriate place for security protection. Themes can be switched quite easily, by admins and sometimes by end users, so if you put the protection in the theme then it's easy to mistakenly create a vulnerability.

Security related code belongs at the module or core layer. Now, Drupal 7 does have a much better rendering system (great presentation on render by Moshe Weitzman) which will hopefully make it easier for themers to not have to think text filtering.

I've read your book (good job, by the way) but it's not for beginners. Are you planning an seochecklist sort of module for security auditing drupal?

Well, I have to disagree ;) I think many parts of it are for beginners. But yes, as part of our security offering we do plan to create many new tools and enhancements to core that will be helpful to site builders.

What are some bad practices for theamers? Are there things that themers can do to make the site more secure?

This is not easy to answer. It's basically the fundamental question that the book answers. However, we do plan another webinar for the spring so perhaps that can be the focus.

Is that a FireFox addon that allows you to change your user agent? What is it called?

Yes, I use the User Agent Switcher by Chris Pederick.

Can t() be considered a substitute for check_plain()?

Yes, if you use the @ or % placeholders then t will automatically include check_plain style filtering as the text is substitutde.

How much scrubbing is necessary for FormAPI based forms? Do you risk XSS type attacks without checkplain, for example?

First, all forms should be Form API based (unless they post to an external site, which is very rare). Second, yes, if you use user modifiable text for labels or titles then you will need to do filtering. The exact nature of the filtering depends on a lot of factors

How can we do SSL or HTTPS with Drupal

I just blogged about this recently: Recipes for SSL / HTTPS in Drupal.

That's it!

Drupal text filtering decision cheat sheet

greggles — Thu, 08 Oct 2009 16:39:54 +0000

This flowchart is based on the one that Heine Deelstra presented at Drupalcon Paris.

I'm hopeful that the presentation will be helpful in eliminating Drupal's most common security issue!

Attachment	Size
filtering_text.pdf	55.82 KB