Highlights of the Ekoparty training Security for web developers

At Ekoparty, during the pre-conference days I took the training Security for web developers by Andrés Riancho.

The course was structured following the OWASP Top 10 vulnerabilities.

For each one, the vulnerability was presented, attack vectors shown and a real running example was presented. We attacked it with a tool or by hand and then saw countermeasures.

I summarize here the highlights for a developer with little penetration-testing experience (concepts, techniques and tools):

  • Injections: don’t use blacklists based solutions.
  • ZAP, a tool to discover vulnerabilities in websites. Starting with an initial URL it can, for example, fuzz it or change its parameters to discover XSS or SQL injection vulnerabilities.
  • Once an SQL injection vulnerability is discovered a tool like sqlmap can be used to discover which RDBMS is running on the back end, but this is just the beginning. It contains all the tricks for SQL injections: it can get the whole database schema, run queries, get passwords and even, depending on the RDBMS configuration, provide a remote shell.
    • SQL Injection can be solved/mitigated using prepared statements, ORMs or (not recommended) escaping queries.
  • There are 3 types of XSS: reflected, persisted, DOM.
    • Single Page Applications are prone to DOM-XSS. Suggestion: encode parameters used in document.write. JQuery and other frameworks come with functions for this.
    • XSS consequences go far beyond showing a pop up in the client. For a complete picture check this framework.
  • Cookies:
    • If marked as httpOnly the browser won’t allow it to be read with document.cookie.
    • If marked as secure, cookies aren’t sent via HTTP.
  • Session attacks:
    • Session prediction: don’t use, for example, sequential numbers for session IDs.
    • Session expiration: don’t allow old sessions.
    • Sessions must expire in both client side and server side.
    • Don’t have session tokens in the URL.
  • When using hash functions:
    • Recommended: SHA256, SHA512, PBKDF2.
    • Not recommended: MD5, SHA1.

Picture by Matias Golini

Pablo at Clojure eXchange, London 2015

Our very own Pablo will be presenting at the Clojure eXchange conference on December 3rd, 2015. His talk is titled What is a Macro. The description of the talk is:

Or what makes Lisp, and Clojure, more powerful than other languages. This is an introductory presentation about macros, explaining how to write them, and why they are so much more powerful in Lisps than in non-Lisp languages.

If you are a Clojurian and can get yourself to London, Clojure eXchange promises to be the place to be on early December.

An Accidental Path to Remote Working

Photo of a path symbolising path to remote working

We were never meant to be a remote working team. There was no grand plan to have colleagues spread around the world in incredible cities, but like many great things in life, Carousel App’s path was naturally formed and our feet trod in the direction of remote work. Now, with the team tuning in from Barcelona, Belgrade, Bali and beyond, we are truly a global team united by our laptops.

How It Began

It started with the loss of shared office space which allowed – and led us – to the acquiring of talent that wasn’t based in the same city. Suddenly, no longer having four walls of confinement meant there was newfound freedom to bring together the best team in the world, not just in London.

And almost two years later, remote working has become a core part of company culture. A feature that not just allows us, but encourages us, to be ourselves and reside where we’re happy, work our most productive hours, and live balanced lives. In fact, let’s just say, it allows us to live.

Map of where the Carousel Apps team remotely works

The World of Carousel Apps

And Where Now?

Saying that, we’re new to this club. We’re still working out just how we should be working. How to overcome the challenges of team unity, work flow, project management, and smooth communication, not to mention building real relationships through virtual means. And how exactly to schedule a meeting when one colleague is waking up in Argentina, whilst the other is settling down for the night in Indonesia (we still haven’t quite figured that one out yet)? We’ve dabbled with ideas, registered with various apps, and created our online water cooler hangout zone, but there remains an evolution towards an optimal remote work flow.

Let’s Share the Journey

And so, we’ve decided to share this journey that we take as well as the culture that we create. Part virtual diary, part advice-giving and plenty advice-seeking, stay tuned to keep on top of the apps that we discover, questions that are asked, and take note of our successes and failures along this accidental path. Who knows, maybe you’ll find yourself walking it soon as well.

Picture by Miguel Virkkunen Carvalho

Ekoparty 2015 summary

This October the Ekoparty 2015 security conference took place in Buenos Aires. I’ve been hearing about this event for years, and this time, thanks to the support of Carousel Apps, I decided to participate.

The event had two main parts: training (2 days) and conference/talks (the next 3 days). I registered for one of the training courses (Security for web developers by Andrés Riancho) and the participation of the conference days.

eko11

When I arrived the first morning I was shocked to see a queue of people two blocks long waiting to register. Fortunately I had registered at the end of my training, so I just walked in. I was expecting a total of 500 people in the conference but I was surprised to know that there were more than 2000 participants.

eko11

There were two main spaces in the conference; the stands hall, where sponsors and independent groups have their stands (security companies challenging future employees, free beer, popcorn, weird hardware, free drinks, a table with locks to be cracked using some tools, music, laser lights and many other things to grab your attention), and the main conference room, where the talks took place.

Upon entering the conference room you were delighted by a really great Back to the Future decoration: the back of a life-size DeLorean, time travel boards from the inside of the car, the legendary clock and even the flux capacitor.

eko11

IMG_3420

One of the central topics was e-voting, with a panel including hackers, legislators, lawyers and other interested parties and a specific talk explaining the failures of the e-voting system used in the last elections in the city.

The topics of the talks I enjoyed the most were:

  • How North Korea attacks South Korea.
  • How to clone cellphone cells.
  • How mobiles (Android and iOS) encrypt data on disk.
  • Fuzzing browsers: a guy crafted a file, opened it with Firefox, made it crash and run Windows Calculator.
  • Hacking cars in Latin America: about a problem with Chevrolet cars.
  • Crozono: a drone + a raspberry pi + a Python script: the drone flies near a wifi network, cracks it and using the internet, calls home giving access to the attacker.

IMG_3394 IMG_3531 IMG_3518 IMG_3483 IMG_3445 IMG_3547

My personal conclusion is that Ekoparty is a great place to meet new people and know about new technologies and techniques in an atmosphere of friendship and responsibility.

You can find out more about this edition searching for tweets with the hashtag #eko11.

Pictures by Matias Golini

Announcing Ninja Tools

These days we use tens if not hundreds of web apps for running our businesses:

  • Email: Google Apps for Work, Outlook.
  • Project Management: Trello, Basecamp, Asana.
  • Issue Tracking: Jira, FogBugz, GitHub.
  • Chat: Flowdock, Slack, Hipchat, Speak.
  • Source code hosting: GitHub, Kiln, BitBucket.
  • Error Reporting: Yeller, Bugsnag, Airbrake, Rollbar and a million others.

When it comes to choosing a new app, finding the right one can be very hard. You can play with the app and like it, but if it doesn’t integrate with all your current tools, it won’t be an ideal solution. Enter the Ninja Tools!

You tell Ninja Tools the apps you use, you tell it what you are looking for, and it’ll find the one with the best integrations for you. Furthermore, if you give it your email address it’ll notify you when new applications come up that you might be interested in, as well as perhaps news or security issues with the apps you use.

That’s it, simple, one task, nothing more, one task done well and done for free. Why free? because Ninja Tools is a companion to our Screensaver Ninja product. Screensaver Ninja displays web pages as your screensaver turning your laptop or a dedicated screen into a powerful dashboard system. We want to help our users find the best tools for their organizations, some of which might find their way into Screensaver Ninja.

We are planning to launch in about a month and we could use your help spreading the word. All we ask for is a simple tweet. We created a Thunderclap campaign to make it super simple: you sign up and forget about it. The tweet will go out automatically on release day. That is, only if 100 other people agree to spread the word, otherwise, nothing happens. It’s a bit like Kickstarter but with social media support.

The startup angle is that having a popular companion free product to a paid one can increase sales and this is one of the things we are aiming with Ninja Tools. This is a technique that has been successfully used by many other companies.

There’s also a research angle: we are using new technologies for developing Ninja Tools. It’s our first SPA (Single Page Application) and it’s also our first application build with Clojure and ClojureScript. We are learning, we are making mistakes and we are making them in an application that is not mission critical for anybody and doesn’t contain any confidential information.

We don’t want to keep any of this to ourselves, so, in the process of building this app, we are also producing new open source libraries whenever we find a gap in the Clojure(Script) ecosystem. So far we built:

But that’s not all! Ninja Tools is also open source and you can find it’s source code in GitHub: https://github.com/carouselapps/ninjatools. You can download, run it yourself, learn how we use the libraries we produce and, if we make mistakes, hopefully at least someone else can learn from them.

If you want to be notified of any release or updates, feel free to leave us your contact details:


Picture by Damien McMahon

to-jdbc-uri 0.4.1 released

We just released a new version of to-jdbc-uri, 0.4.1. A very important change in this one is that we are consolidating all our libraries into the com.carouselapps group ID, so you need to switch from including it like this:

to including it like this:

Aside from that, this release supports RedHat OpenShift style of URL that use the schema postgresql:// instead of postgres://. Courtesy of Pradnyesh Sawant.

Picture by Joe Hall

Polishing a gem

Since Watu is an application written using Ruby on Rails, we use a lot of gems. A couple of weeks ago I found a bug in one of these gems. In this situation, the common action is to fix the bug and provide a patch upstream. The problem was that the gem was really out of shape: tests were red, there was a lot of outdated code and it was packaged using Jeweler. So, before fixing the bugs, I took on the job of polishing the gem. These are my gem-agnostic tips for the job:

  • Use bundler to package/manage the gem.
  • If the gem tests are written using a testing tool like RSpec, update the tests to work with the latest stable version of the tool (I migrated from RSpec 2 to RSpec 3 and it wasn’t big deal).
  • Make the gem work with the latest versions of its dependencies (but also support versions widely used by the community).
  • Use appraisal to test the gem against different versions of its dependencies.
  • Use Travis or other continuous integration service to ensure the tests are continuously run after every push against the different versions of dependencies and different Ruby versions. (Tip: you can run this testing matrix locally using wwtd).

After that, the gem is ready for a new release. After the release, you can fix that damned bug.

Picture by Mitch Altman

Don’t forget to clear your client side state when logging a user out

When a user logs out from our web site, we are used to clearing the session and that’s it. When you are developing a single page application, you are likely to keep a lot of state on the client side, and that should be cleared too.

For Ninja Tools, that meant going from the traditional re-frame initialize-db:

to having the initial-db in a re-usable value:

and our logged-out handler to use it instead of modifying the current estate, which meant going from:

to:

Since we care so much about security, for us, it’s important to go back to initial-db, and if there’s some state that should survive, we’ll pass it on manually. That is, we’ll be doing whitelisting vs blacklisting.

Something that we haven’t decided is whether we clear the state on log-out, when the user just clicked the log out link, or logged-out, when when the server has cleared the session.

The advantage of the former is that we clear all the state as soon as possible, the advantage of the later is that should the log out procedure fail for some reason, the app still has the state and it should still be usable, which might be required for re-trying logging out.

Recapping that, clearing state immediately behaves better when everything goes well, clearing state later behaves better when something goes wrong during the log out process. We can’t comment one being safer that the other, as clearing the session earlier and failing to log out might leave the user under the impression they successfully logged out when it’s not the case.

Picture by Ken Hawkins.

Automatically converting case between SQL and Clojure

SQL, at least PostgreSQL, likes using snake case for table names, such as user_name, while in Clojure, kebab case is preferred, such as user-name. When you use the library Yesql you are likely to end up with keywords in snake case unless you do some conversion. In our toy project, Ninja Tools, I wanted to perform these conversions automatically.

To achieve this automatic conversion I wanted to wrap every single function generated by Yesql and do the conversion both ways. This sounded familiar. Dmitri Sotnikov and I came up with a neat trick to do that in Conman, a connection manager for Yesql, that wraps all the Yesql functions binding them to a connection.

This code wraps around the result for Conman but if you just need to do something similar with plain Yesql I’d recommend looking at Conman’s code. Normally, this is how you would use Conman:

and this is the code to do the automatic wrapping to convert case style:

Let me explain what’s going on here. The namespace of the file is ninjatools.db.core. In this namespace we define an atom, conn, to store the connection and then the madness begins.

Line 7 defines another namespace, one that is used to store the original functions created by Conman and which we are not likely to ever access directly. On line 11 we do exactly that, we invoke Conman, and thus Yesql, so the file with the queries is read and turn into a bunch of functions in the ninjatools.db.core.queries namespace. This functions are also returned as a sequence that we are going to iterate over.

In line 12 we call intern to essentially define a function in a different namespace, in this case, the one that matches this file. The name of this new function will be the same as the one defined by Yesql thanks to Clojure’s ability to inspect the meta-data of a function, as we can see in line 13. While we are at it, let’s also make the meta-data be same, just in case.

Since we don’t know how many arguments the function will take, we accept any amount and if there’s more than one, in line 17 we convert the first one from Clojure’s kebab-case to PostgreSQL’s snake_case. The result goest through the reverse process in line 18.

Very important for the sake of the rest of the file, line 19 takes us back to the natural namespace for this file. Neat trick, isn’t it? Obviously it would be better if this wasn’t required a lot, which is the goal of issue 108, “Callback when defining queries”.

Any questions?

Picture by AAB_BAA

Isomorphic JavaScript (with ClojureScript) for pre-rendering single-page-applications, part 3

I was not expecting there to be a part 3 to this series and this third part is also going to be quite different to the first two. In parts 1 and 2 I walked you through an exploration of server side pre-rendering with Nashorn. My naive example worked fine with Nashorn but it didn’t survive encountering the real world.

Nashorn is not a headless browser, it’s a plain JavaScript engine. It doesn’t implement document or window for example, which were easy to workaround, but it also doesn’t implement setTimeout, setInterval or XMLHttpRequest which are much harder to workaround.

When I started to look for alternatives I focused on NodeJS because I knew if implemented those things I was missing and V8‘s speed is attractive. Also, the fact the ClojureScript has it as a compilation target made me feel it was well supported, a first class citizen.

At this point someone might interject and exclaim: What about nodyn.io? nodyn.io is an attempt to bring all the NodeJS goodness to Nashorn and I think it’s a great idea. Sadly, on GitHub we can find this notice:

This project is no longer being actively maintained. If you have interest in taking over the project, please file an issue.

I’m not sure if the project got far before being abandoned either.

Implementing the missing bits of Nashorn in Clojure was tempting. It looks like fun and it also looks like something that might be popular amongst Java users and thus good for the Clojure echo system. I exercised some restrain and moved on.

In the process of experimenting with NodeJS my code quickly took the form of a library and without further ado, let me introduce you to Prerenderer. The ultimate solution for all your server side pre-rendering needs. I’m not going to show you how to use it here because its page go into a lot of detail already.

My big concern about prerendering is performance and stability. As I showed in part 2, a naive implementation can behave horribly while in production, sometimes taking up to 17 seconds to serve a page. Prerenderer was not developed with a sample project, like I did with Nashorn, but with a project we are working on called Ninja Tools that uses re-frame and AJAX. Before any modifications to it, this was its performance:

Ninja Tools performance with no server side rendering

After enabling Prerenderer, this is how it looks like:

Ninja Tools with Prerenderer

The average response time went up from 51ms to 362ms. This would generally be a very bad thing. The reason for this is explained in Prerenderer’s documentation:

[…] SPAs are never done. Imagine a SPA that has a timer and every second sends a request to the server, and the server replies with the current time, which then the application displays. When is it done rendering? Never. But Prerenderer needs to, at some point, decide that the page is done enough and ship it to the browser. […] […] Prerenderer will watch for events and once nothing happened for a period of time (300ms by default) it’ll consider the application done and if a certain amount of time went by (3s by default) even if the application is still active, it’ll stop and send it to the browser.

That’s where the jump in 300ms is coming from and it’s constant. It’s not linear and definitely not exponential. It’s a constant number that can be tuned and tweaked. There are also some potential optimizations to reduce it or remove all together.

The important thing is that all other values remained more or less the same and that the performance characteristics where quite stable. For me, this feels good enough to move on and start producing SPAs and with a bigger codebase we’ll be able to improve this library and make it better.

Picture by Ian Farrel