Security Kit on GitHub

I was planning to do this a long time ago, but this, that and the other delayed me. Finally, I've registered at GitHub and added repository for Security Kit. In short, that's the module for Drupal CMS which provides with few options to improve the security of your Drupal-based site. It aims to simplify the process of setting up security features which exist in modern browsers (CSP, Origin, X-Frame-Options etc.).
Present situation in web security indicates that regardless huge number of hacks and all these talks about "every site needs to be secured", the number of vulnerabilities does not decrease. Just take a look at XSSed. So, browser companies decided to add more built-in features to harden the web. They are mostly implemented with HTTP response headers and all the website owner/admin has to do is to add one.
Still, many people have no idea about such things or they don't know how to do this. That's the reason of creating Security Kit and, previously, SafeClick (which is so highly tailored, just for Clickjacking, so I decided to move it to Security Kit and close it).
Even though Drupal recently migrated to Git from CVS (thanks!), I plan to develop SecKit on GitHub along with other projects, which I hope I will soon finish (at least to make them public).

P.S. I do really hope and expect collaboration.

Drupal and cookies domain caching

From time to time anyone experience some problems with non-fresh Drupal installations (e.g. some project from SCM). The major one for me was some strange cookie setting and handling - when I tried to login Drupal replied with correct Set-Cookie header, but cookies were not saved within browser, i.e. after login the page was just reloaded with login prompt. No message or anything to help me. So I just started commenting and editing related code by random. Finally, I got it. The problem is that Drupal was installed first with hostname A and I tried to work with it on hostname B. Don't know why sometimes it's okay and sometimes it's not. However, you just need to uncomment $cookie_domain and set it to your hostname in settings.php. Just like this:

$cookie_domain = 'your.domain';

Exploiting IE MIME-sniffer vulnerability in Drupal

IE always loved to create vulnerabilities where they would never be. Not many people know, but there is an old bug in IE MIME-sniffer, which can be easily exploited. The essence of the bug is that when IE renders file, which was sent along with Content-type: text/plain header, it tries to identify its MIME type. So, if file contains HTML code inside, IE will think its text/html and render it. Simple example of exploit in Drupal:

1. There is a Drupal site with enabled Upload module.

2. Attacker uploads *.txt file with HTML code inside. By default Drupal allows *.txt files.

3. Attacker sends a link to that file to victim.

4. Victim opens it in IE and HTML code is rendered.

It's pretty bad that Drupal core, which is tough by default, can be exploited in such a simple manner. I understand that it's not Drupal issue, but Microsoft isn't going to fix it. Instead, they suggest to send X-Content-Type-Options: nosniff HTTP response header. But, it's not possible to do this in Drupal and Drupal Security Team didn't fix it for 2 years and won't do this in future. So, if you are aware of your users' safety, remove .txt from allowed tags. You can do this in Administer -> Site configuration -> File uploads.

SafeClick - protect your Drupal site from Clickjacking

SafeClick is released. It is a module for Drupal CMS, which you gotta have to defense your website from Clickjacking. It implements several techniques of such defenses.

Opportunity of setting X-Frame-Options HTTP header. You may set it up to SameOrigin to allow framing of website within its domain or to DENY to prevent framing at all. Or you may disable it. This header is currently supported by Mozilla Firefox + NoScript extension, Apple Safari, Google Chrome and Microsoft Internet Explorer 8, so it's the safest way for your website.  

JavaScript + CSS + <noscript> framebusting. It's the hardest defense for your website, however it can break down some of your modules which use iframes. The disadvantage of usual framebusters is that they can be disabled particularly using IE8 or Safari XSS filter  This framebuster, pointed to me by sirdarckcat, excludes such kind of attack. If user disables framebuster script selectively - he sees blank screen. If user has generally disabled JavaScript - he sees message like "Enable JavaScript". However, I've decided to make <noscript> tag as a separate option, because such option may be useful without framebuster itself. 

Opportunity of decreasing the risk of Clickjacking on your site via overridden styles of <iframe>, <frame>, <object> and <embed> tags. This option should only be enabled if you allow your users to post content with stated tags. Special CSS overrides opacity level and z-index for them, preventing transparent frames and hidden via z-index frames. Also, z-index is useful for prevention of "last loaded - first focused" behavior (when last loaded frame is being focused regardless its z-index). The reverse is that in theory it may break website layout.

Module is released and I hope it will be useful for Drupal users. Thanks to all slackers for helping me with Clickjacking prevention techniques.

You may download module there.

SafeClick Testing & Review

After long discussion about methods of Clickjacking prevention, I've released for testing and reviewing SafeClick. It is a module for Drupal CMS which implements several of such techniques.

The first is an implementation of  X-Frame-Options HTTP header.

The second is JavaScript + CSS + <NoScript> hack, pointed to me by sirdarckcat - thanks to him!

The third is special CSS, which can be useful if a website allows users to post frames within their content. It overrides opacity and z-index of HTML elements, used for Clickjacking attacks.

Module is currently being reviewed by Drupal community. Everyone is welcomed for testing and hacking!