La sicurezza della lingua non è chiaramente definita mentre ci sono avvertenze su ad esempio Java. Quindi, come puoi dire che la lingua non è sicura mentre la sicurezza della lingua non è chiaramente definita? Se Java non è sicuro ora, la versione 7 di Java è "più sicura" di Java versione 2?
Si può dire che una lingua è "sicura" se è possibile implementare il suo ambiente interprete / compilatore / runtime in modo efficiente, nel pieno rispetto delle specifiche della lingua, e ancora con la forza di impedire che "cose cattive" accadano. Quindi dipende da "cose cattive" di cui stai parlando.
Java è "sicuro" se vuoi proteggere la macchina da il codice scritto dallo sviluppatore . I limiti delle matrici sono controllati, i tipi sono inderogabili e la deallocazione della memoria è gestita da un garbage collector , il che significa che non è teoricamente fattibile per fare in modo che un'applet Java, per quanto malamente scritta, esegua il codice nativo scelto dagli aggressori. Nelle stesse condizioni, C è "non sicuro" perché non può essere completamente implementato con controlli che impediscono l'esecuzione di codice arbitrario.
Naturalmente, nella pratica , le cose cambiano un po ': il codice C può essere reso "più sicuro" con varie tecniche (come DEP e ASLR ) e il sistema operativo può" contenere "codice nativo sotto alcuni diritti di accesso specifici (un processo" utente normale "non è root ). E l'attualità di Java ci mostra che mentre Java è teoricamente sicuro, l'implementazione di Java Virtual Machine e il suo ambiente di runtime possono avere buchi. In una certa misura, l'esatta specifica JVM assicura che l'implementazione di Java in sicurezza sia difficile (si tratta di una disfunzione del modello di applet: forza il controllo per metodo nell'intera libreria standard).
Non puoi avere una definizione unica per tutti della sicurezza della lingua, a meno che non ti accontenti di uno slogan soggettivo (COBOL fa schifo! F # regole! Prolog per sempre!). Tutto dipende dal contesto.
Potrebbe esserci qualche confusione qui. Un linguaggio di programmazione non include intrinsecamente vulnerabilità. Sono i programmi scritti in quelle lingue che fanno.
I linguaggi di livello superiore (come Perl, Java, JavaScript, C #, ma non C o C ++) aiutano a semplificare il codice di programmazione e ti consentono di scrivere il codice in modo tale che non sia possibile un overflow del buffer che è meglio per la sicurezza, ma la differenza di sicurezza tra i linguaggi di alto livello è molto piccola.
Nel caso di Java, c'è una sandbox che non ha dimostrato di essere completamente efficace. Questa sandbox aveva lo scopo di consentire la scrittura di un programma in Java e quindi l'esecuzione nel browser, senza accesso al computer su cui era in esecuzione. È la sandbox Java che ha avuto problemi di sicurezza, non Java stesso. Non posso parlare al confronto tra Java 7 e Java 2.
Le lingue sono classificate come sicure e non sicure in base a poche proprietà. Un linguaggio sicuro, come dici tu, include almeno le seguenti proprietà:
Il linguaggio Java ha tutte queste proprietà e quindi può essere facilmente classificato come un linguaggio "sicuro". L'insicurezza che hai citato non è dovuta al linguaggio in sé, ma a causa di un insicuro ambiente sandbox e di chiamate di librerie non sicure. Smonta qualsiasi recente codice di exploit Java e tutto ciò che fa è bypassare le restrizioni di sicurezza per chiamare il codice di classe privilegiato. Non ha nulla a che fare con l'insicurezza del linguaggio stesso, ma con il design complesso e insicuro delle librerie java.
La sicurezza linguistica può essere interpretata in modo più ampio rispetto alla semplice sicurezza. Ma poiché questo è un sito di sicurezza, limitiamoci alla sicurezza.
Chiaramente, la selezione della lingua ha un significato significativo se si otterranno certi tipi di vulnerabilità. Scrivi un programma non banale in C e sarà pieno di errori di corruzione della memoria (buffer overflow, use-after-free, ecc.).
Ci sono un paio di definizioni utili:
Memory-safe - Questo significa che un programma all'interno della lingua non può accedere alla memoria al di fuori delle allocazioni. Non oltrepassare un buffer o utilizzare un'assegnazione dopo che è stata liberata. È difficile provare automaticamente un linguaggio come C. Memory: la sicurezza viene in genere ottenuta attraverso la garbage collection e l'uso di una sicurezza di tipo più restrittiva.
Tipo sicuro - Non confondere questo con solo non rovinare i tuoi tipi in lingue non sicure. Questa è una garanzia che va oltre la sicurezza della memoria in quanto non è possibile utilizzare un tipo in modo inappropriato rispetto al tipo effettivo dell'oggetto. Ad esempio, non puoi trattare un puntatore come un numero intero.
È interessante notare che da 1.5 Java non è sicuro per il tipo vaniglia. È sicuro dal punto di vista del tipo rispetto ai tipi non elaborati, come usato dalla JVM e dal linguaggio Java 1.4 e precedenti. Non è sicuro per quanto riguarda il sistema di tipo linguistico completo inclusi i farmaci generici. Ciò non sembra affatto importante, in gran parte perché per accedere ad un oggetto il bytecode deve eseguire un controllo di tipo non elaborato.
Le librerie di vulnerabilità per la corruzione senza memoria diventano più importanti. Ad esempio, l'iniezione è una classe di vulnerabilità incredibilmente popolare, ma non c'è davvero alcuna scusa per non averne affatto.
Il codice mobile (ovvero il codice mobile e non attendibile) è una cosa completamente diversa. La sicurezza può essere ottenuta tramite una sandbox (come il NaCl di Google), un Object-Capability Model (gergo che in sostanza significa OOP in un ambiente sicuro per tipo) o una combinazione degli altri due.
Come per Java SE 1.7 vs 1.2. Non c'è stato molto cambiamento. 1.2 è molto diverso da 1.1, e 1.0 era di nuovo un po 'diverso (anche se in realtà prima di prestare attenzione a questo genere di cose).
Problemi specifici nella lingua Java che causano vulnerabilità:
static (per i campi, quando non è immutabile) è un modo a una parola chiave per introdurre le vulnerabilità e distruggere la qualità del codice. transient e un'implementazione che non è nemmeno possibile in bytecode) sono ambigui. Leggi altre domande sui tag java known-vulnerabilities