Sicurezza di JVM per Server

Java va bene per i server. I problemi di sicurezza con Java sono in realtà problemi con il modello di applet Java , in cui la tua JVM ( nel tuo browser) è pensato per eseguire codice potenzialmente ostile (ad es. codice "dal Web") e tuttavia in qualche modo impedire che il codice ostile faccia qualcosa di negativo. Il modello di applet è un po 'come eseguire il codice dell'applet in una macchina virtuale, tranne per il fatto che il livello di isolamento viene eseguito con la lingua stessa e con le protezioni nella libreria standard. Si scopre che provare a fare una sandbox in questo modo è molto difficile, perché devi includere controlli espliciti in ogni classe e metodo di libreria potenzialmente pericolosi, e ce ne sono migliaia. Tutte le vulnerabilità di Java che hanno colpito le notizie negli ultimi anni riguardano questo: alcuni codici di libreria standard che non filtravano le chiamate con sufficiente robustezza, nel caso in cui il chiamante fosse un'applet ostile.

Nessuno di questi si applica a Java su un server. Su un server, questo è il tuo codice, presunto non ostile e con accesso completo alla libreria standard. L'esecuzione di codice Java sul server non è peggiore (per motivi di sicurezza) rispetto all'utilizzo di codice C o C ++; in realtà è probabilmente meglio perché le protezioni intrinseche del linguaggio Java (gestione della memoria basata su garbage collector, tipi forti e controlli sui limiti della matrice) lo rendono più robusto rispetto ad alcune categorie di bug come i buffer overflow. Vale a dire, le conseguenze di un overflow del buffer sono più limitate (il buffer non viene effettivamente sovraccaricato, viene invece lanciata un'eccezione) e il GC consente una gestione molto più semplice delle stringhe di caratteri, che è una fonte fertile di buffer overflow durante la scrittura del codice C .

Lo stesso ragionamento si applica a .NET e ai suoi vari linguaggi (C #, VB ...).

Java Runtime Environment può essere eseguito utilizzando un Security Manager se si desidera limitare determinati accessi a determinate parti dell'applicazione (in base al codice in esecuzione e allo stato di autenticazione).

Può essere abilitato in Apache Tomcat o in JBoss per esempio.

Il sistema delle politiche e delle autorizzazioni è un argomento complesso ed è documentato qui .

Certo, il sistema non è perfetto poiché le vulnerabilità a cui si fa riferimento per le applet si verificano quando l'applet "scappa" dal proprio gestore della sicurezza. Questo può accadere se c'è un bug nel gestore della sicurezza stesso (ovviamente un problema) o se il criterio è troppo lento.

Da questo punto di vista, un ambiente server è diverso da un ambiente applet in quanto l'ambiente dell'applet è installato con una politica valida per tutti: qualcosa che mira ad essere abbastanza buono da limitare il cattivo comportamento mentre abilita la maggior parte delle funzionalità, senza sapere quale codice verrà eseguito o in quale ambiente esatto. Un ambiente server è meno vulnerabile a tale riguardo, dal momento che potresti essere in grado di personalizzare la tua politica per soddisfare le tue esigenze specifiche (ad esempio, consentire connessioni al tuo server database specifico ma nessun'altra connessione in uscita).

I gestori della sicurezza tendono a non essere abilitati di default nei contenitori webapp, ma se necessario, puoi configurare i criteri in base alle necessità.

Sì, JVM e ambienti simili riducono il rischio di vulnerabilità di corruzione della memoria, sebbene si tenga presente che questo tipo di problemi può verificarsi anche a livello di VM (ad esempio CVE-2013-2420)

La recente ondata di vulnerabilità Java è in effetti focalizzata sulle applet lato client, ma va anche notato che ci sono stati modi per sfruttare questi problemi sul lato server (come attraverso il protocollo RMI). Oracle non lo segnala sempre nei loro consigli:

link

Per quanto riguarda la sicurezza delle diverse implementazioni di JVM, il progetto SE-2012-01 di Security Explorations sembra un buon punto di partenza:

link