2015-01-30 35 views

risposta

16

A seconda della versione di Mojarra. Aveva diversi difetti/fallimenti nelle versioni precedenti.

In Mojarra 1.2.x - 2.1.18, non è mai stato effettivamente utilizzato. Il nome della voce JNDI era in realtà erroneamente documentato. Era documented come com.sun.faces.ClientStateSavingPassword (con lo stesso prefisso Mojarra's other web.xml context parameters), ma il codice actually controlla ClientStateSavingPassword. Dovresti quindi registrarlo su quel nome.

<env-entry> 
    <env-entry-name>ClientStateSavingPassword</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[Your Password]</env-entry-value> 
</env-entry> 

In caso contrario, lo stato cliente è realtà non criptato.

In Mojarra 1.2.x - 2.0.3, la password will essere usato come un SecureRandom seed per generare un DES algorithm key. Quindi, generalmente, si applicano le stesse regole di "real world" passwords. Solo, questo può essere facilmente compromised se la password è "troppo facile" e l'utente malintenzionato indovina/bruteforces/calcola la password.

In Mojarra 2.0.4 - 2.1.x, hanno changed l'algoritmo da DES a AES e il codice ora non actually più usare la password fornita per generare la chiave (per prevenire potenziali comprisions). Invece, una chiave completamente casuale è generated, che è più sicuro. La voce JNDI ora controlla fondamentalmente se lo stato client debba essere crittografato o meno. In altre parole, si comporta ora come una voce di configurazione booleana. Quindi non importa assolutamente quale password usi.

<env-entry> 
    <env-entry-name>ClientStateSavingPassword</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[Any value is interpreted as boolean=true to enable encryption]</env-entry-value> 
</env-entry> 

In Mojarra 2.1.19 - 2.1.x, hanno fixed il codice per allineare la documentazione sul nome della voce JNDI. Così si potrebbe utilizzare il nome della voce JNDI documentato:

<env-entry> 
    <env-entry-name>com.sun.faces.ClientStateSavingPassword</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[Any value is interpreted as boolean=true to enable encryption]</env-entry-value> 
</env-entry> 

Tuttavia, questo ancora non influenza la chiave AES, che è stato cambiato dal 2.0.4, ancora consente fondamentalmente solo/disabilita la crittografia.

In Mojarra 2.2.0 - 2.3.x, come parte di JSF 2.2 specification (capitolo 7.8.2), lo stato lato client è ora di default always crittografato. Sarà disabilitato solo quando il parametro di contesto web.xmlcom.sun.faces.disableClientStateEncryption è impostato con il valore true. Lo standard still utilizza l'algoritmo AES con un completely random key. La voce JNDI com.sun.faces.ClientStateSavingPassword è ora non utilizzata più.

In Mojarra 2.2.6 - 2.3.x, hanno aggiunto come per issue 3087 una nuova voce JNDI che permette di specificare la chiave AES in formato Base64 codificato, the jsf/ClientSideSecretKey.Questo fa parte del bugfix sullo stato lato client in errore quando viene utilizzata una webapp JSF in ambiente cluster, poiché ogni server utilizzava una chiave AES diversa che causava solo uno ERROR: MAC did not verify! quando lo stato viene ripristinato in un server diverso da quello che ha salvato lo stato , come descritto in issue 2557.

<env-entry> 
    <env-entry-name>jsf/ClientSideSecretKey</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[AES key in Base64 format]</env-entry-value> 
</env-entry> 

È possibile utilizzare questo AES key generator per generare uno (aggiornare la pagina per rigenerare), o utilizzare sotto frammento per generare il proprio Base64 -encoded AES256 chiave:

KeyGenerator keyGen = KeyGenerator.getInstance("AES"); 
keyGen.init(256); // Use 128 for AES128 (when server don't have JCE installed). 
String key = Base64.getEncoder().encodeToString(keyGen.generateKey().getEncoded()); 
System.out.println(key); // Prints AES key in Base64 format. 
+0

Chi come definitiva, come potevo sperare per :) Vado a controllare esattamente quale versione è in esecuzione - grazie. Ho 16 ore per andare fino a quando non potrò assegnare la taglia, quindi la pubblicherò su questa risposta. –

+0

Prego. Puoi anche solo aspettare fino alla scadenza del periodo di taglia. Generalmente, hai più possibilità di aumentare le entrate nell'ultimo giorno del bounty (dato che questa domanda galleggia in cima all'elenco "featured"), in questo modo puoi guadagnare i punti indietro. – BalusC

+0

Dato che so che non è stato crittografato prima, e che ha usato 'com.sun.faces.ClientStateSavingPassword', sembra probabile che io cada nel blocco 2.1.19 - 2.1.x. Siamo in un ambiente con cluster: è probabile che si verifichino problemi con l'utilizzo di chiavi AES diverse su ciascun server? –

Problemi correlati