Prevenire problemi di sicurezza in Rails

La sicurezza è una delle principali preoccupazioni per qualsiasi sviluppatore che aspira allo sviluppo sostenibile e di successo delle applicazioni web. Ogni sviluppatore desidera codificare in modo tale che le proprie applicazioni siano il più sicure possibile da qualsiasi attacco, tuttavia, nessun codice può essere privo di bug o protetto. Pertanto, gli sviluppatori sono consapevoli che devono fare del loro meglio per rendere le loro applicazioni con la minima vulnerabilità agli attacchi. Rilevare le vulnerabilità è semplice, ma le violazioni della sicurezza e gli attacchi hacker potrebbero comportare perdite. Questo è il motivo per cui è sempre meglio verificare la presenza di problemi di sicurezza fin dall'inizio del processo di sviluppo dell'applicazione, oltre a condurre controlli di qualità regolari per mantenere le cose sulla buona strada.

1] Sessioni

Un buon punto di partenza per valutare la sicurezza sono le sessioni, che possono essere vulnerabili a determinati attacchi.

sessione[:user_id] = @current_user.id Utente.find(session[:user_id])

– Per impostazione predefinita, Ruby on Rails utilizza un archivio di sessione basato su cookie. Ciò implica che, a meno che non venga modificato qualcosa, la sessione non scadrà sul server. Ciò significa quindi che non dovremmo mai conservare dati sensibili come password, ID, ecc. nelle sessioni.
– La procedura migliore quindi è lavorare con una sessione basata su database, il che è molto semplice con Rails –

Progetto::Application.config.session_store :active_record_store
L'ID sessione è una stringa esadecimale casuale di 32 caratteri.

L'ID di sessione viene generato utilizzando SecureRandom.hex che genera una stringa esadecimale casuale utilizzando uno qualsiasi dei metodi specifici della piattaforma come OpenSSL, /dev/urandom o Win32, per generare numeri casuali crittograficamente sicuri. Attualmente non è possibile effettuare attacchi di forza bruta, ovvero tentativi ed errori, sulle credenziali di accesso negli ID di sessione di Rails.

Ecco alcuni degli attacchi più comuni basati sulla sessione:
Dirottamento della sessione: consente agli aggressori di rubare l'ID di sessione di un utente e utilizzare l'applicazione Web a nome della vittima.
Correzione della sessione: - Oltre a rubare l'ID di sessione di un utente, l'aggressore è anche in grado di correggere un ID di sessione a lui noto. Questo è chiamato fissazione della sessione.
Scadenza della sessione: - Gli aggressori tentano anche di aumentare la durata dell'attacco con sessioni che non scadono mai. Gli attacchi come cross-site request forgery (CSRF), session hijacking e session fixation ne sono esempi.

2] Comando Iniezione

Un'applicazione diventa vulnerabile al command injection nel caso in cui l'aggressore sia in grado di influenzare i parametri della riga di comando o i comandi Unix nel loro complesso. Tuttavia, poiché l'esecuzione dei comandi UNIX in Rails non è comune, è meno probabile che questi attacchi abbiano luogo.
D'altro canto, possono verificarsi vulnerabilità in un processo in background che utilizza direttamente i comandi Unix per i dati del cliente.

Ecco alcuni dei metodi comuni della riga di comando di Rails:
%x[…]
sistema()
exec()
`…`
Va inoltre notato che esistono più modi per concatenare i comandi, ma ciò dipende anche dal sistema operativo host. Esempi: “&”, “&&”, “|”, “||” eccetera.
Variabili di ambiente protette durante l'esecuzione dei comandi
I processi eseguiti dalle tue applicazioni ferroviarie ottengono le variabili di ambiente dei processi principali che possono comprendere chiavi API, ecc.

3] Iniezione SQL

L'SQL injection avviene quando un utente è in grado di manipolare un valore che viene utilizzato in modo non sicuro all'interno di una query SQL. Ciò può comportare perdita di dati, fughe di dati, privilegi elevati tra gli altri risultati indesiderati.

L'SQL injection è un attacco molto semplice e comune che di solito si verifica e il suo impatto può essere molto grave a seconda del sito Web e della situazione in cui si verifica.

Come sviluppatori dovremmo occuparci di tutte quelle possibilità in cui può verificarsi l'iniezione SQL e dovremmo gestire le stesse di conseguenza.

Ecco come appare SQL Injection:

Employee.all(:condizioni => "designazione = #{params[:designazione]}")

Il codice sopra riportato è vulnerabile all'SQL injection, il codice seguente impedirà l'SQL injection.

Employee.all(:condizioni => ['designazione = ?', params[:designazione]])

O

Employee.all(:conditions => {:designation => params[:designation]})

Contromisure contro SQL Injection in Rails

Testare ogni istruzione per l'iniezione SQL può essere un lavoro noioso, ma dovremmo prendere alcune contromisure come uno scanner di codice statico come Brakeman e puoi scrivere alcuni casi di test unitari.
a)Regola generale:– Non utilizzare mai i parametri nell'inflessione delle stringhe (#{}) in questo modo
Per esempio

User.where("nome = '#{params[:nome]}'")

b)Attenzione che params può essere anche un array, ad esempio:

params[:user] se aggiungi ?user[]=1 all'URL. Utente.esiste? params[:utente] eseguirà quindi la query SELECT 1 AS one FROM “users” WHERE (1) LIMIT 1.

4] Scripting incrociato (XSS)

Con l'aiuto di XSS, un utente malintenzionato può eseguire script nel contesto di sicurezza della tua applicazione web.

Considera questo snippet di visualizzazione di Rails: <%= @flat.title %>. Se il titolo del flat viene modificato insieme all'aggiunta dell'HTML, questa vista di Rails esegue il rendering dell'HTML nel contesto di sicurezza dell'applicazione. Pertanto, il browser eseguirà l'HTML, che è XSS.

In effetti, questo non funziona ancora in Rails al giorno d'oggi, nella versione 2 di Rails ti verrebbe richiesto di eseguire l'escape di ogni singolo input dell'utente: <%= h(@flat.title) %>
Al giorno d'oggi, rails viene fornito con un flag su ogni stringa che la contrassegna come HTML, sicura o meno: @flat.title.html_safe?. Nel caso in cui non sia sicuro (ad esempio da un parametro, dal database, ...), verrà automaticamente escape mentre lo si utilizza in questo modo: <%= @flat.title %>
In Rails 3.0 la protezione contro XSS è un comportamento predefinito.

Contromisure

a) Una strategia di politica di sicurezza dei contenuti (CSP).

Una sicurezza dei contenuti Politica è fondamentalmente sotto forma di un'intestazione HTTP e questo fa una dichiarazione delle regole su ciò che tutte le fonti sono consentite per tutti i tipi di risorse. Come conseguenza del rispetto di queste regole, tutto il resto non è consentito. Una volta implementato in modo appropriato, è in grado di eliminare tutte le vulnerabilità Cross-Site-Scripting (XSS) nella tua app.

b) HTML-Safe, ActiveSupport::SafeBuffer

Il modulo ActiveSupport::SafeBuffer è stato introdotto da Rails 3 per aggiungere un flag HTML-safe alle stringhe. Per impostazione predefinita, è falso, soprattutto quando la stringa ha un'origine esterna come il database o i parametri. Il flag viene restituito con "string".html_safe?.

Il metodo di escape HTML h(), esegue l'escape della stringa contrassegnando una stringa come sicura per HTML.

h("html>").html_safe? #=> vero ("html>").html_safe? #=>falso

c) Prevenzione XSS OWASP (Open Web Application Security Project).

Per prevenire XSS, tutti i dati non attendibili devono essere negati e impedito di essere inseriti direttamente nell'HTML o in qualsiasi altro contesto (come JavaScript, CSS, contesti di attributi).

d) Protezione XSS nei templi HAML

Durante l'utilizzo dei modelli Haml, anziché ERB, le stringhe vengono automaticamente sottoposte a escape allo stesso modo dei modelli ERB. E allo stesso modo dei modelli ERB, le stringhe sicure per HTML (string.html_safe? restituisce true) non vengono saltate automaticamente. La notazione != in Haml funziona nello stesso modo in cui <%= raw(…) %> funziona in ERB, quindi rende la versione senza escape.
Per impostazione predefinita,

=" sottolineato " != " sottolineato "

compila in:

sottolineato sottolineato

Quindi è necessario prestare attenzione durante l'utilizzo di != in Haml e assicurarsi che nessun dato utente venga reso senza caratteri di escape.
Di seguito sono riportate alcune misure preventive che possono essere prese in considerazione durante lo sviluppo dell'applicazione ferroviaria.

1] Autenticazione

Utilizza il dispositivo o la gemma Authlogic.
– Per abilitare l'autenticazione, non dimenticare di aggiungere ->

classe ProjectController <ApplicationController
prima_filtro:authenticate_user
– Per impostazione predefinita Devise richiede solo 6 caratteri per una password. Il minimo può essere modificato in: /config/initializers/devise.rb
config.password_length = 8..128
– È possibile modificare la complessità della password aggiungendo il seguente codice nel modello utente.

convalidare: complessità_password def complessità_password if password.present? e non password.match(/\A(?=.*[az])(?=.*[AZ])(?=.*\d).+\z/) errori.add :password, "deve includere almeno una lettera minuscola, una lettera maiuscola e una cifra" end end

2] Riferimento diretto a oggetti non sicuri o navigazione forzata

– Le app Ruby on Rails utilizzano una struttura URL riposante che rende i percorsi utilizzati per lo più indovinabili e intuitivi. Pertanto, per proteggersi da un utente che tenta di accedere o modificare i dati che appartengono a un altro utente, le azioni devono essere controllate in modo specifico. Non esiste un tipo di protezione integrato di questo tipo su un'applicazione Rails vanilla. Inoltre, può essere eseguita manualmente a livello di controller.
– Utilizzare cancancan o pandit per il controllo degli accessi

3] Assegnazione di massa e parametri forti

- class Project < ActiveRecord::Base attr_accessible :name, :admin end

Secondo l'esempio sopra, con l'attributo admin accessibile, potrebbe funzionare quanto segue:
– curl -d “progetto[nome]=triage&progetto[admin]=1” host:porta/progetti
– config.active_record.whitelist_attributes = true

4] Reindirizzamenti e inoltri

– Si consiglia di evitare di utilizzare i reindirizzamenti che utilizzano parametri
Ad esempio:- //www.example.com/redirect?url=//www.example_commerce_site.com/checkout
– la protezione restrittiva consiste nell'utilizzare :only_path

inizio se percorso = URI.parse(params[:url]).percorso reindirizzamento_al percorso fine salvataggio URI::InvalidURIError reindirizzamento_a '/' fine

– Avere hash dei siti approvati e consentire solo a loro di essere reindirizzati.

5] Percorsi di rendering dinamici

– È necessario prestare attenzione quando si esegue il rendering dinamico di qualsiasi vista in base a determinate condizioni. Potrebbe comportare il caricamento della vista amministratore.

6] Condivisione delle risorse tra origini

– Come il caricamento di file.
– Il sito ricevente dovrebbe limitare e consentire solo i domini autorizzati e assicurarsi che le richieste provengano solo da tali domini.
– Imposta anche l'intestazione Access-Control-Allow-Origin sia nella risposta alla richiesta OPTIONS che alla richiesta POST. Questo perché la richiesta OPTIONS viene inviata per prima, per determinare se il sito remoto o ricevente consente il dominio richiedente.
– Viene inviata una richiesta POST. Ancora una volta, l'intestazione deve essere impostata affinché la transazione venga visualizzata come avvenuta con successo.

7] Bug della logica aziendale

– Le applicazioni, indipendentemente dalla tecnologia su cui si basano, possono contenere errori di logica aziendale che possono portare a bug di sicurezza. Può essere davvero complicato rilevare tali bug di sicurezza utilizzando gli strumenti automatizzati. Pratiche come revisioni regolari dei codici, programmazione in coppia e scrittura di test unitari possono aiutarti a evitare che si verifichino tali bug di sicurezza.

8] File sensibili

Di seguito sono riportati alcuni file di cui dovremmo occuparci durante lo sviluppo di un'applicazione web.
/config/database.yml- Può contenere credenziali di produzione.
/config/initializers/secret_token.rb – Contiene un segreto utilizzato per eseguire l'hash del cookie di sessione.
/db/seeds.rb – Può contenere dati seed incluso l'utente amministratore bootstrap.
/db/development.sqlite3 – Può contenere dati reali.

9] Crittografia

Ruby on Rails utilizza la crittografia del sistema operativo. Non dovresti quasi mai scrivere le tue soluzioni per la crittografia.
Aggiornamento dei binari e disponibilità di un processo per l'aggiornamento delle dipendenze.

Strumenti per rilevare problemi di sicurezza nelle applicazioni ferroviarie

• Frenatore
• audit del bundler
• Coda in codice::Alba
• Rack::Attacco
• Tarantola
• Cintura degli attrezzi Hakiri