Provetta 2018 - commenti

1. WS accessibile via OpenVPN. Non occorre che il modulo NAPT della organizzazione in cui si trova WS renda accessibile WS. Basta che renda accessibile OpenVPN. Il modulo NAPT vede solo traffico verso/da il server OpenVPN (non può vedere quale traffico applicativo viaggia all'interno della VPN perché questo traffico è crittato). Non l'ho considerato come errore (anche se probabilmente avrei dovuto) perché il testo non diceva che WS è accessibile solo tramite VPN.
2. WS accessibile via OpenVPN. Server OpenVPN può comunicare direttamente con WS. Questo significa che il pacchetto da browser a WS che viaggia all'interno della VPN, una volta uscito dal tunnel prosegue direttamente verso WS: non ha alcun senso farlo andare verso il NAPT di frontiera; il NAPT converte da dentro a fuori o da fuori a dentro; non da dentro a dentro.
   
   Potrei ammettere che uno sia rimasto confuso dal fatto che il testo non diceva esplicitamente che l'accesso a WS avveniva "solo" tramite VPN, però non è ammissibile uno svolgimento con transito asimmetrico. Se all'andata uno passa da OpenVPN server, poi da NAPT, poi da WS, allora deve fare lo stesso cammino anche al ritorno; se al ritorno non si passa da NAPT allora si ottiene una situazione che non ha il minimo senso: sul browser c'è una connessione TCP in cui l'indirizzo della estremità server nei pacchetti che vanno al server è diverso da quello nei pacchetti che arrivano dal server.
3. CSP "impedisce di utilizzare la sintassi HTML" non ha il minimo senso.
4. WS accessibile via OpenVPN. Mettere nella configurazione NAPT solo WS e non OpenVPN server non ha senso: come riesco a contattare quest'ultimo? Inoltre, "configurazione" è diverso da "stato interno". La configurazione è quello che deve essere inserito prima di fare funzionare il sistema: non occorre inserire configurazione per i client (che ovviamente alterano lo stato interno durante il funzionamento).
5. "CSP previene iniezione exploit CSRF perché iniezione avviene con FORM e il browser si rifiuta di eseguire" è sbagliato; l'iniezione si può fare anche con dei javascript che creano immagini ospitate sul sito vulnerabile; inoltre, l'invio della forged request si fa prima di prelevare contenuti dal sito vulnerabile, quindi CSP è irrilevante.
6. Mettere nella mapping table del NAPT di una organizzazione dei mapping per indirizzi di altre organizzazioni non ha alcun senso.
7. Il testo chiedeva "...specificare quali delle seguenti affermazioni è vera..., con una breve motivazione". Uno svolgimento contenente la specifica ma non la motivazione non è pienamente accettabile.
8. molto grave 4-way handshake in WPA-Personal. Inviare la PMK nel payload di uno dei frame non ha senso perché è già presente su entrambi i partner (supplicant e AP). Soprattutto, è sbagliatissimo perché sarebbe trasmessa in chiaro.
9. molto grave I numeri di sequenza sono associati ai byte, non ai segmenti. Se due segmenti consecutivi inviati dallo stesso sender hanno sequence number che differiscono di 1 allora vuol dire che il primo segmento ha trasmesso 1 byte utile. Non ha senso. Se poi la window size del partner passa da 43 MSS a 41 MSS allora il senso è ancora meno (se trasmetto 2 byte come fa la window del partner a diminuire di 2 MSS???)
10. HTTP request da BX verso WS su VPN. Pacchetto che esce da tunnel (OpenVPN server) ha destinazione IP-RS1 (che è l'indirizzo del router di frontiera). Pacchetto che arriva a web server ha destinazione IP-S. Chi l'ha cambiato? Forse è passato dal NAPT di frontiera? in tal caso vedi #2 qui sopra.
11. molto grave BX invia segmento S1 con HTTP request; WS risponde con 2 segmenti S2, S3 di dimensione MSS ognuno; BX invia segmento S4 di riscontro.
    
    S4.seqnum = S1.seqnum+1 S1 trasportava 1 byte?
    S3.seqnum = S2.seqnum+2MSS S2 trasportava 2 MSS? cioè il doppio della dimensione massima possibile per un segmento?
    S2.ack=S1.seqnum+1 e S3.ack=S1.seqnum+2 questa non la capisco in nessun modo
12. CSP non c'entra nulla con i web application firewall; non c'entra nulla con lo header http-only dei cookie; non c'entra nulla con il safe encoding; c'entra qualcosa con spostare gli script ma se non si accenna minimamente alle direttive da inserire nelle risposte HTTP allora non ha senso dire che spostando gli script "si previene la vulnerabilità" (che comunque è sbagliato perché la vulnerabilità rimane)