Bug di sicurezza nel codice Scala

4

Attualmente sto leggendo "Sicurezza del software: Build Security In" di Gary McGraw, e lui fa la distinzione tra bug di sicurezza e difetti di sicurezza. I bug di sicurezza sono errori di implementazione nel codice e difetti sono più sul lato architettonico / design del software. Scrive come i difetti di sicurezza tendono ad essere intorno a una divisione 50/50 tra bug e difetti.

Tuttavia, questo è stato scritto nel 2006 e menziona linguaggi come C e C ++. Si parla molto di buffer overflow, ad esempio. La mia domanda è questa: quanto è pertinente questo per Scala? Ovviamente i bug nell'implementazione possono ancora causare rischi per la sicurezza, ma avere un linguaggio gestito sulla JVM che controlli i limiti sembra attenuare una vasta classe di bug di cui parla McGraw. È ragionevole affermare che la sicurezza del software, in un linguaggio come Scala, ha spostato maggiormente verso il lato architettonico e logico delle cose? Oppure, per essere più specifici, l'analisi del codice statico in Scala è meno importante per la sicurezza di quanto lo sarebbe per le lingue come C e C ++? In caso contrario, perché no?

    
posta Nathan 12.06.2015 - 21:33
fonte

2 risposte

4

Per quanto riguarda i problemi relativi alla memoria, ci sono ancora problemi, ad es. si può ancora imbattersi in un puntatore nullo, utilizzare un indice di raccolta fuori limite, condividere accidentalmente dati mutabili con altre classi, fare in modo che l'applicazione utilizzi tutta la memoria allocata, o in alcuni casi dove viene utilizzata quasi tutta la memoria e molte nuove gli oggetti temporanei vengono creati, il GC può occupare quasi tutto il tempo di esecuzione, ma la maggior parte di questi sono eccezioni / errori sulla JVM e possono essere gestiti, anche se dovrebbero essere evitati con la configurazione e un'attenta codifica, se possibile.

Inoltre, in scala nulla è disapprovato a favore di Option, e lo stato mutabile a favore di immutabile, quindi con uno stile funzionale idiomatico, i problemi di nullità e mutabilità sono ulteriormente ridotti.

Ci sono alcuni strumenti di analisi statica di scala (disclaimer: io sono il manutentore di Linter), ma non sono sono specializzati per la sicurezza. Detto questo, trovano spesso problemi che causano il crash dell'applicazione a runtime, lo rendono più lento del necessario, o trovano codice che logicamente non ha senso - tutto una potenziale fonte di problemi di sicurezza. Vorrei menzionare Wartremover che presenta controlli che limitano la lingua a un sottoinsieme più sicuro / puro.

Puoi anche usare gli strumenti che vengono eseguiti sul bytecode JVM, ad es. plugin find-sec-bugs per Findbugs. Anche i controlli predefiniti di Findbug funzionano, ma sono attivati dal codice scala generato, quindi ci sono molti falsi positivi. Gli autori del linguaggio guardano questi risultati e correggono se trovano qualcosa, ma sfortunatamente i falsi positivi rendono Findbugs meno utile per il resto di noi.

(Sono molto interessato a sentire se qualcuno ha usato altri strumenti con Scala nei commenti)

    
risposta data 13.06.2015 - 11:37
fonte
3

Sebbene sia giusto dire che i linguaggi gestiti sono meno inclini a certe classi di problemi rispetto alle lingue come c / c ++, esistono ancora diverse classi di bug software che possono essere applicate a Java / Scala e ad altri linguaggi che vengono eseguiti in ambienti gestiti.

Questo può variare da problemi di convalida dell'input come SQL injection e cross-site scripting a problemi di gestione degli errori e uso improprio della crittografia. Una fonte di informazioni è questa tassonomia dei problemi di sicurezza, che mostra una vasta gamma che interessa Java. Ovviamente Scala non soffrirà di tutti gli stessi problemi, ma ti darà l'immagine che le lingue gestite possono ancora beneficiare dell'analisi statica.

    
risposta data 12.06.2015 - 21:52
fonte

Leggi altre domande sui tag