gsingh2011
2014-05-09 22:39:24 UTC
Mi piace molto il linguaggio di programmazione Java, ma sento continuamente parlare di quanto sia insicuro. Googling "java insecure" o "java vulnerabilities" fa apparire più articoli che parlano del motivo per cui dovresti disinstallare o disabilitare Java per proteggere il tuo computer. Java spesso rilascia un numero enorme di patch di sicurezza alla volta, eppure ci sono ancora tonnellate di vulnerabilità da correggere.
Capisco che ci saranno sempre bug nel software, ma la quantità di vulnerabilità che Java ha non mi sembra normale (o me lo sto immaginando?). Ciò che è ancora più confuso è che se c'è un'unica decisione architettonica che sta creando queste vulnerabilità, perché non cambiare quel design? Ci sono un sacco di altri linguaggi di programmazione che non hanno questo problema, quindi deve esserci un modo migliore per fare tutto ciò che Java sta facendo di sbagliato. Allora perché Java è ancora così insicuro?
Trovo davvero ingiusto che alcune persone affermino che Java sarebbe "insicuro" perché il suo concetto di sandboxing ha alcuni difetti mentre la maggior parte delle altre tecnologie non ha nemmeno il sandboxing e consente ai programmi di fare praticamente tutto ciò che vogliono sulla macchina su cui vengono eseguiti. La critica è giustificata solo nel caso d'uso molto ristretto di applet eseguite in un browser web, dove le alternative come Flash hanno un track record di sicurezza altrettanto negativo.
La tua domanda è simile alla domanda "Perché le auto hanno ancora problemi al motore?". (E per quelli che provengono dall'angolo di "C (++) non li ha!", Aggiungi "La mia bicicletta non ne ha mai!")
Perché è stato vittima di bullismo da bambino.
Java ha avuto relativamente * poche * vulnerabilità di sicurezza per un linguaggio di programmazione completo che è in grado di funzionare in un browser (la maggior parte degli altri linguaggi compatibili con browser non sono, per progettazione, in grado di fare certe cose). - Le vulnerabilità di cui hai sentito parlare di recente sono applicazioni completamente dannose (leggi Applet) che trovano un modo per uscire dalla sandbox ed eseguire codice arbitrario sul tuo sistema. Potrebbe esserci una discussione sul fatto che le applet siano una parte di java che dovrebbe essere messa a tacere, tuttavia molte tecnologie si basano ancora su di esse (console IMPI, siti Web di banche, ecc.).
@Philipp: Non penso sia affatto ingiusto. Se una lingua viene promossa come sandbox, ma la sua sandbox ha una cronologia che va da decine a centinaia di vulnerabilità critiche ogni anno, è perfettamente giusto condannarla come insicura. La sicurezza non è una cosa assoluta, ma una questione di essere all'altezza del contratto pubblicato. Forse non è giusto confrontare Java e C ++, ma è certamente giusto confrontare Java e Lua. Se non sbaglio, quest'ultimo non ha nemmeno superato le cifre singole per le vulnerabilità di fuga dalla sandbox.
@R .. Il sandboxing si applica solo a un contesto molto ristretto, e questo è applet java nei browser web. Quando vuoi dire che questi sono insicuri, sono pienamente d'accordo. Ma come puoi capire da questa domanda, molte persone estendono questa critica a Java in generale, che copre casi d'uso in cui i problemi di sandboxing delle applet non hanno alcuna importanza.
@R .. Anche il confronto tra Java e Lua non è giusto, perché Java è un linguaggio generico con [un'enorme libreria standard che include tutto tranne il lavello della cucina] (http://docs.oracle.com/javase/8 /docs/api/allclasses-noframe.html) mentre Lua ha [una libreria standard molto piccola] (http://www.lua.org/manual/5.2/) ed è pensata per essere incorporata in un'applicazione host che aggiunge dominio - collegamenti di script specifici a lua che potrebbero o non potrebbero essere sicuri.
La mia opinione è che sia perfettamente giusto, perché un'enorme libreria standard * implementata al di fuori della sandbox * essenzialmente preclude la possibilità di offrire un ambiente sandbox sicuro. Questa è una delle cose che Java ha sbagliato orribilmente che Lua ha avuto ragione.
Sono d'accordo che "Java the language" riceva molta pubblicità negativa dal fatto che "Java the sandbox" sia così rotto. Se questo è "giusto" o no è un giudizio, ma è una conseguenza della decisione di marketing di accoppiare strettamente i due. Sulla maggior parte dei sistemi, la semplice installazione di Java (per qualsiasi scopo) installa anche componenti del browser che espongono il sistema a vulnerabilità remote critiche se viene utilizzato il browser, quindi è giusto dire che semplicemente avendo Java installato, a meno che tu non abbia fatto di tutto per bloccarne l'utilizzo nel browser, è un problema di sicurezza.
@R .. Una società per cui ho lavorato usava LotusNotes semplicemente perché poche persone lo usavano e quindi le falle di sicurezza che certamente aveva (come tutto) sono rimaste inosservate. Temo che Java sia dalla parte opposta. Qualsiasi difetto che ha ** verrà ** scoperto, non significa che altre cose meno utilizzate siano più sicure, ci sono solo meno persone che cercano di decifrarle
@R .. "è certamente giusto confrontare Java e Lua. Se non sbaglio, quest'ultimo non ha nemmeno superato le cifre singole per le vulnerabilità sandbox-escape." In base a questo argomento, dovremmo davvero tutti utilizzare PostScript, poiché ha ancora meno vulnerabilità di questo tipo. (PostScript _does_ in effetti offre sandboxing e, se configurato correttamente, può consentire di eseguire codice ostile impunemente, FYI) (Se non capisci esattamente quello che sto dicendo, è che Java ha più vulnerabilità _discovered_ perché Java è usato _far più spesso_ di Lua.)
In realtà PostScript ha storicamente alcune vulnerabilità, specialmente se si considera l'ambiente in cui è destinato ad essere utilizzato. E qualsiasi linguaggio completo di Turing è una vulnerabilità DoS nel contesto di ciò per cui è pensato PostScript (documenti), specialmente quando sei eseguendolo su microcontrollori da 1MHz all'interno delle stampanti.
Per quanto riguarda Java vs Lua, non è questione di quanto vengono utilizzati. È una questione di design. Lua ha un numero esiguo di punti di potenziale guasto (uno di questi era idiota: consentire al codice Lua di inviare il bytecode direttamente alla macchina virtuale). Java ha un numero astronomico.
Ovviamente per gli hacker (cappello bianco), investigare nei vuln Java è più interessante che negli altri linguaggi, questo è come Windows per gli altri sistemi operativi.
Forse puoi chiarire qual è il contesto della tua dichiarazione. Sembra che tu stia affermando che ritieni che il codice Java potrebbe dover essere riparato e che i manutentori del software non stanno facendo un lavoro abbastanza buono? Ogni applicazione avrà il proprio tipo di codice applicabile da implementare, quindi si dovrebbe evitare di fare affidamento su una qualsiasi serie di pratiche di codifica. Scommetto che le applicazioni Java lato client passeranno per Flash e presto moriranno.
Hah, parliamo di ingiusto: stiamo sviluppando un [browser in Java] (https://github.com/UprootLabs/gngr) e le persone lo scambiano con applet, o lo associano a Java che scambiano con applet, o associano la sandbox del gestore della sicurezza con la sandbox dell'applet più specifica ... e così via.