At Qredo we are very strict about handling credentials, including the ones for SMTP, which in Rails projects are normally stored in config/environments/development.rb, config/environments/production.rb, etc. Trying to read Rails.application.secrets from those files doesn’t work, because they are loaded before the secrets, so, we came up with this alternative solution.

The environment files that need to use SMTP for delivering email have this common configuration:

Share:

Like this:

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:

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.

Share:

Like this:

We tend to be very security conscious at Carousel Apps and one thing we often do is force all our applications to run over TLS (aka SSL), that is, when you go to http://example.com we redirect you to https://example.com. This little article will show you how to do it in a Luminus application.

That library provides various Ring middleware functions to deal with SSL. The first one you care about is wrap-ssl-redirect that will cause an HTTP request to be redirected to the equivalent HTTPS one.

In your middleware.clj file, find the function wrap-base which will look something like:

Redirecting to SSL should happen as early as possible to avoid leaking any information over a non-secure channel. With that code you’ll immediately run into trouble when running your project locally, because neither your development environment nor your test one are likely to support TLS, so you’ll get redirected to HTTPS and it won’t work.

That’s easy to solve by creating a function, let’s call it enforce-ssl , that will skip the enforcement when developing or testing:

The function wrap-ssl-redirect obviously checks whether you are already accessing the site over SSL and if that’s the case, it doesn’t redirect you; otherwise you’d have a redirect loop.

If your application is sitting behind a proxy or a load balancer, like in the case of Heroku, Linode’s Load Balance, AWS Elastic Load Balancing, etc. the proxy will be terminating the HTTPS connection and then it’ll issue an HTTP (non-S) connection to your application because since now you are in an internal secure network, encryption is no longer required and HTTP is faster. Thus, your application after forwarding to HTTPS will still receive connections to HTTP and forward again and it’ll be stuck in an infinite forwarding loop.

The convention for this situation is that those proxies will add the header X-Forwarded-Proto with the original protocol, either http or https. There’s another middleware function called wrap-forwarded-scheme that will look at X-Forwarded-Proto (or another header entry of your choosing) and set that as the actual scheme in the request so a simple check for http or https would suffice:

Doing the scheme forwarding should be the first thing you do, so that wrap-ssl-redirect can use the correct scheme.

IMPORTANT: if your application is not behind a trusted proxy, or the proxy is using a different header, then blindly applying wrap-forwarded-scheme would be dangerous as your application could be easily deceived into believing a connection is secure which would enable a man‐in‐the‐middle attack.

One last thing that we do is add wrap-hsts which makes sure the browser from now on will only use HTTPS for this domain, even if the user types http (which would result in a redirect anyway). The final code looks like this:

Share:

Like this:

There’s a gem called bundler-audit that checks whether any of the gems in your project have open security advisors against them. A year or so ago there was an infamous month in which Rails itself got three of those. It was terrible and I think bundler-audit is a good idea. My only problem with it is having to remember to run it: it just won’t happen. I need to run it automatically and an easy way to do that is to run it as part of my tests.

Unfortunately, bundler-audit doesn’t make it easy. It’s designed for the command line and that’s it, but these days it’s easier than a year ago and I recommend everybody to add them to their integration tests. Here’s how we do it at Watu:

require "test_helper"
require "bundler/audit/database"
require "bundler/audit/scanner"
class SecurityTest < ActionDispatch::IntegrationTest
should "not have any vulnerable gems" do
Bundler::Audit::Database.update!
scanner = Bundler::Audit::Scanner.new
scanner.scan do
raise "There are vulnerable gems in your Gemfile. Run bundle-audit check to know more"
end
end
end

I don’t try to show the vulnerable gems because I found those methods to not be easily reusable and I didn’t want to copy them because they look like they might change at any moment. It’s not a big problem, if something is wrong, you should run bundle-audit check anyway.

Share:

Like this:

This article is like a third edition to “Encrypted home in Ubuntu (or Kubuntu… or Debian…)”, although I keep changing the name. It’s the 8.10 edition. Many things changed and I updated the article for those, and the rest should work as well.

Motivation

Every day we put more and more personal information on our computers, and our computers become lighter, smaller, more mobile. In other words, the importance of the information gets higher and the possibility of being loosed or stolen gets higher as well.

Share:

Like this:

This article is like a second edition to Encrypted home in Ubuntu (or Kubuntu… or Debian…). Important changes include that I have tested it for Ubuntu 7.04 Feisty Fawn and it works, but the devices are sd instead of hd due to all hard disk being viewed as SCSI (I am not sure why). Also I corrected some text layout problems of the previous article and I am no longer targeting Debian. Since Debian 4.0 Etch encrypting the whole file system (but /boot) is trivial because it is supported on the install, so you are not likely going to need this. Also, it seems more and more Ubuntu is taking a different direction than Debian so we may start to find big differences and I am not going to test this on Debian. Continue reading “Encrypted home in Ubuntu (or Kubuntu… or Xubuntu…)”

Share:

Like this:

The explanations you’ll find here have been tested with Ubuntu 6.10 (Edgy Eft) and Kubuntu 6.10 (Edgy Eft), they should work without any problem in other members of the Ubuntu family and with minimal changes in other Debian-based distributions like Debian itself or Mepis. In other distributions it might require even more changes.Continue reading “Encrypted home in Ubuntu (or Kubuntu… or Debian…)”