Rails: protezione contro l'iniezione di codice e XSS

21

Ho iniziato a utilizzare Ruby on Rails e mi chiedevo se ci fossero dei trucchi di sicurezza da tenere in considerazione con Rails, in particolare per quanto riguarda l'iniezione di codice e XSS?

So che Rails cerca di prevenire tali attacchi disinfettando gli input, ma immagino che questo non possa essere infallibile.

    
posta Magnus 11.11.2010 - 22:31
fonte

2 risposte

11

Rails 3 ha alcune buone protezioni attivate di default che cattureranno molti problemi di sicurezza comuni.

La codifica in uscita specifica aiuterà a mitigare gli attacchi XSS, i token CSRF sono abilitati di default su tutti i moduli che dovrebbero aiutare in questo caso, e fintanto che lo usi correttamente ActiveRecord o altri ORM possono aiutare a mitigare l'iniezione SQL.

Sul fronte della convalida dell'input ci sono ovviamente alcune cose da tenere d'occhio. Rails non eseguirà la convalida dell'input per impostazione predefinita, quindi se i dati immessi nell'app vengono trasferiti ad altre applicazioni Web, il rischio di attacchi XSS è ancora presente.

Detto questo, Rails supporta le convalide nel modello e, se possibile, ti consiglierei di eseguire la convalida della white-list degli input.

Sul fronte di iniezione SQL, è ancora possibile utilizzare SQL raw con ActiveRecord e, se lo fai, possono verificarsi i soliti problemi con SQL injection, quindi è ancora utile la convalida di tutti gli input di white-list.

Oltre a ciò ci sono ancora molte cose da guardare. l'installazione di Rails di base non fornisce autorizzazione / autenticazione, quindi deve provenire da un plug-in o essere scritta dallo sviluppatore.

Uno svantaggio degli URL stile RESTful che un'app per rails tipicamente produce è che di solito è facile per un utente malintenzionato cercare di violare l'autorizzazione modificando l'URL. Ad esempio un URL di link che mostra il primo utente, potrebbe essere facilmente modificato per avere un 2 o più. Non è che sia meno sicuro, ma rende più facile agli aggressori tentare di aggirare i controlli di autorizzazione.

Ci sono un paio di buone fonti di informazione per la sicurezza di Rails che vale la pena leggere per ulteriori informazioni.

La guida alla sicurezza delle guide di OWASP è qui e c'è anche un libro Security on Rails di Pragmatic Programmers che sebbene si concentri su Rails 2.3 ha ancora molte buone informazioni da considerare (notare che Security on Rails è ora fuori stampa).

    
risposta data 11.11.2010 - 23:05
fonte
11

Il OWASP XSS Cheat Sheet è un'ottima risorsa per comprendere tutti i modi in cui può accadere l'XSS :

  • REGOLA # 0 - Non inserire mai dati non attendibili eccetto nelle posizioni consentite
  • REGOLA # 1 - Escape HTML prima di inserire dati non attendibili nel contenuto dell'elemento HTML
  • REGOLA # 2 - Fuga di attributi prima di inserire dati non attendibili in attributi comuni HTML
  • REGOLA # 3: fuga JavaScript prima di inserire dati non attendibili nei valori dei dati JavaScript HTML
  • REGOLA # 4 - Escape CSS prima di inserire dati non attendibili nei valori delle proprietà dello stile HTML
  • REGOLA # 5: fuga dell'URL prima di inserire dati non attendibili nei valori dei parametri URL HTML
  • REGOLA # 6: utilizzare un motore di criteri HTML per convalidare o pulire l'HTML guidato dall'utente in un modo in uscita
  • REGOLA # 7 - Impedisci l'XSS basato su DOM

Non tutte le regole sopra riportate sono gestite automaticamente da Rails e dipendono dalla versione:

Rails 3.x="Se una stringa semplice viene passata in un <% =% & gt ;, Rails lo scappa sempre"
Rails 2.x = Devi usare il metodo h () (o usare qualcosa come Cross Site Sniper o Safe Erb )

La lista bianca domina il giorno: se prevedi un'abbreviazione postale di due lettere, utilizza le convalide per accettare solo quella.

Guida alla sicurezza generale: link

    
risposta data 11.11.2010 - 23:34
fonte

Leggi altre domande sui tag