giovedì 26 marzo 2015

Io "sono" un numero

Ieri a lezione abbiamo detto che se un client CX genera (in modo fraudolento) una request RX contenente l'identifier di una sessione di un altro client C, allora RX viene elaborata dal server come se fosse stata generata da C.

Ciò è evidentemente molto spiacevole. Specialmente se la sessione è "autenticata", cioè l'utente che sta controllando C ha dimostrato la propria identità al server (con meccanismi che vedremo nella prossima lezione) ed il server ha quindi inserito nello stato della sessione informazioni quali "sessione autenticata, username rettore ateneo".

In questo modo, infatti, CX può accedere in lettura e scrittura a dati privati dell'utente che sta controllando C. Superfluo evidenziare le implicazioni.

Ho anche detto che queste cose, fino a pochissimi anni fa, erano talmente facili da fare che erano stati sviluppati software gratuiti in grado di farlo in modo automatico. In pratica, bastava osservare il traffico in una rete WiFi per raccogliere gli identificatori delle sessioni degli altri utenti della stessa rete. Trovati gli identificatori, generare request contenenti quegli identificatori era banale. A questo link trovate informazioni al proposito:
http://bartoli-alberto.blogspot.it/search?q=sidejacking

​Oggi, fortunatamente, le cose sono cambiate nel senso che tutto il traffico di tutte le sessioni autenticate è crittato. Pertanto indovinare il session identifier di un altro client non è più banale come in passato ("non banale" è diverso da "impossibile").

Ciò che è istruttivo è il fatto che le cose sono andate avanti in quel modo per moooolti anni.

A questo punto ci sarebbe da spiegare "ma come mai non se ne preoccupavano?"....

lunedì 23 marzo 2015

Machine learning e tesi di laurea

Un lavoro basato su una tesi di laurea magistrale svolto nel "mio" laboratorio è stato accettato ad un congresso scientifico internazionale moooolto prestigioso.

Come ho già avuto modo di scrivere in una occasione simile "Ancora una volta mi chiedo perché molti studenti in gamba preferiscano fare tesi di laurea in cui l'obbiettivo è fare qualche finestra colorata con qualche bottone altrettanto colorato usando una delle N tecnologie esistenti al momento...ma questo è un altro discorso."

Il lavoro è descritto in un post sul sito del Machine Learning Lab.

Il tesista, Marco Virgolin, è stato davvero molto bravo. Ha un solo difetto, purtroppo non rimediabile, che non riporto pubblicamente ma che lui conosce benissimo. Difetto che comunque non ha impedito il raggiungimento di questo bellissimo risultato.

Al fine di non deludere gli altri tesisti, passati e futuri, il cui lavoro non è stato pubblicato, chiarisco che per arrivare alla pubblicazione di una tesi sono necessari molti fattori: bravura ed impegno del tesista sono solo due di questi. Ho seguito infatti molte tesi che non hanno portato a pubblicazioni pur essendo molto belle, fatte da persone molto in gamba e che hanno lavorato molto.  L'esempio più lampante è quello del mio braccio destro, Eric Medvet...


Indipendentemente dalle pubblicazioni, comunque, spero che il passaggio dal Machine Learning Lab sia stata una esperienza positiva per tutti quelli che l'hanno fatto.

giovedì 5 marzo 2015

Come organizzo lo studio di Internet

Lo studio di Internet è molto diverso dallo studio di Analisi I o di Fisica II. Internet fa parte della nostra esperienza quotidiana immediata, altre discipline sono più lontane dall'esperienza quotidiana o ne sono parte ma non ce ne accorgiamo.

Ciò rende potenzialmente più "appassionante" lo studio di Internet, ma rende anche l'impostazione didattica molto complicata. Analizzare gli argomenti di Internet esattamente come si verificano nella realtà sarebbe didatticamente disastroso. In ogni argomento si mescolano infatti:
  1. elementi necessari per il funzionamento e fondamentali per la comprensione;
  2. elementi non necessari per il funzionamento e/o non fondamentali per la comprensione;
Gli elementi 2 purtroppo sono tantissimi. Nella realtà, infatti, per ogni argomento ci sono elementi:

  1. inutili (anche se non ci fossero non cambierebbe nulla);
  2. dannosi (renderebbero il sistema più efficiente se non ci fossero);
  3. non fondamentali per la comprensione (necessari per motivi non tecnici o per motivi tecnici irrilevanti);
  4. duplicati (più elementi che risolvono lo stesso problema);

Molto spesso, inoltre, ci sono anche elementi che:

  1. si studiano successivamente;
  2. si studiano in un corso successivo;
  3. non si studiano;

Un approccio "completamente pratico", quindi, avrebbe l'effetto di fornire una idea estremamente nebulosa sul come funzionano le cose e perché sono state fatte in quel modo. Effetto didatticamente disastroso. Come risolvere questo enorme problema didattico?

Una possibilità potrebbe essere quella di prendere l'approccio opposto: impostare il corso in modo "completamente teorico", prescindendo completamente dall'esperienza quotidiana. Anche questo approccio secondo me è sbagliato, seppur migliore dell'altro.

Cerco quindi di fare un compromesso tra i due estremi. Cerco di individuare per ogni argomento il sottoinsieme delle informazioni necessarie e fondamentali. Per me è molto complicato e faticoso, ve lo garantisco, ma in questo modo si dovrebbe riuscire a capire meglio il come ed il perché. 

Ovviamente quando lo studente cerca di fare la corrispondenza tra quanto fatto a lezione e l'esperienza quotidiana mancano sempre alcuni elementi, pochi o molti ma mancano. A me sembra comunque il male minore, un buon compromesso tra tutti i vincoli e gli obbiettivi.

E' importantissimo che lo studente si faccia sempre domande e cerchi sempre di mettere in corrispondenza quanto visto a lezione con l'esperienza quotidiana. Importantissimo. Occorre però essere consapevoli che la corrispondenza sarà sempre parziale e non del tutto accurata, per i motivi discussi. Occorre inoltre evitare di cadere nell'approccio "questo non lo capisco, quindi non sarà importante o sarà troppo complicato per me"---in questo modo non si capisce nulla. Purtroppo a priori uno non sa se un aspetto sfugge perché è giusto che sfugga oppure perché non lo si è capito o non ci si è riflettuto abbastanza. Studiare è impegnativo, c'è poco da fare.

Ultima osservazione. In ogni argomento cerco di semplificare fornendo parte delle informazioni; quasi mai fornisco informazioni diverse dalla realtà.

A volte mi capita di restringere troppo il sottoinsieme ed effettivamente manca qualcosa, in quel caso cerco di integrare. Questo problema però capita di rado, solo quando faccio modifiche significative al programma. In alcuni casi, pochissimi, invece di descrivere una parte della verità scelgo di descrivere una cosa leggermente diversa dalla verità.

lunedì 2 marzo 2015

Attacchi al DNS

Come sempre, nella prima lezione sul DNS ho richiamato l'attenzione sulla possibilità di alterare in modo fraudolento la traduzione da nomi ad indirizzi IP---ad esempio, www.unicredit.it potrebbe essere tradotto in IP-criminale invece che in IP-del-vero-server.

Ho citato solo alcuni dei numerosi modi per farlo: minacciare l'amministratore del name server con una pistola, inserire un malware nel name server. I modi possibili sono ovviamente moltissimi altri e molti saranno discussi nelle prossime lezioni (avevo peraltro dimenticato di evidenziare che l'amministratore stesso del name server potrebbe essere parte della gang...).

L'alterazione fraudolenta delle traduzioni da nomi ad indirizzi IP non è una possibilità teorica. E' un evento che accade relativamente spesso. Al link qui sotto ho messo una raccolta di notizie di questo genere, dovrebbero essere 75 (settantacinque).

(UPDATE FEBBRAIO 2015: nella pagina al link qui sotto, inserire "DNS" nella casella di ricerca; la pagina adesso non elenca solo news legate al DNS ma anche altre news legate a questo post; se a qualcuno interessano queste bruttissime cose, trova una raccolta aggiornata frequentemente a questo link)

https://www.evernote.com/pub/bartolialberto/news-selected-public