Hai ragione nella valutazione di "Java 0-day" per il codice del server. Questi attacchi riguardano il codice ostile della applet sandbox , che è il modello di sicurezza utilizzato dalle applet: un'applet è un codice che potrebbe essere malevolo e quindi verrà eseguito con pesanti restrizioni (ad esempio, nessun accesso ai file locali, nessun caricamento di codice nativo, nessuna connessione di rete eccetto il server che ha inviato l'applet in il primo posto, nessuna completa introspezione su altri pacchetti ...). Su un server, il codice è, per definizione, non-ostile e non viene eseguito in una sandbox.
Java su un server gira ancora nella Java Virtual Machine , che non è la stessa della sandbox. In parole povere, la JVM applica le regole di tipo (nessun accesso al campo o richiami di metodo su oggetti che non hanno il campo o il metodo designato) ei limiti dell'array (nessuna scrittura in byte adiacenti su buffer overflow), ed esegue il garbage collector; la sandbox aggiunge molti controlli extra su quali metodi standard possono essere chiamati o meno, con un sistema di permessi elaborato. Il codice lato server non è in modalità sandbox, ma la JVM conterrà comunque il danno in caso di buchi sfruttabili:
-
In caso di overflow del buffer, il thread offendente è terminato (beh, riceve un'eccezione che può intercettare, ma in pratica la terminazione è il risultato finale normale) e nessun oggetto in memoria è stato effettivamente danneggiato. I buffer overflow sono ancora bug, ma, almeno, le conseguenze sono limitate.
-
Il garbage collector , per definizione, impedirà qualsiasi tipo di accesso-dopo- gratuito.
-
Il sistema di tipo rigoroso impedirà l'accesso a qualsiasi byte di dati con un'interpretazione diversa da quella utilizzata per memorizzare quel byte in primo luogo.
-
Le variabili locali non inizializzate non possono essere lette (l'analisi del flusso quando viene caricato il codice lo impedisce). I campi vengono sistematicamente forzati in valori predefiniti di default (0, false , 0.0, null ).
Tutto questo, però, si applica ugualmente a .NET, PHP e Perl e praticamente a tutto tranne linguaggi di programmazione di livello molto basso.
Tentare di stabilire livelli di vulnerabilità intrinseche è un'attività rischiosa. Le caratteristiche di Java, che ho spiegato sopra, possono essere trasformate in un argomento su come Java sia " intrinsecamente sicuro ". Tuttavia, lo stesso si applica alla maggior parte degli altri framework di programmazione, incluso PHP. In definitiva, la maggior parte delle vulnerabilità sono errori di programmazione, non in del framework, ma errori commessi dallo sviluppatore che ha usato il framework. Il conteggio delle vulnerabilità pubblicate ti dirà solo i buchi di sicurezza nelle librerie del framework, ma non i buchi nel codice sviluppato per il framework, ed è qui che la maggior parte dei buchi sarà.
Quindi le vulnerabilità riguardano la facilità con cui il framework deve essere utilizzato e quanto bene (o male) le caratteristiche del framework aiutano il programmatore a non creare bug. Questo è relativo allo sviluppatore . Un abile sviluppatore PHP che non sa nulla di Java non sarà bravo a creare un server basato su Java sicuro: dovrà imparare un po 'di Java e usarlo subito, sarà un processo doloroso e lo sviluppatore non avrà molto tempo per i test. Ciò non implica affatto che PHP sia intrinsecamente più sicuro di Java; la situazione verrebbe invertita con uno sviluppatore che conosce Java ma non PHP.
Nel migliore dei casi, possiamo sottolineare che linguaggi di programmazione "di basso livello" come C, Forth, Assembly, C ++ ... sono oggettivamente più difficili da usare di quelli "di alto livello" (come C #, Java, PHP, Node.js ...). Il punto in cui questo è più evidente è la gestione delle stringhe di caratteri. I server tipici lo fanno molto. In C, la gestione delle stringhe di caratteri è molto manuale, con tutte le allocazioni e le operazioni di copiatura, e avendo cura delle lunghezze del buffer. Le lingue con gestione automatica della memoria (ad esempio tutte quelle con un GC) rendono questi lavori molto più semplici, ovvero molto più difficili da sbagliare .
Questa è la fine dell'esercizio. Per piattaforme basate su linguaggi di alto livello (sia LAMP, Spring, .NET ...), il "più sicuro" sarà quello che lo sviluppatore conosce meglio . Questo "fattore di conoscenza" supera tutti gli altri.
(Potresti trasformarlo in: "il framework Web più sicuro sarà quello per cui è più facile trovare uno sviluppatore competente").