{"id":27233,"date":"2017-10-31T14:05:41","date_gmt":"2017-10-31T14:05:41","guid":{"rendered":"https:\/\/dev.railscarma.com\/preventing-security-issues-rails\/"},"modified":"2022-09-06T09:26:04","modified_gmt":"2022-09-06T09:26:04","slug":"prevenire-problemi-di-sicurezza-sui-binari","status":"publish","type":"post","link":"https:\/\/www.railscarma.com\/it\/blog\/articoli-tecnici\/prevenire-problemi-di-sicurezza-sui-binari\/","title":{"rendered":"Prevenire problemi di sicurezza in Rails"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

La sicurezza \u00e8 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\u00f9 sicure possibile da qualsiasi attacco, tuttavia, nessun codice pu\u00f2 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\u00e0 agli attacchi. Rilevare le vulnerabilit\u00e0 \u00e8 semplice, ma le violazioni della sicurezza e gli attacchi hacker potrebbero comportare perdite. Questo \u00e8 il motivo per cui \u00e8 sempre meglio verificare la presenza di problemi di sicurezza fin dall'inizio del processo di sviluppo dell'applicazione, oltre a condurre controlli di qualit\u00e0 regolari per mantenere le cose sulla buona strada.<\/p>

1] Sessioni<\/strong><\/h3>

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

sessione[:user_id] = @current_user.id Utente.find(session[:user_id])<\/code><\/pre>
\u2013 Per impostazione predefinita, Ruby on Rails utilizza un archivio di sessione basato su cookie. Ci\u00f2 implica che, a meno che non venga modificato qualcosa, la sessione non scadr\u00e0 sul server. Ci\u00f2 significa quindi che non dovremmo mai conservare dati sensibili come password, ID, ecc. nelle sessioni.
\u2013 La procedura migliore quindi \u00e8 lavorare con una sessione basata su database, il che \u00e8 molto semplice con Rails \u2013<\/p>
Progetto::Application.config.session_store :active_record_store
L'ID sessione \u00e8 una stringa esadecimale casuale di 32 caratteri.<\/p>
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 \u00e8 possibile effettuare attacchi di forza bruta, ovvero tentativi ed errori, sulle credenziali di accesso negli ID di sessione di Rails.<\/p>
Ecco alcuni degli attacchi pi\u00f9 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 \u00e8 anche in grado di correggere un ID di sessione a lui noto. Questo \u00e8 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.<\/p>
2] Comando Iniezione<\/strong><\/h3>
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\u00e9 l'esecuzione dei comandi UNIX in Rails non \u00e8 comune, \u00e8 meno probabile che questi attacchi abbiano luogo.
D'altro canto, possono verificarsi vulnerabilit\u00e0 in un processo in background che utilizza direttamente i comandi Unix per i dati del cliente.<\/p>
Ecco alcuni dei metodi comuni della riga di comando di Rails:
%x[\u2026]
sistema()
exec()
`…`
Va inoltre notato che esistono pi\u00f9 modi per concatenare i comandi, ma ci\u00f2 dipende anche dal sistema operativo host. Esempi: \u201c&\u201d, \u201c&&\u201d, \u201c|\u201d, \u201c||\u201d 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.<\/p>
3] Iniezione SQL<\/strong><\/h3>
L'SQL injection avviene quando un utente \u00e8 in grado di manipolare un valore che viene utilizzato in modo non sicuro all'interno di una query SQL. Ci\u00f2 pu\u00f2 comportare perdita di dati, fughe di dati, privilegi elevati tra gli altri risultati indesiderati.<\/p>
L'SQL injection \u00e8 un attacco molto semplice e comune che di solito si verifica e il suo impatto pu\u00f2 essere molto grave a seconda del sito Web e della situazione in cui si verifica.<\/p>
Come sviluppatori dovremmo occuparci di tutte quelle possibilit\u00e0 in cui pu\u00f2 verificarsi l'iniezione SQL e dovremmo gestire le stesse di conseguenza.<\/p>
Ecco come appare SQL Injection:<\/p>
Employee.all(:condizioni => "designazione = #{params[:designazione]}")<\/code><\/pre>
Il codice sopra riportato \u00e8 vulnerabile all'SQL injection, il codice seguente impedir\u00e0 l'SQL injection.<\/p>
Employee.all(:condizioni => ['designazione = ?', params[:designazione]])<\/code><\/pre>
O<\/p>
Employee.all(:conditions => {:designation => params[:designation]})<\/code><\/pre>
Contromisure contro SQL Injection in Rails<\/strong><\/h5>
Testare ogni istruzione per l'iniezione SQL pu\u00f2 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:<\/strong>\u2013 Non utilizzare mai i parametri nell'inflessione delle stringhe (#{}) in questo modo
Per esempio<\/p>
User.where("nome = '#{params[:nome]}'")<\/code><\/pre>
b)Attenzione che params pu\u00f2 essere anche un array, ad esempio:<\/strong><\/p>
params[:user] se aggiungi ?user[]=1 all'URL. Utente.esiste? params[:utente] eseguir\u00e0 quindi la query SELECT 1 AS one FROM \u201cusers\u201d WHERE (1) LIMIT 1.<\/p>
4] Scripting incrociato (XSS)<\/strong><\/h3>
Con l'aiuto di XSS, un utente malintenzionato pu\u00f2 eseguire script nel contesto di sicurezza della tua applicazione web.<\/p>
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\u00e0 l'HTML, che \u00e8 XSS.<\/p>
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\u00e0 automaticamente escape mentre lo si utilizza in questo modo: <%= @flat.title %>
In Rails 3.0 la protezione contro XSS \u00e8 un comportamento predefinito.<\/p>
Contromisure<\/strong><\/h3>
a) Una strategia di politica di sicurezza dei contenuti (CSP).<\/strong><\/p>
Una sicurezza dei contenuti Politica<\/a> \u00e8 fondamentalmente sotto forma di un'intestazione HTTP e questo fa una dichiarazione delle regole su ci\u00f2 che tutte le fonti sono consentite per tutti i tipi di risorse. Come conseguenza del rispetto di queste regole, tutto il resto non \u00e8 consentito. Una volta implementato in modo appropriato, \u00e8 in grado di eliminare tutte le vulnerabilit\u00e0 Cross-Site-Scripting (XSS) nella tua app.<\/p>
b) HTML-Safe, ActiveSupport::SafeBuffer<\/strong><\/p>
Il modulo ActiveSupport::SafeBuffer \u00e8 stato introdotto da Rails 3 per aggiungere un flag HTML-safe alle stringhe. Per impostazione predefinita, \u00e8 falso, soprattutto quando la stringa ha un'origine esterna come il database o i parametri. Il flag viene restituito con "string".html_safe?.<\/p>
Il metodo di escape HTML h(), esegue l'escape della stringa contrassegnando una stringa come sicura per HTML.<\/p>
h("html>").html_safe? #=> vero ("html>").html_safe? #=>falso<\/code><\/pre>
c) Prevenzione XSS OWASP (Open Web Application Security Project).<\/strong><\/p>
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).<\/p>
d) Protezione XSS nei templi HAML<\/strong><\/p>
Durante l'utilizzo dei modelli Haml, anzich\u00e9 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(\u2026) %> funziona in ERB, quindi rende la versione senza escape.
Per impostazione predefinita,<\/p>
=" sottolineato " != " sottolineato "<\/em><\/em><\/em><\/em><\/code><\/pre>
compila in:<\/p>
sottolineato<\/em> sottolineato<\/em><\/code><\/pre>
Quindi \u00e8 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.<\/p>
1] Autenticazione<\/strong><\/h5>
Utilizza il dispositivo o la gemma Authlogic.
\u2013 Per abilitare l'autenticazione, non dimenticare di aggiungere -><\/p>
classe ProjectController <ApplicationController
prima_filtro:authenticate_user
\u2013 Per impostazione predefinita Devise richiede solo 6 caratteri per una password. Il minimo pu\u00f2 essere modificato in: \/config\/initializers\/devise.rb
config.password_length = 8..128
\u2013 \u00c8 possibile modificare la complessit\u00e0 della password aggiungendo il seguente codice nel modello utente.<\/p>
convalidare: complessit\u00e0_password def complessit\u00e0_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<\/code><\/pre>
2] Riferimento diretto a oggetti non sicuri o navigazione forzata<\/strong><\/h5>
\u2013 Le app Ruby on Rails utilizzano una struttura URL riposante che rende i percorsi utilizzati per lo pi\u00f9 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\u00f2 essere eseguita manualmente a livello di controller.
\u2013 Utilizzare cancancan o pandit per il controllo degli accessi<\/p>
3] Assegnazione di massa e parametri forti<\/strong><\/h5>
- class Project < ActiveRecord::Base attr_accessible :name, :admin end<\/code><\/pre>
Secondo l'esempio sopra, con l'attributo admin accessibile, potrebbe funzionare quanto segue:
\u2013 curl -d \u201cprogetto[nome]=triage&progetto[admin]=1\u201d host:porta\/progetti
\u2013 config.active_record.whitelist_attributes = true<\/p>
4] Reindirizzamenti e inoltri<\/strong><\/h5>
\u2013 Si consiglia di evitare di utilizzare i reindirizzamenti che utilizzano parametri
Ad esempio:- \/\/www.example.com\/redirect?url=\/\/www.example_commerce_site.com\/checkout
\u2013 la protezione restrittiva consiste nell'utilizzare :only_path<\/p>
inizio se percorso = URI.parse(params[:url]).percorso reindirizzamento_al percorso fine salvataggio URI::InvalidURIError reindirizzamento_a '\/' fine<\/code><\/pre>
\u2013 Avere hash dei siti approvati e consentire solo a loro di essere reindirizzati.<\/p>
5] Percorsi di rendering dinamici<\/strong><\/h5>
\u2013 \u00c8 necessario prestare attenzione quando si esegue il rendering dinamico di qualsiasi vista in base a determinate condizioni. Potrebbe comportare il caricamento della vista amministratore.<\/p>
6] Condivisione delle risorse tra origini<\/strong><\/h5>
\u2013 Come il caricamento di file.
\u2013 Il sito ricevente dovrebbe limitare e consentire solo i domini autorizzati e assicurarsi che le richieste provengano solo da tali domini.
\u2013 Imposta anche l'intestazione Access-Control-Allow-Origin sia nella risposta alla richiesta OPTIONS che alla richiesta POST. Questo perch\u00e9 la richiesta OPTIONS viene inviata per prima, per determinare se il sito remoto o ricevente consente il dominio richiedente.
\u2013 Viene inviata una richiesta POST. Ancora una volta, l'intestazione deve essere impostata affinch\u00e9 la transazione venga visualizzata come avvenuta con successo.<\/p>
7] Bug della logica aziendale<\/strong><\/h5>
\u2013 Le applicazioni, indipendentemente dalla tecnologia su cui si basano, possono contenere errori di logica aziendale che possono portare a bug di sicurezza. Pu\u00f2 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.<\/p>
8] File sensibili<\/strong><\/h5>
Di seguito sono riportati alcuni file di cui dovremmo occuparci durante lo sviluppo di un'applicazione web.
\/config\/database.yml- Pu\u00f2 contenere credenziali di produzione.
\/config\/initializers\/secret_token.rb \u2013 Contiene un segreto utilizzato per eseguire l'hash del cookie di sessione.
\/db\/seeds.rb \u2013 Pu\u00f2 contenere dati seed incluso l'utente amministratore bootstrap.
\/db\/development.sqlite3 \u2013 Pu\u00f2 contenere dati reali.<\/p>
9] Crittografia<\/strong><\/h5>
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\u00e0 di un processo per l'aggiornamento delle dipendenze.<\/p>
Strumenti per rilevare problemi di sicurezza nelle applicazioni ferroviarie<\/strong><\/h4>
  • Frenatore<\/li>
  • audit del bundler<\/li>
  • Coda in codice::Alba<\/li>
  • Rack::Attacco<\/li>
  • Tarantola<\/li>
  • Cintura degli attrezzi Hakiri<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t
    Iscriviti per gli ultimi aggiornamenti<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t
    \t\t\t\t\t