Se usi Java come la maggior parte degli altri linguaggi di programmazione, ad es. per scrivere applicazioni standalone, non è meno sicuro di altri linguaggi e più sicuro di C o C ++ a causa di buffer overflow ecc.

Ma Java viene regolarmente utilizzato come plugin all'interno del browser web, ad es. simile a Flash. Poiché in questo caso l'utente esegue codice non affidabile senza averlo installato esplicitamente, l'idea è di far eseguire il codice all'interno di una sandbox limitata, dove non dovrebbe essere in grado di agire in qualche modo contro il sistema o l'utente (ad esempio, leggi i file locali e invia loro al sito Web, scansionano la rete locale ecc.). Ed è qui che Java ha fallito negli ultimi anni, ad es. nuovi bug sono spuntati a volte su base giornaliera che permettevano l'evasione dalla sandbox.

Inoltre, a volte i bug nell'interprete del codice di byte o nelle librerie native portano a buffer overflow e possono compromettere il sistema, ma a questo proposito Flash è generalmente considerato peggiore.

E come per gli altri linguaggi è meglio: questi di solito non possono nemmeno essere eseguiti come codice non affidabile all'interno di una sandbox (eccezione è JavaScript e forse Flash), quindi sarebbero anche peggio perché non esiste un modo intrinseco per limitare la loro interazione con il sistema.

Le vulnerabilità di sicurezza riportate non riguardano Java (il linguaggio di programmazione), che, in virtù della JVM che impone la sicurezza della memoria , è in realtà più robusto di linguaggi come C o C ++, in cui i buffer overflow e le sovrascritture dei buffer rimangono una minaccia e possono causare problemi come Heartbleed.

Al contrario, le vulnerabilità segnalate si trovano nella Java Sandbox, che tenta di imporre un modello privilegiato che consente l'esecuzione sicura di codice non sicuro ed è notoriamente utilizzato per consentire l'esecuzione automatica di applet Java in un browser. Quella sandbox è piena di buchi. Inoltre, Oracle rilascia patch (gli "aggiornamenti critici delle patch") solo 4 volte all'anno. Inutile dire che i venditori di browser non sono contenti di questo. Firefox, ad esempio, è che richiede l'autorizzazione dell'utente per avviare un applet Java da Firefox 26.

Il motivo per cui i comunicati stampa non fanno quella distinzione è che Oracle utilizza il marchio "Java" sia per il linguaggio di programmazione, sia per il plug-in del browser che esegue le applet . Infatti, se un utente ordinario incontra il marchio Java, probabilmente si riferisce a quest'ultimo.

È alquanto speculativo perché la Sandbox rimanga vulnerabile. Se me lo chiedi, una ragione è che la stessa API viene utilizzata sia con che senza Sandbox, e la maggior parte del codice Java viene eseguito senza Sandbox (perché il codice è affidabile). Di conseguenza, è possibile che uno sviluppatore dimentichi di questa caratteristica oscura quando modifica l'API Java o la sua implementazione, esponendo accidentalmente cose che dovrebbero essere protette (per illustrare quanto sia facile, ecco il lungo Linee guida per la codifica sicura per Java SE ). Un'altra ragione correlata è la dimensione pura dell'API Java ( 5800 classi e quasi 50.000 metodi, per Java SE 6 ).

There are tons of other programming languages that don't have this problem, so there must be a better way to do whatever Java is doing wrong.

Questa è una richiesta piuttosto alta, dove hai avuto questa impressione? Ci sono "tonnellate di altri linguaggi di programmazione" che non sono stati messi alla prova con lo stesso ritmo di Java, o che sono usati come onnipresenti.

In linea di principio, il motivo per cui ci sono così tante patch di sicurezza è perché Java è stato progettato per essere sicuro, con una serie di funzionalità focalizzate sulla sicurezza che altri linguaggi non hanno.

The Java Language Environment

1.2.2 Robust and Secure

Java technology is designed to operate in distributed environments, which means that security is of paramount importance. With security features designed into the language and run-time system, Java technology lets you construct applications that can't be invaded from outside. In the network environment, applications written in the Java programming language are secure from intrusion by unauthorized code attempting to get behind the scenes and create viruses or invade file systems.

Se non includi "essere sicuro" nelle specifiche del tuo linguaggio di programmazione, raramente dovrai rilasciare patch di sicurezza. Se, d'altra parte, questo è uno dei tuoi obiettivi dichiarati, ti verrà difficile premere non per .

Di per sé, Java ha grandi risorse per la sicurezza, vale a dire la sua intrinseca resistenza ai buffer overflow e agli errori di gestione della memoria:

• Tutti gli accessi agli array sono controllati per quanto riguarda la lunghezza dell'array assegnato. Gli overflow del buffer sono così intrappolati in modo affidabile e innescano un'eccezione, che è migliore (questo trasforma le vulnerabilità dell'esecuzione di codice in remoto in un semplice denial-of-service).

• L'allocazione della memoria viene gestita tramite un garbage collector, che impedisce errori use-after-free e double-free. Inoltre, il GC consente una gestione più semplice delle stringhe di caratteri (le stringhe sono immutabili in Java), che rimuove la maggior parte delle occasioni per i bug di overflow del buffer.

• Viene applicata una rigorosa digitazione; il codice non può accedere ai byte dei dati per ciò che non sono. Ciò impedisce di nuovo le vulnerabilità (i bug in cui i tipi di dati vengono trasgrediti saranno segnalati alla compilazione o, nel peggiore dei casi, come runtime ClassCastException ).

Ciò rende Java più strong di molti linguaggi di programmazione (in particolare la coppia infernale C / C ++) quando si tratta di sicurezza.

Tuttavia, i progettisti Java hanno cercato di sfruttare questa sicurezza avanzata per creare qualcosa di difficile, ad esempio applets . Il problema è superficie di attacco : poiché l'applet è un codice potenzialmente ostile, tutto ciò che deve essere controllato deve essere controllato. Ma il codice ostile deve essere in grado di utilizzare le "classi Java standard" se deve fare qualcosa, quindi i "punti di controllo" devono essere applicati su ogni singola classe Java standard. La superficie di attacco consiste quindi in centinaia di classi contenenti migliaia di metodi, e tutti di loro devono applicare controlli adeguati.

I progettisti Java peccati dall'ambizione: la difficoltà di implementare migliaia di assegni senza effettuare il pignoramento era molto più alta di quanto immaginassero. Tutti i "bug Java" provengono da questo fatto.

Possiamo confrontare Java con Javascript qui; ad esempio, Java consente l'accesso ai file sui dischi, ma questo diritto non deve essere concesso alle applet, tranne se l'applet lo ha richiesto e l'utente accetta (che implica l'intera attività di firma dell'applet). Javascript, meno ambizioso, semplicemente non ha alcun metodo di accesso ai file: i controlli di accesso su una funzione non possono essere implementati in modo improprio se la funzione in realtà non esiste!

Per riassumere: Java è perfetto e sicuro. Le applet di Java implicano un'enorme superficie di attacco la cui sicurezza è molto difficile da garantire. Per applicazioni e server standalone, tuttavia, l'utilizzo di Java è una buona idea se si desidera la sicurezza (ciò vale anche per C #).

In questi giorni, trovare più vulnerabilità potrebbe non implicare quanto sia insicuro il software. Il problema è come reagisce il team di risposta alla sicurezza di ciascun fornitore di software e quanto velocemente le patch stanno uscendo.

Controlla la velocità con cui Firefox e Chrome vengono ripristinati. Molte vulnerabilità si trovano anche su di loro e risolte.

Come ricordo, Oracle ha un programma chiamato Critical Patch Updates (CPU) che fornisce un sacco di patch trimestrali. Rilasciano anche patch senza CPU se esiste una vulnerabilità zero-day . Ma il problema è il tempo impiegato da Oracle per rilasciare una patch.

Paura sopravvalutata .. Java in sé va bene; i problemi si verificano con le applet Java della vecchia scuola eseguite nei browser Web, ma dubito che qualcuno crei effettivamente gli Applet - molte case di sviluppo hanno utilizzato Flash o HTML4 / 5 per interfacce Web front-end per almeno gli ultimi 10 anni.

Al giorno d'oggi Java viene principalmente utilizzato per JEE backend, client GUI front-end (JFX / AWT / SWING), app per console e app mobili - quindi non ci sono problemi.

La risposta è abbastanza ovvia. Puoi cancellare i file del tuo computer usando JavaScript, HTML o Flash? No, non puoi.

Che dire di Java. Puoi cancellare tutti i tuoi file, cancellare completamente il tuo disco rigido usando un'applet Java (ospitata su un sito web)? La risposta è sì, se accetti di eseguire l'applet. A differenza di qualsiasi altra lingua del browser web.

Java ha la capacità di fare cose come eseguire programmi sul tuo computer (eseguibili) e ha anche la capacità di scrivere, aggiornare o eliminare file sul tuo disco rigido.

Inoltre, le applet Java non sono rilevabili dagli scanner dei virus: nella maggior parte dei casi, non si sa nemmeno che ha rovinato il computer. Alcuni scanner potrebbero rilevare che qualcosa sta cercando di eliminare i file in una directory limitata: uno che conosco è Kaspersky , ma la maggior parte delle persone ha questa funzione attivata disattivato per impostazione predefinita.

Le applet Java possono fare cose come aggiornare i file di Windows, come HAL.dll , che impedirà l'avvio del tuo computer. Può fare qualsiasi cosa sul tuo computer quando accetti di eseguire l'applet.

In alcuni casi non importa nemmeno se un'applet Java è firmata o non firmata - continuerà a scaricare file sul tuo computer.

Per non parlare di Java è molto popolare.

Ce n'è un'altra che sta diventando sempre più popolare, chiamata Unity Engine (simile a Flash): ha gli stessi problemi di sicurezza come ha Java e potrebbe fare qualsiasi cosa sul tuo computer. L'unica differenza tra Unity Engine e Java è che Unity viene eseguito senza chiederti se desideri eseguirlo o meno. Quindi, se qualcuno ha installato Unity Player ed esegue un gioco che contiene un virus, rovinerà il tuo computer.

Meno popolare, ma potenzialmente potenzialmente estremamente dannoso è VBScript . Credo che Microsoft Internet Explorer sia l'unico che attualmente supporta questo, ma potrei sbagliarmi. Ha le stesse abilità di Java.