Approfondimenti su privacy e sorveglianza

https://www.schneier.com/blog/archives/2013/11/surveillance_as_1.html

https://bartoli-alberto.blogspot.com/search?q=cambridge

http://crackedlabs.org/en/corporate-surveillance

https://www.newyorker.com/magazine/2018/09/17/can-mark-zuckerberg-fix-facebook-before-it-breaks-democracy 

Cookie con scadenza nel passato (!)

per curiosità stavo analizzando gli header della response che si riceve con questo link amazon:

https://www.amazon.it/gp/goldbox

E mi sono accorto che c'è un set-cookie con expiry date nel passato. Come è possibile ? Si tratta di un errore del server amazon?

Penso proprio che sia un errore nel codice del server amazon.

Errori di questo genere sono descritti, ad esempio, qui:

http://stackoverflow.com/questions/24351257/expires-attribute-points-to-a-date-in-the-past

(non occorre approfondire: l'idea è che, per quanto ne so io, non può essere una situazione voluta dal server).

Ho analizzato il traffico in dettaglio (con lo strumento Fiddler: potente ma non banalissimo da usare con i siti HTTPS per motivi che capiremo alla fine del corso). Ho visto che la situazione è ancora più intricata perché non solo ci sono tanti cookie ma addirittura ci sono più cookie con lo stesso id ma date di scadenza diverse; in particolare (per i valori delle coppie name-value: XXXX l'ho messo io per oscurare i valori veri; - è il valore vero: anche questo è un forte indizio di errore nel codice):

Ci sono 4 cookie con data di scadenza nell'anno 2036:

• Set-cookie: ubid-acbit=XXXXXXXXXXX; path=/; domain=.amazon.it; expires=Tue, 01-Jan-2036 00:00:01 GMT
• Set-cookie: lc-acbit=it_IT; path=/; domain=.amazon.it; expires=Tue, 01-Jan-2036 00:00:01 GMT
• Set-cookie: session-id-time=XXXXXXXXXXX; path=/; domain=.amazon.it; expires=Tue, 01-Jan-2036 00:00:01 GMT
• Set-cookie: session-id=XXXXXXXX; path=/; domain=.amazon.it; expires=Tue, 01-Jan-2036 00:00:01 GMT

Altri 4 cookie con stesso id e data di scadenza nel 2004,

• Set-Cookie: ubid-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: lc-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: session-id-time=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: session-id=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT

Più altri 7 o 8 che scadono nel 2004; 

• Set-Cookie: session-token=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: at-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: x-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: x-wl-uid=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: sess-at-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: UserPref=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT

I cookie del terzo gruppo sono scartati dal browser (già scaduti; non ho verificato nella tabella dei cookie del browser ma penso proprio che sia così).

Per gli altri due gruppi bisognerebbe vedere cosa dice esattamente il protocollo HTTP circa il comportamento da tenere in casi come questo; quale che sia la specifica http, comunque, il browser considera solo il cookie con data di scadenza più avanti nel tempo. Ho verificato questa affermazione ispezionando il contenuto della prima richiesta successiva verso amazon:

Cookie: session-token=YYYYY; x-wl-uid=YYYYY; ubid-acbit=XXXXX; lc-acbit=it_IT; session-id-time=XXXXX; session-id=XXXX

I 2 valori indicati con YYYY dovevano essere già presenti nel mio browser in precedenza. Gli altri 4 valori sono esattamente quelli con scadenza nel 2036, quelli del primo gruppo.

Riflessione

La domanda sorge spontanea: "ma com'è possibile che ci siano errori di questo genere?". La risposta è questa:

1) gli errori che non provocano problemi di funzionalità o sicurezza possono rimanere latenti per molto tempo (= nessuno se ne accorge);

1-bis) anche se qualcuno li scopre, si può decidere di non correggerli o di dare loro una priorità talmente bassa che in pratica non saranno mai corretti (proprio perché non causano problemi di funzionalità o sicurezza);

Riflessione ancora più importante

Questo esempio dovrebbe aiutare a capire ancora meglio il significato di "Come organizzo lo studio di Internet":

...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 dell'argomento;
2. elementi non necessari per il funzionamento e/o non fondamentali per la comprensione;

Gli elementi 2 purtroppo sono tantissimi....

Orwell e Facebook (e i cookie)

Supponiamo di essere sul sito del corriere della sera.

Per il solo fatto di aver visualizzato la home page del corriere ho inviato un centinaio di get /?imgX (e/o eseguito scripit) a un centinaio di siti che mi hanno mandato indietro cookies a fini pubblicitari.

Poniamo però che come diceva lei a lezione, ci siano anche le foto di tutti quelli che sono nella lista di fb che hanno visionato la stessa pagina... questo mi fa pensare a Orwell piuttosto che alla pubblicità...cioè che scopo pubblicitario potrebbe avere il fatto che io sappia che tot miei conoscenti hanno visto la stessa pagina? Siamo comunque già tutti sulla stessa pagina non serve fare ulteriore pubblicità!

Obbiettivo

Utente U1 preleva la pagina P1 sul sito S. La pagina P1 contiene N link. S vuole incoraggiare U1 a prelevare uno o più dei documenti linkati (per motivi evidenti: più pagine vede l'utente, meglio è per S).

Se P1 riesce a mostrare ad U1, accanto ad ogni link, uno o più dei suoi amici Facebook che hanno prelevato quel link, allora U1 forse preleverà quel link. E' un modo per incoraggiare U1 a prelevare quel contenuto.

Da un altro punto di vista, P1 fornisce "contenuti personalizzati a U1, ottimizzati per le sue preferenze" (una di quelle frasi standard scritte nei messaggi relativi ai cookie.

Meccanismo tecnico

Il meccanismo tecnico non è banalissimo ma neanche complicato. Abbiamo tutti gli elementi per comprenderlo. E' più difficile da descrivere che da capire.

La pagina P1 è costruita in modo da avere "accanto" ad ogni link un URL che punta su Facebook. L'URL è funzione della pagina P1 e del link (cioè ogni link su P1 è associato ad un URL diverso su Facebook).

Sia P1-k il k-esimo link su P1 e sia F1-k l'URL di Facebook associato a P1-k.

Quando U1 chiede F1-k a Facebook, Facebook riceve il cookie di U1; se U1 è autenticato, allora Facebook è in grado di capire lo username Facebook di U1 e, quindi, gli amici di U1. A questo punto Facebook analizza quali amici di U1 hanno prelevato P1-k (informazione che Facebook ha raccolto in precedenza con le tecniche solite), sceglie in qualche modo un amico "caro" e quando torna a U1 il documento F1-k ci mette dentro la foto di quell'amico.

Osservazione

Nella realtà ciò che viene fatto più spesso non è mettere accanto ad ogni link una lista di amici, ma mettere su ogni pagina una lista di amici che hanno visto quella pagina e hanno clickato su "like". 

In questo caso l'interesse è incoraggiare l'utente a premere like perché ciò fornisce un forte segnale sulle preferenze e sui gusti dell'utente. Segnale molto più forte della sola visione di un contenuto e che poi può essere sfruttato in molti modi. 

Con la notazione sopra, P1 non contiene URL verso Facebook (o meglio, non contiene contenuto visibile prelevato da Facebook; contiene contenuto prelevato da Facebook ma invisibile); ogni pagina linkata da P1 ha URL verso Facebook (l'immagine qui sopra mostra il contenuto di tale URL). Quando l'utente preleva tale URL, Facebook applica un meccanismo analogo a prima.

Invio dati a web server

ho un dubbio per quanto riguarda l’invio di dati al Web Server. Abbiamo detto che a seconda del valore di METHOD il browser fa una richiesta di tipo GET oppure POST. 

Se la richiesta è di tipo GET sarà del tipo: 

GET / script?QueryString 

….

linea vuota 

Non mi è ben chiaro perché, se usiamo GET per richiedere dei dati al server, aggiungiamo in coda allo script la QueryString. 

Perché il mondo reale è fatto di cose brutte e fatte male. Ormai dovrebbe essere chiaro. GET in inglese ha centomila significati, moltissimi legati al concetto di "prendere". Le richieste GET si usano per prendere documenti da un server. Purtroppo si usano anche per inviare dati ad un server, usando quel meccanismo ignobile (query string appesa in coda all'URL; il programma eseguito dal server estrae i dati dalla query string).

Non c'è quindi un motivo logico. E' così.

Anche in questo caso stiamo trasmettendo dei dati al server? 

Si, vedi sopra.

E' il caso di quando inseriamo dei dati nel motore di ricerca? 

Quando si inseriscono dati in un motore di ricerca, questi possono essere trasmessi con GET oppure con POST. Dipende da come è fatto il documento che ha inviato il motore di ricerca e da come è strutturato il programma del motore di ricerca.

Google invia dati tramite GET. Lo si può capire con i developer tools di chrome, o con un qualsiasi software in grado di mostrare il traffico HTTP. Lo si può capire anche analizzando la home page di google:

Lo si può capire indirettamente anche in questo modo: https://www.google.it/search?q=trieste

Clickando su quel link il browser esegue le stesse operazioni che esegue per ogni altro link, cioè invia una richiesta GET verso l'URL visualizzato (ho costruito il link in modo che il testo visualizzato coincida con l'URL). Il documento che si ottiene come risposta è la risposta standard di Google. Pertanto, Google è predisposto per ricevere dati via GET.

Inviando i dati a Google nel modo "canonico" (cioè nel form di google.it) si ottiene un documento di risposta il cui URL ha una query string con più coppie nome=valore (sopra ce n'era solo una). Ad esempio:

https://www.google.it/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=grande%20kaka

Clickando su questo link si ottiene ancora lo stesso documento di risposta (o lo si dovrebbe ottenere). Soprattutto, si osservano cose buone e giuste.

HTTP: Autenticazione su webmail di ateneo

ATTENZIONE: informazioni del 2010

Le riporto il traffico HTTP effettuato con il browser IE e con FIREFOX inerente l'accesso alla casella di posta universitaria sul web.

(riportati qui sotto, dopo la mia risposta)

qui purtroppo intervengono aspetti che a lezione non vediamo; si fanno a Reti II.

Il server risponde dicendo: ti devi autenticare, io supporto 3 meccanismi: "mettiamoci d'accordo" (negotiate), NTLM, Basic;

Firefox sceglie NTLM (che a reti non facciamo) e dopo uno scambio un pò intricato riesce ad autenticarsi

IE sceglie invece il "mettiamoci d'accordo" e non riescono a mettersi d'accordo (!). Il che è singolare perché il server è Microsoft ed il browser è Microsoft, pertanto dovrebbero essere in grado di mettersi d'accordo. Non so perché non riescano a mettersi d'accordo, sospetto che il motivo sia questo:

*) il client (per come è configurato) se gli viene proposto negotiate allora lo sceglie; 

*) il server è stato configurato in modo che quando il client chiede "negotiate", allora il server accetta solo un terzo meccanismo che a reti non si fa e che si chiama Kerberos;

*) questo particolare client non supporta Kerberos e quindi non si mettono d'accordo.

altro esempio di quello che dico spesso: per capire le reti bisogna sforzarsi di guardare alla realtà con molta elasiticità. altrimenti non si capisce nulla di nulla...la realtà è troppo complicata per la presenza di molti dettagli concettualmente irrilevanti.

INTERNET EXPLORER

GET http://webmail.ing.units.it/exchange HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: webmail.ing.units.it
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279

 

HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:23 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange HTTP/1.1Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
Host: webmail.ing.units.it

 

HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAABAAEADgAAAAVgonieK1Rw6d8At8AAAAAAAAAAIAAgAA8AAAABQLODgAAAA9EAFMAAgAEAEQAUwABABAAUwBFAFIAVgBJAE4ARwA1AAQAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQAAwAoAHMAZQByAHYAaQBuAGcANQAuAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAAFABYAZABzAC4AdQBuAGkAdABzAC4AaQB0AAAAAAA=
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:49 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange HTTP/1.1Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279
Host: webmail.ing.units.it
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAIoAAAAoASgBogAAABIAEgBYAAAADgAOAGoAAAASABIAeAAAABAAEADKAQAAFYKI4gYBsB0AAAAPIsy0u8P/lxYEmbDGLaL7gEEAVABDAE8ATABEAC0AUABDAFMAMQA2ADQAOAA5ADkAQQBUAEMATwBMAEQALQBQAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANCk2viZwkvSHk8AbOtkAUgEBAAAAAAAAZuwxU4TLygFtPP91tzPSFAAAAAACAAQARABTAAEAEABTAEUAUgBWAEkATgBHADUABAAWAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAADACgAcwBlAHIAdgBpAG4AZwA1AC4AZABzAC4AdQBuAGkAdABzAC4AaQB0AAUAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQACAAwADAAAAAAAAAAAQAAAAAQAAA+miYJ4qikKJ0o7U6X5Ryt52Zp6HPnj1joaoPJKowOzwoAEAAAAAAAAAAAAAAAAAAAAAAACQAsAEgAVABUAFAALwBzAGUAcgB2AGkAbgBnADUALgB1AG4AaQB0AHMALgBpAHQAAAAAAAAAAACb9zENiofg6F4C/UqLme4C

 

HTTP/1.1 401 Unauthorized
Content-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:49 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

FIREFOX

GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279

 

HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==

 

HTTP/1.1 401 Unauthorized
Content-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM TlRMTVNTUAACAAAABAAEADgAAAAFgomik7/eomb8S4kAAAAAAAAAAIAAgAA8AAAABQLODgAAAA9EAFMAAgAEAEQAUwABABAAUwBFAFIAVgBJAE4ARwA1AAQAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQAAwAoAHMAZQByAHYAaQBuAGcANQAuAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAAFABYAZABzAC4AdQBuAGkAdABzAC4AaQB0AAAAAAA=
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAuAS4BkAAAAAAAAABYAAAADgAOAFgAAAASABIAZgAAAAAAAAC+AQAABYKIogYBsB0AAAAPtdAL6R8OtcOJ2I7rO8AwzVMAMQA2ADQAOAA5ADkAQQBUAEMATwBMAEQALQBQAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgJ4MAUjYi3OHIWebOJCt/wEBAAAAAAAAZSUYNoXLygFx/gJjFIX+AAAAAAACAAQARABTAAEAEABTAEUAUgBWAEkATgBHADUABAAWAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAADACgAcwBlAHIAdgBpAG4AZwA1AC4AZABzAC4AdQBuAGkAdABzAC4AaQB0AAUAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQACAAwADAAAAAAAAAAAQAAAAAgAAA+miYJ4qikKJ0o7U6X5Ryt52Zp6HPnj1joaoPJKowOzwoAEAAAAAAAAAAAAAAAAAAAAAAACQAyAEgAVABUAFAALwB3AGUAYgBtAGEAaQBsAC4AaQBuAGcALgB1AG4AaQB0AHMALgBpAHQAAAAAAAAAAAA=

 

HTTP/1.1 302 Object MovedContent-Length: 160
Content-Type: text/html
Location: http://webmail.ing.units.it/exchange/
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT

 

<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://webmail.ing.units.it/exchange/">here</a></body>

 

GET http://webmail.ing.units.it/exchange/ HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279

 

HTTP/1.1 200 OKDate: Wed, 24 Mar 2010 19:07:10 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/html
Content-Length: 1168
MS-WebStorage: 6.5.7638
Cache-Control: no-cache

 

<!--Copyright (c) 2000-2003 Microsoft Corporation. All rights reserved.-->
<!--CURRENT FILE== "NON-IE5" "NON-WIN32" frameset -->
<!--CURRENT TEMPLATE == frameset.00000000 -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<TITLE>Microsoft Outlook Web Access</TITLE>
<BASE href="http://webmail.ing.units.it/exchange/s164899/">
</HEAD>
<SCRIPT language="JavaScript">
var g_iNewWindowWidth = 700;
var g_iNewWindowHeight = 500;
var g_fWarnOnLogOff=false;
function WarnOnLogOff()
{
if (g_fWarnOnLogOff)
alert("Per evitare che utenti non autorizzati accedano alla cassetta postale, chiudere tutte le finestre del browser dopo aver utilizzato Outlook Web Access.");
}
</SCRIPT>
<FRAMESET OnUnload="WarnOnLogOff()" framespacing="3" cols="190,*"><FRAME bordercolor="#3D5FA3" name="navbar" title="Esplorazione" src="./?Cmd=navbar" marginheight="0" marginwidth="0" scrolling="auto" border="1"><FRAME name="viewer" title="Sommario" src="Posta%20in%20arrivo/?Cmd=contents" scrolling="auto">
<NOFRAMES>
<BODY><P>This page uses frames, but your browser doesn't support them.</P></BODY>
</NOFRAMES>
</FRAMESET>
</HTML>

 

GET http://webmail.ing.units.it/exchange/s164899/?Cmd=navbar HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://webmail.ing.units.it/exchange/
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279

 

HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange/s164899/Posta%20in%20arrivo/?Cmd=contents HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://webmail.ing.units.it/exchange/
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279

 

HTTP/1.1 200 OKDate: Wed, 24 Mar 2010 19:07:10 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/html
Content-Length: 64948
MS-WebStorage: 6.5.7638
Cache-Control: no-cache

 

// SEGUE DOCUMENTO HTML

HTTP: notazione da usare per URL rewriting

http://bartoli-alberto.blogspot.it/search?q=url+rewriting

HTTP: attacchi alle sessioni

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.

http://bartoli-alberto.blogspot.it/2015/03/io-sono-un-numero.html

HTTP: Uso proxy

E' una scelta delle grandi organizzazioni quella di usare il Proxy HTTP? E' giusto che io da casa mia guardando nelle mie impostazioni di rete non sia collegato a nessun Proxy?

non tutte le organizzazioni usano proxy, pertanto può accadere che da casa uno non sia collegato tramite proxy.

HTTP: sessioni con più server

quando mi collego ad una pagine web faccio richieste a tanti server diversi, con ognuno di loro ho una sessione?

"mi collego ad una pagina web" non significa nulla.

l'elaborazione di una richiesta da parte di un server web viene effettuato in modo del tutto autonomo, senza contattare altri server web; questo dovrebbe essere chiaro;

quindi, un server S1 decide se creare o non creare una sessione in modo del tutto autonomo;

quindi, quando un browser contatta N server diversi, sarà creato un numero di sessioni variabile tra 0 ed N a seconda di cosa decide di fare ogni server.

nelle provette/esami, lo studente deve fare svolgimenti coerenti con quanto richiesto nell'esercizio; ovviamente, se si può evitare di creare una sessione allora conviene fare uno svolgimento che non la crea (in quanto si minimizza la probabilità di errori e si risparmia tempo); altrettanto ovviamente, se è richiesto esplicitamente di creare una sessione oppure sono citate funzionalità per le quali la creazione di una sessione è necessaria, allora la sessione deve essere creata.

HTTP: redirection dopo autenticazione

Negli esercizi in cui viene richiesta Form authentication, una volta che mi sono autenticata (dopo aver inviato la richiesta POST) devo scrivere la risposta:

               HTTP 1.1 301 Found

               Location: ….

               <LV>

       E quindi fare una redirection e richiedere nuovamente il file con GET,

       oppure posso scrivere direttamente la risposta che contiene il file richiesto?

E' lo stesso.

Nella realtà avviene quasi sempre la redirection, ma ai fini degli esami è lo stesso.

HTTP: scambio messaggi con autenticazione

Autenticazione basic: 

- Dopo la richiesta del documento protetto, la response( che apre la finestra delle credenziali) deve contenere gli header Content-type: text/html e Content-lenght: L ? 

Dipende. 

In linea di principio una response con status 401 Unauthorized potrebbe non trasportare alcun documento (lo header WWW-Authenticate è sufficiente a istruire il browser su cosa fare). In pratica response di questo genere spessissimo trasportano un documento HTML che dice "non sei autorizzato e ti devi autenticare" o qualcosa del genere. In questo caso, ovviamente, gli header della response devono descrivere tipo e lunghezza del documento trasportato, con gli header che lei ha indicato.

- se ci fosse url rewriting, bisogna modificare gli url contenuti nella finestra delle credenziali? Se così fosse, vuol dire che nel tasto "Accedi" c'è l'url modificato del documento che sto chiedendo? Cioè, visto che il browser dovrebbe mandare una richiesta identica alla precedente, come fa a sapere di aggiungere all'url l'identificazione di sessione?

O non ho capito la domanda o sta facendo grossa confusione.

Con autenticazione BASIC il browser NON segue nessun URL. La "finestra delle credenziali" non è un documento inviato dal server, è una finestra aperta dal browser in reazione ad uno header contenuto nella response (lo header WWW-Authenticate). Quindi non c'è nessun URL da riscrivere in quella response.

------------------------

Per quanto riguarda la FORM Authentication, se devo prelevare un documento, ad esempio offerte.html per cui necessita un’autenticazione, una possibile sequenza di request/response può essere la seguente?

GET /offerte.html http 1.1Request HeaderLV

HTTP 1.1 200 OKResponse HeaderLVDocumento html che contiene la Login Page (cioè il form)

PRIMA di inviare la response qui sopra il server ha aperto una sessione. Se usa i cookie allora la response mantiene i cookie. Se usa URL rewriting allora il form deve avere gli URL modificati.

NB: nei compiti e negli esami i FORM devono essere descritti esplicitamente; almeno i valori degli attributi DEVONO essere scritti.

POST credenziali   (In questo punto più precisamente come funziona?) VEDI SLIDE; le credenziali sono dei dati inseriti in un form; form identico a qualsiasi altro form

Request headerLV

Se le credenziali sono errate il server risponde con      

http 1.1  301 UnauthorizedResponse headerLvDocumento in cui dico che non è autorizzato

Se le credenziali sono corrette 

http 1.1 200 ok
response headerlv/offerte.html (o comunque il documento richiesto)

Aggiungo che in una provetta o negli esami è necessario inserire gli header che nelle slide ho definito essere irrinunciabili (Host, Referer, etc)

-------------------------

Supponiamo di avere un realm “Foto” a cui si puo’ accedere solo tramite Basic Authentication, e contenente solo immagini.

Quando io invio la richiesta:

GET /a/img.gif HTTP 1.1Request HeadersLV

Il server mi risponde:

HTTP 1.1 410 Unauthorizedwww-Authenticate:
......LV

Ora il dubbio che mi sono posto è:

all’interno della request successiva, l’URL relativo /a/img.gif sarà già modificato (del tipo GET /a/img.gif?ID=id1) o siccome la risposta (scritta sopra) del server non fornisce alcun documento, il server stesso non ha ancora modificato gli URL relativi?

La sessione viene creata alla ricezione della prima request (perché questa non trasporta nessun identificatore di sessione).

Ma la prima response non contiene nessun URL. Se la sessione viene mantenuta con URL rewriting, quindi, la seconda request non conterrà alcun identificatore di sessione; quindi il server non sarà in grado di capire che la seconda request appartiene ad d una sessione; quindi creerà un'altra sessione.

HTTP: sessioni con web hosting

Supponiamo di avere un server che contenga più di un sito web 

per esempio contiene    www.units.it   e   www.abbassojuve.com    

questo vuol dire che il server ha due nomi , e per quei due nomi l'indirizzo IP è lo stesso; 

se il mio browser richiede  il documento www.units.it  ( la home page)  e viene creata una sessione tramite tecnica url rewriting  il server mi riconosce se richiedo URL presenti  nel documento ma  se accedo a www.abbassojuve.com  la sessione non c'è più? 

Non è che "la sessione non c'è più". Non è mai esistita. 

Una sessione identifica una sequenza di richieste tra un browser ed un server web. Le nozioni di "browser" e "server web" sono semplici se si definiscono intuitivamente. Sono più complicate se uno vuole (giustamente) definirli in modo completo e preciso.

Per definire cosa sia un browser, infatti, occorre tenere conto del fatto che tutti i tab in una stessa window condividono le sessioni; window diverse non in incognito condividono le sessioni.

In questo contesto, un server web è un server web "virtuale": occorre cioè immaginare che tutti gli URL con lo stesso nome di server (seconda parte dell'URL) sono associati ad un server (appunto, virtuale) che gestisce solo quegli URL; URL con nome di server diverso è come se fossero associati ad un server diverso.

HTTP: Header host

 si puó concludere che l'Header Host contiene sempre il nome del Server verso cui è inviata la Request?

Si, con l'osservazione che un server può ospitare più siti (lasciando perdere cosa sia esattamente un sito"). Quindi "il nome" è in realtà "uno dei nomi".

Da quanto ho capito io lo header HOST va messo all’interno di una request HTML solo nel caso in cui un web server “ospita” tanti siti web...se ad un web server corrisponde un unico sito web non ha alcun senso. E’ corretto? Inoltre, per quanto gli esercizi, come faccio a capire se effettivamente un server ha uno o più siti web al suo interno, e quindi se devo o no mettere lo header HOST?

a parte il fatto che la request è HTTP, lo header Host va inserito sempre. Il browser non può infatti sapere se il server ospita più siti web

HTTP: inserimento delle pubblicità

Quando è andato sul sito americano per vedere il suo user agent la pubblicità era in italiano. Come mai?
anche qua mi son fatto le mie idee
o il sito ha varie pubblicità principali e in base all'accept language e altri header mostra quella più giusta
oppure la pubblicità è gestita da terzi 

Entrambe le ipotesi sono corrette, ma la seconda nella realtà è più complicata di quello che possa apparire in base a quanto visto sinora.

Nella stragrande maggioranza dei casi le pubblicità sono effettivamente gestite da terzi: cioè se prelevo una pagina da un sito S1, la pagina ha sempre delle componenti che prelevo da altri siti diversi da S1 e specializzati nella somministrazione di pubblicità; il sito che sceglie la pubblicità vede lo header Accept-Language inviatogli dal browser e sceglie di conseguenza.

In pratica, però, nella scelta ci mette anche moltissimi altri ingredienti, ad esempio relativi alla "storia di navigazione" del browser. Al momento non siamo però in grado di capire come sia raccolta quella storia e come sia associata ad ogni browser. Lo capiremo già nelle prossime lezioni (cookie).

HTTP: Significato di content-length

In una slide la content-Length specificata è 2870 ma il data è solo 1176
Ho pensato a 2 possibilità
Nel content-Length vengono calcolati anche gli header e altre informazioni inviate, oppure il data è compresso. È per caso giusta la mia idea?

Giusta osservazione.

Il fatto che il valore di content-length non coincida con la lunghezza dei dati che seguono la linea vuota può avere due spiegazioni:

1) il documento trasportato dalla HTTP response è compresso; non è però il caso della slide, in quanto una HTTP response che trasporta un documento compresso deve avere uno header Content-Encoding il cui valore descrive la trasformazione applicata al documento (compressione); ciò permette al browser di applicare la trasformazione opposta prima di usare il documento; in assenza di tale header, il browser non può che assumere che il documento non sia stato trasformato;

2) lo capiremo nella seconda parte del corso;

essenzialmente, ciò che mostra la slide non è una HTTP response intera, ma è un messaggio trasportato dalla network Ethernet; la HTTP response viene spezzata in più messaggi Ethernet, perché è troppo grande per essere contenuta in un unico messaggio Ethernet; questi dettagli, e molti altri, sono (fortunatamente) del tutto invisibili alle applicazioni; chi usa un servizio di comunicazione (nel nostro caso TCP) non ha necessità di sapere come funziona internamente quel servizio; basta sapere cosa offre quel servizio ai propri utenti;