Content Security Policy for Rack

A long time ago I have implemented Content Security Policy as Rack middleware for my Ruby on Rails project. In short, CSP is a XSS mitigation mechanism. Server responds with HTTP header which defines trustworthy sources for different types of content (js, css, images) and browser restricts content from other sources. It's very powerful and you definitely should implement it along with other header-based security features (like X-Frame-Options, Origin, Strict-Transport-Security) especially as long as it won't take much time.

A couple of days ago I decided that it worths to publish middleware as a separate gem. I googled a bit and found csp_easy. However, it lacked few features (hash-based directives configuration, support to WebKit, Report-Only mode) and specs, so I decided not to fork and push my changes (I know it looks bad), but just to publish my own version.

Project is on Github. Read instructions and improve security of your Rack-based web application!


Polymorphous page objects

I'm a big fan of page object pattern used for developing Selenium tests and I like the whole approach it follows. However, there are some points which can be improved in this approach. Let's talk about them.

Imagine that we have profile page for authenticated user. It has navigation menu with a set of links: "Home", "Profile", "Messages". Typical page class will look like this:

class ProfilePage

  def click_home_link
    @browser.find_element(:id => 'home_link').click

  def click_profile_link
    @browser.find_element(:id => 'profile_link').click

  def click_messages_link
    @browser.find_element(:id => 'message_link').click

end # ProfilePage

Home and Messages pages are rather different page, but still have navigation menu. So they should have the same set of methods. We shouldn't duplicate code, so we need to extract these methods into a separate module.


Little cheat to speed up your WebDriver tests

While most examples for Selenium WebDriver use creating new instance of browser on setUp() and closing it on tearDown(), it is not that fast really. So, in most cases, you only need to clear cookies and open homepage. Fortunately, WebDriver allows this. Such a little cheat will significantly decrease the time your tests take to run.

You can clear cookies by driver.manage.delete_all_cookies (Ruby bindings). In Watir-WebDriver there is also cute clear_cookies() method. Just create a new instance of WebDriver before all the tests and clear cookies in setUp(). That's it.


Continuous integration for iOS app with Cucumber, Frank and Bamboo

It's been a while since I had written latest post and it's just because I have too little time and too little readers, so I wasn't sure it worthies spending time. But after this post by Marlena Compton I've decided to keep it on.

So, this post is about building continuous integration for iOS application with Cucumber + Frank as acceptance testing framework and Bamboo as CI server.


User-Agent in padBuster.pl

Quick note for those, who perform penetration testing of ASP.NET applications and try to exploit Padding Oracle Attack with padBuster.pl, but always receive 403 Forbidden response from either WebResource.axd or ScriptResource.axd. This is most probably because of incorrect User-Agent or, actually, it's absence. To fix, you need to add user-agent to LWM. Just change the following code of makeRequest() function from
$lwp = LWP::UserAgent->new(env_proxy => 1,
                            keep_alive => 1,
                            timeout => 30,
       requests_redirectable => [],
$lwp = LWP::UserAgent->new(env_proxy => 1,
                            keep_alive => 1,
                            timeout => 30,
       requests_redirectable => [],
                            agent => 'Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110406 Firefox/4.0',
or whatever UA you need.
I actually think this should be added to padBuster.pl as an option.


Continuos Integration of Android apps

While looking for a way to implement this, I've found several how-tos, but they all used Maven, which didn't look great for me for several reasons. That's why I decided to set it up with myself. Here is the short manual if you are interested.
  1. Install Apache Ant
  2. Install Android SDK and its components (Tools and Platform Tools)
  3. Install Jenkins (formerly Hudson)
  4. Install Android Emulator Plugin for Jenkins and configure it with path to Android SDK
  5. Install Python Plugin for Jenkins
  6. Download android-junit-report.jar and place it to your tests lib/ directory (we need this as long as default Android test-runner doesn't generate XML report needed by Jenkins).
  7. Download build script and change variables section to fit your project (directories to application and tests, path to Android SDK, target version of Android, package name, use emulator or real device etc.). You don't need to add any modifications to AndroidManifest.xml or create build.xml - script will do this for you
  8. Create new job
  9. Add Python script as build step and paste modified version of build script there
  10. Try it!
That's supposed to be all. If you have any problems, feel free to comment/open issues at GitHub. Hope this will help you.


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.