In un mondo ideale, e per fortuna questo pazzo universo sembra molto lontano dall’esserlo, due cose succederebbero oggi:

• la Germania non avrebbe distrutto il Brasile in una semifinale mondiale per 7-1
• tutto il mondo farebbe safe coding, applicherebbe tutte le best practice in tema di sviluppo sicuro, farebbe un paio di code review prima del rilascio ed un penetration test approfondito.

Nel mondo reale, possiamo impazzire cercando di sensibilizzare gli sviluppatori che lavorano con noi ai temi a noi più cari, ma possiamo anche dar loro una piccola ricetta veloce, tipo quelle della Parodi, da applicare per mitigare alcuni dei rischi legati al codice insicuro.

Rullo di tamburi: i secure headers

5 header HTTP in più, 5 problemi in meno

Ormai il browser è diventato il programma che la gente usa di più. Tutti i vendor hanno alle spalle un team di security con i controfiocchi dedicato alla sicurezza della navigazione web ed il browser, con i suoi aggiornamenti settimanali, è il componente più gestito di tutta la nostra postazione di lavoro.

A partire da un paio d’anni organismi standard come l’IETF, il w3c o vendor in autonomia hanno introdotto delle aggiunte al protocollo HTTP affinché si proteggesse più efficacemente il browser dell’utente.

La gemma secure_headers

La gemma secure_headers è stata sviluppata dal team di application security di twitter per introdurre gli header di cui sopra nel loro social network.

Era il 2011 infatti quando un DOM based XSS fece proliferare a suon di retweet un cross site scripting a catena come se si trattasse di un worm. Da allora una prima contromisura fu l’introduzione di sicurezza proattiva lato client.

La gemma si installa o direttamente o inserendola nel Gemfile dell’applicazione web e attraverso l’esecuzione del comando bundle install.

Una volta installata, creiamo un file config/initializers/secure_headers.rb dove mettiamo la configurazione iniziale della gemma che sarà caricata in automatico da rails allo startup dell’applicazione.

::SecureHeaders::Configuration.configure do |config|
  config.hsts = {:max_age => 20.years.to_i, :include_subdomains => true}
  config.x_frame_options = 'DENY'
  config.x_content_type_options = "nosniff"
  config.x_xss_protection = {:value => 1, :mode => 'block'}
  config.csp = {
    :default_src => "https://* self",
    :frame_src => "https://*",
    :img_src => "https://*",
    :report_uri => '//antani.com/uri-directive'
  }
end

Ora abilitiamo i secure_headers modificando il file application_controller.rb:

class ApplicationController < ActionController::Base
  # Probabilmente questa riga ci sarà già, serve per proteggervi dai cross site
  # request forgery. Se manca, aggiungetela.
  protect_from_forgery with: :exception
  ensure_security_headers
end

In automatico saranno aggiunti agli header di risposta, le impostazioni di security che abbiamo specificato nel nostro file di configurazione.

Come tutte le cose che hanno a che fare con il virtual patching, ad esempio l’uso di WAF come mod_security, questo non si sostituisce alla scrittura di codice sicuro, è un di più.

Nel caso voi scriviate codice Java, vi rimando al progetto highlines che imposta gli header di security per voi.

Off by one

Grazie ai secure headers, avete la possibilità di mitigare al volo alcune problematiche di security in attesa che implementiate hardening nel vostro codice, seguendo una delle linee guida di sviluppo sicuro che avete sulla scrivania.

Partite da qui, create una buona content security policy ed implementate il filtro anti cross site scripting e poi dedicate il vostro tempo a capire come rendere la vostra applicazione web più sicura.

Se non avete una linea guida per i vostri sviluppi in Rails, Sinatra o Padrino potete richiedermene una custom tutta per voi o potete aspettare la pubblicazione della Owasp Ruby on Rails and friends security guide

Enjoy it!