I linguaggi di programmazione di alto livello presentano più vulnerabilità o rischi per la sicurezza rispetto ai linguaggi di basso livello? [chiuso]

Maggiore avvertimento anticipato:

È possibile essere insicuri in qualsiasi lingua, in qualsiasi momento, e solo l'attenzione / consapevolezza dello sviluppatore può risolvere questo problema. L'iniezione SQL è ancora una cosa . Le lingue di livello superiore generalmente hanno eval , e se sei abbastanza stupido da valutare l'input dell'utente ottieni ciò che ottieni.

Detto questo, è il contrario. La garbage collection evita intere classi di rischi per la sicurezza legati alla gestione della memoria come i buffer overflow. I linguaggi di livello superiore tendono ad essere più concisi, meno codice significa meno posti da nascondere per gli errori. Tutto ciò che è noioso (e la codifica nelle lingue di livello inferiore è certamente questo) è soggetto a errori.

Poiché i linguaggi di livello inferiore non hanno la stessa espressività, è necessario scrivere una grande quantità di codice boilerplate non solo all'inizio, ma in tutto il codice base. Ciò significa, dal momento che non è sempre facile capire da vicino quale dovrebbe essere il codice (in termini di business logic), che sarà meno autodocumentato e richiederà più documentazione sotto forma di commenti o documenti esterni . Ciò introduce un'altra fonte di errore: se la documentazione non viene aggiornata quando il codice a cui fa riferimento cambia, è possibile scrivere altro codice che non è sicuro a causa delle ipotesi obsolete nella documentazione del relativo codice.

Le lingue di livello inferiore mancano di una strong digitazione, quindi ci sono meno errori che un compilatore può catturare. Ci sono stati alcuni tentativi interessanti come Nim e Rust per risolvere questo problema, ma nessuno dei due è ancora popolare.

Ultima, ma certamente non meno importante, la differenza reale tra i linguaggi di alto livello e di basso livello è che i linguaggi di alto livello spostano l'onere dal programmatore all'interpreter / compilatore. Questi interpreti / compilatori sono scritti e mantenuti da alcune delle luci più brillanti del settore, vengono regolarmente sottoposti a verifiche per le vulnerabilità, ecc. Il codice dell'applicazione, d'altra parte, è scritto da mortali. Quindi spostare l'onere da un sacco di codice di applicazione scritto da programmatori medi a codice relativamente meno scritto da programmatori eccezionali dovrebbe migliorare la sicurezza perché c'è meno codice da controllare scritto da persone più abili. Quindi, di quale ti fideresti piuttosto, la gestione del buffer di JVM o Joe Blow a mano in C?

Tutto ciò piuttosto fa sorgere la domanda sul perché le persone usano ancora i linguaggi di basso livello se sono più difficili da usare e meno sicuri. Ci sono una serie di motivi:

1) Il martello dorato . 'Abbiamo un sacco di programmatori C, e stranamente tutto il nostro codice è scritto in C'.

2) Prestazioni. Questo di solito è un'arma rossa, non vale quasi mai il compromesso tra sicurezza e velocità di sviluppo, ma in casi come i giochi in cui è necessario migliorare ogni aspetto dell'hardware può avere un senso.

3) Piattaforma oscura. Lungo le linee sopra, è molto più facile scrivere un compilatore C che un compilatore Rust o una JVM. Se devi prima implementare il compilatore, iniziare con C sembra molto più attraente.

Secondo la mia ricerca estesa su Google, il primo risultato mi ha dato questo risposta .

In breve: meh.

Lo studio è di Veracode, e osservano che è principalmente un lavaggio. Lo basano sulla vulnerabilità tramite la densità del codice, che potrebbe essere un buon modo per misurarlo, non lo so. Quello che so è che si finisce con un'enorme inclinazione perché C / C ++ impiegherà 10 volte più righe di codice per scrivere una determinata applicazione rispetto ad altre lingue.

Inoltre, ciò che vediamo non è probabilmente una vera misura della vulnerabilità, ma della probabilità di trovare una vulnerabilità a causa della popolarità o della disponibilità delle applicazioni fornite. Il più basso numero presunto di vulnerabilità è stato trovato in C / C ++, seguito da iOS (presumibilmente Objective-C?), Ma poi da JavaScript. Ma se consideri l'aspetto della densità, potresti guardare a numeri distorti.

Ecco la cosa: le vulnerabilità sono solo bug. Le lingue non scrivono bug, ma gli sviluppatori lo fanno, quindi è sullo sviluppatore produrre codice privo di bug. Di conseguenza, più è difficile per lo sviluppatore produrre codice privo di bug, più è probabile che ci sarà una vulnerabilità di qualche tipo . Questo significa che i linguaggi di basso livello sono più probabili per avere vulnerabilità, indipendentemente dal fatto che lo facciano effettivamente.