Pubblicità, statistiche, profilazione e FoolDNS

Il Web sta (ri)scoprendo la pubblicità come forma di guadagno. Il problema non sono le inserzioni pubblicitarie in senso stretto, ma la profilazione che sta dietro ad esse.

La profilazione (Behavioral targeting) si perfeziona sempre più arrivando a proporre prodotti e/o servizi ai quali si è vulnerabili; per i quali si ha un interesse particolare.
Nessuno ha notato i servizi introdotti su YouTube dopo l’acquisizione da parte di Google?

Un anno fa insieme a Matteo Flora abbiamo condotto delle ricerche sulla diffusione, nel panorama blog Italiano, a riguardo di network di inserzioni pubblicitarie e di statistiche sulle visite. I risultati sono stati tutt’altro che confortanti. Google con i suoi AdSense e Analitycs ha una penetrazione intorno al 90% della blogosfera italiana.

Non è strano che Google dopo aver acquistato la Urchin Software ha reso gratuito un software, Urchin poi rinominato Google Analytics, che prima costava centinai di dollari al mese nella versione out-sourced? Per precisione di cronaca va detto che la versione gratuita di Google Analytics non comprende tutte le features di Urchin, per quelle è necessario abbonarsi.

Oltre ad usare plug-in specifici come NoScript, CustomizeGoogle, AdBlock, ecc c’è un metodo più semplice e trasparente per l’utente finale.
Nato da un’idea sviluppata grazie ai dati emersi dal talk, FoolDNS è un servizio di DNS creato per proteggere la privacy e bypassare i filtri censori dello stato Italiano. Un servizio che rende la navigazione più piacevole. Niente più JavaScript (inserzioni pubblicitarie e tool di statistiche) di tutti quei network che collezionano dati di navigazione senza una esplicita dichiarazione. L’idea di fondo è una gestione “casalinga” di inserzioni pubblicitarie e statistiche: perchè doversi accontentare degli spiccioli che network di inserzioni regalano per ogni click e utilizzare prodotti in out-sourcing per le statistiche?!
Grazie all’invito nella beta, dopo una settimana di utilizzo, non ho riscontrato problemi. La navigazione risulta estremamente pulita e piacevole sapendo anche che non vengono caricati JavaScript dalla dubbia utilità.

Il servizio, a detta anche delle statistiche, promette molto bene:
489378 richieste evase negli ultimi 7 giorni, più di 100.000 banner bloccati e più di 200 utenti attivi.

I 10 domini più richiesti sono:

  1. mail.google.com
  2. www.google.com
  3. www.facebook.com
  4. twitter.com
  5. profile.ak.facebook.com
  6. www.test.fool
  7. www.google.it
  8. feeds.feedburner.com
  9. safebrowsing.clients.google.com
  10. www.google-analytics.com

Per i più curiosi quelle che seguono sono le url ordinate per maggior numero di banner sostituiti da FoolDNS:

  1. http://www.repubblica.it/index.html
  2. http://www.repubblica.it
  3. http://home.myspace.com/index.cfm
  4. http://messaging.myspace.com/index.cfm
  5. http://www.libero.it
  6. http://www.youtube.com
 

SQL Injection: think out of the box

SQL Injection

In Spagna si lavora ad un sistema automatizzato per la gestione e la registrazione delle infrazioni stradali e relative multe. A tal scopo sarà utilizzato un database centralizzato in modo da poter smistare e verificare la mole di dati nazionali.
Il sistema sarà basato sul riconoscimento automatico delle targhe inviando così al database tutti i dati delle infrazioni.

L’immagine, presa da Alfredo Reino, è volutamente provocatoria ma quanto così distante dalla realtà?

Non sono l’unico ad aver pensato alle ZTL Italiane ed in particolare all’Ecopass di Milano: “Sql injection sul Gate di Milano?

Grazie a pollycoke per l’assistenza sugli articoli in lingua spagnola.

 

PayPal introduce le policy per le segnalazioni di vulnerabilità

Tramite Jeremiah Grossman leggo che PayPal ha pubblicato una pagina contene la “vulnerability disclosure policy“. Essa permette ai (Web application) security researchers di segnalare vulnerabilità trovate in PayPal senza rischiare azioni legali.

Ovviamente l’immunità è garantita solamente a chi rispetta la policy:

Guidelines for responsible disclosure

  • Share the security issue with us before making it public on message boards, mailing lists, and other forums.
  • Allow us reasonable time to respond to the issue before disclosing it publicly.
  • Provide full details of the security issue.

Non è tollerato, come è normale aspettarsi, l’uso della vulnerabilità per accedere a dati di cui normalmente non si possiede l’autorizzazione, pretendere una somma di denaro in cambio delle informazioni dettagliate della vulnerabilità o causare un D0S all’intero sistema PayPal.

La policy porta a porsi qualche domanda come evidenziato da Chris Shiflett, ma sicuramente le buone intenzioni ci sono e per migliorare siamo sempre in tempo. Credo che sia la prima volta che una grossa azienda mette nero su bianco un comportamento del genere per incoraggiare chiunque a segnalare preventivamente le vulnerabilità al team di competenza.
Google, Microsoft e Yahoo hanno delle policy simili, ma ancora, al contrario di PayPal, non si fa menzione di possibili rivolti legali per le vulnerabilità segnalate.

Questa notizia non dovrebbe interessare solamente agli addetti ai lavori ma anche ai semplici clienti/utenti, una grossa azienda che gestisce i nostri dati personali (o ancor peggio i nostri risparmi) non deve nascondere eventuali attacchi o vulnerabilità di sicurezza. Solitamente infatti, non solo non esiste una policy ben precisa sul comportamento che l’azienda terrà nei confronti di chi segnala una vulnerabilità ma addirittura non è ben chiaro a chi segnalare i dettagli di essa.

 

Scontri informatici tra Estonia e Russia

Avevo letto la notizia qualche giorno fa senza dargli peso, oggi passandomi tra le mani un approfondimento ho capito che merita parlarne.

Tutto è iniziato a causa dello spostamento di una statua eretta alla fine della seconda Guerra Mondiale in memoria dei soldati dell’Armata rossa caduti nella liberazione dell’Estonia dall’invasione nazista. La repubblica estone perse la propria indipendenza per mano sovietica nel 1939 in seguito del Patto Molotov-Ribbentrop, riguadagnandola solo nel 1991. La rimozione della statua, dettata da una legge del 2006 contro la pubblica esibizione di monumenti rappresentanti l’occupazione sovietica, ha causato l’indignazione della minoranza russa in Estonia e del senato Russo e successivamente un attacco DDoS su larga scala.

L’attacco informatico iniziato il 27 Aprile scorso, ha preso di mira, come spiegato da Hillar Aarelaid del CERT Estone, siti Web di banche, scuole e quello del primo ministro causando non pochi danni all’interno della nazione.
Secondo Jose Nazario, l’attacco DDoS è stato fatto tramite tre diverse tecniche: ICMP floods, TCP SYN floods e floods tramite richieste generiche. Sembra che tra le sorgenti di attacco (presumibilmente una botnet) vi sia oltre a Brasile, Canada, U.S. e Vietnam anche la Russia.
In un primo momento era stato puntanto il dito contro il governo Russo, ma più approfondite analisi hanno portato a pensare che vi fossero “semplici” cittadini (nazionalisti) dietro gli attacchi. Fatto sta che il CERT Estone riceverà l’aiuto niente meno che dalla NATO (North Atlantic Treaty Organization, tengo a sottolineare). Lo scopo dell’organizzazione internazionale, nata da una temuta invasione sovietica dell’Europa occidentale, è riassunto in maniera esaustiva nell’articolo 5 del Trattato Atlantico:

Le parti convengono che un attacco armato contro una o più di esse in Europa o nell’America settentrionale sarà considerato come un attacco diretto contro tutte le parti, e di conseguenza convengono che se un tale attacco si producesse, ciascuna di esse, nell’esercizio del diritto di legittima difesa, individuale o collettiva, riconosciuto dall’ari. 51 dello Statuto delle Nazioni Unite, assisterà la parte o le parti così attaccate intraprendendo immediatamente, individualmente e di concerto con le altre parti, l’azione che giudicherà necessaria, ivi compreso l’uso della forza armata, per ristabilire e mantenere la sicurezza nella regione dell’Atlantico settentrionale. Ogni attacco armato di questo genere e tutte le misure prese in conseguenza di esso saranno immediatamente portate a conoscenza del Consiglio di Sicurezza. Queste misure termineranno allorché il Consiglio di Sicurezza avrà preso le misure necessarie per ristabilire e mantenere la pace e la sicurezza internazionali.

Siamo di fronte ad un pezzo di storia?

 

HttpOnly Cookie implementati in Firefox 3

L’attributo HttpOnly dello header HTTP “Set-Cookie” serve per rendere invisibile un cookie ai linguaggi client-side come JavaScript.
Tramite questa tecnica, sviluppata da Microsoft, un browser invierà i cookie di un dominio solamente al server contattato inibendone, ad esempio, la lettura tramite il classico “document.cookie” di JavaScript.

HttpOnly Cookie è stato implementato per la prima volta in IE 6 sp1, da pochi giorni è stato integrato di default anche nella terza beta di Firefox 3.

HttpOnly è ancora una tecnologia poco utilizzata: è stata implementata ufficialmente su PHP dalla versione 5.2 Ci sono però dei workaround per utilizzarla anche sulle versioni precedenti.

Per chi volesse provare HttpOnly su Firefox 2 può usare l’estensione “httpOnly” scritta da Stefan Esser. L’estensione non segue la vera implementazione usata da Microsoft: tutti i cookie in arrivo, contrassegnati dal flag HttpOnly vengono criptati con AES tramite un hook di Firefox. Un altro hook decripta i cookie solo quando vengono inviati tramite HTTP, in questo modo i cookie ottenuti tramite JavaScript saranno inutilizzabili perché criptati.

Segnalo inoltre, che da poche ore sono stati rilasciati Firefox 2.0.3 e Firefox 1.5.0.11 che correggono alcuni bug di sicurezza venuti alla ribalta negli scorsi giorni.