I blog gratuiti di Blogger vengono da oggi rediretti al dominio blogspot.it (se aperti dall'Italia).

Per essere più chiari facciamo un esempio pratico.

Un mio blog che uso per fare dei test ha questo URL

http://design-prova.blogspot.com

Se adesso verrà aperto da un navigatore situato in Italia, nella barra del browser si vedrà questo URL

http://design-prova.blogspot.it

Se invece venisse aperto da un utente che si trova inSpagna, sarebbe visualizzato con l'URL

http://design-prova.blogspot.es

e così via per tutti gli altri Paesi.

Se provate a modificare l'estensione finale del vostro blog, inserendo quella tedesca, francese o di qualsiasi altro Paese, risiedendo però in Italia,non trovereste il vostro blogma un altro sito o un messaggio di errore.L'estensione finale dipende dall'IPche indica la nostraposizione geografica. Il primoPaesein cui è avvenuto questo redirect credo sia stato l'India e adesso è il turno dell'Italia o forse la cosa è stata generalizzata a tutto il mondo.

Vengono anche a modificarsi gli indirizzi dei singoli URL. Per esempio questo post

http://design-prova.blogspot.com/2012/02/demo-del-codice-qr-inserito-nel-blog.html

verrà rediretto all'URL

http://design-prova.blogspot.it/2012/02/demo-del-codice-qr-inserito-nel-blog.html

Questa ultima cosa è probabile che impieghi diverse ore se non giorni per essere completata.

LE RAGIONI DEL CAMBIAMENTO DI URL

Secondo Google questa modifica è stata resa necessaria per una gestione locale dei contenuti. Sappiamo che ci sono molte differenze culturali, politiche e giuridiche tra i vari Paesi in cui è presente la piattaforma Blogger.

Il Team di Google riceve continue richieste di rimozione di contenuti dalle varie autorità locali. Con questo metodo, un post o un intero sito verrebbe quindi oscurato solo nel Paese che ne ha fatto richiesta o su cui si è pronunciata la magistratura mentre rimarrebbe regolarmente online per il resto del mondo. Questo nuovo sistema, secondo Google, riesce a conciliare le diverse esigenze della libertà di espressione e del rispetto della legislazione locale.

Un cittadino italiano potrebbe per esempio chiedere alla magistratura il blocco di un sito di Blogger che, nel caso la richiesta venisse accolta, non sarebbe più visibile in Italia ma resterebbe regolarmente online in tutto il resto del mondo.

SARA' SEMPRE POSSIBILE ACCEDERE ALLA VERSIONE ORIGINALE DI UN BLOG

Non c'è censura che tenga perché anche se un sito venisse oscurato in un Paese, i cittadini ivi residenti potranno accedervi digitando alla fine dell'URL la stringa /ncr che è l'acronimo di "No Country Redirect". Rimando in tema con l'esempio di inizio post, si potrà accedere al suo indirizzo canonico digitando

http://design-prova.blogspot.com/ncr

Se fosse oscurato un solo post, per accedervi dovremmo inserire /ncr subito dopo in dominio del Paese. Prendendo l'esempio di prima, dovremo digitare

http://design-prova.blogspot.com/ncr/2012/02/demo-del-codice-qr-inserito-nel-blog.html

CONSEGUENZE E DOMINI PERSONALIZZATI

Tutti coloro che hanno acquistato da Google o hanno configurato da soli un dominio personalizzato come è per esempio il caso di questo blog non saranno in alcun modo interessati da questa modifica. Chi invece ha un dominio gratuito potrebbe avere delle spiacevoli sorprese nel breve periodo

1. I Mi Piace su Facebook o il numero di Tweet ricevuti da un articolo potrebbero azzerarsi e non si sa se questa sarà una cosa momentanea (la più probabile) o se perdurerà nel tempo.
2. Ciascun blog gratuito avrà decine di domini che porteranno allo stesso sito (tanti quanti sono i Paesi del mondo in cui viene supportata questa nuova funzionalità). Questo potrebbe portare a un rilevamento di contenuti duplicati per Google inteso come motore di ricerca. Il Team di Bloggerha già dichiarato che correrà ai ripari configurando nei suoi server quello che si chiama URL Canonico ma nel breve periodo potrebbero verificarsi dei problemi.
3. Quale URL si dovrà inserire quando vorremo indicare il nostro blog? In linea teorica si può mettere sia l'URL canonico, cioè .com, sia quello locale vale a dire .it. Però per non avere troppi redirect è consigliabile cercare di usare il più possibile l'URL con il .com
4. Nel caso ci fossero delle novità sarà mia cura aggiornare questo post

Aggiornamento n°1: Alcuni widget come quello dei Lettori hanno smesso di funzionare. Nono si visualizzano più alcune icone di accesso rapido come il Quick Edit e quella del cacciavite e della chiave inglese. Su alcuni blog è scomparso anche il pulsante Elimina sotto i commenti nidificati quindi per procedere a cancellare i commenti si deve necessariamente andare nella Bacheca.

Aggiornamento n°2: E' stato azzerato il Page Rank dei blog con estensione locale. Sicuramente non porterà a una diminuzione delle visite però è scocciante.

La subdola minaccia del Cross Site Scripting

Al contrario del mondo reale, in quello virtuale la distanza non ha alcuna importanza e la diffusione di Internet ha creato una sorta di enorme megalopoli che ci permette di vivere allo stesso tempo in perfetta solitudine o in mezzo a una moltitudine. Parlando di sicurezza, nel mondo reale la distanza è un parametro fondamentale visto che la minaccia deve essere fisicamente vicina. Lo stesso ovviamente non vale per il mondo virtuale dove chiunque è soggetto a minacce che possono arrivare da qualsiasi parte della rete e perciò molto più frequentemente.

Il cross site scripting è una tipologia di attacco che può essere portato a compimento anche se solo uno dei tre attori principali della società informatica sono incauti: utenti, sviluppatori e amministratori di sistema.

Come funziona

Il cross site scripting è un attacco informatico prodotto da un hacker che consiste nell’iniettare uno script in una applicazione web vulnerabile, la quale inconsapevolmente farà eseguire lo script nel browser dei suoi utenti.

Un primo schema molto semplificato è il seguente:

causerà la formattazione a titolo di tutto 

L’hacker in qualche modo avvelena il sito web facendo si che le pagine richieste da un utente contengano lo script realizzato dall’hacker.

La prima domanda che salta in mente allo sviluppatore riguarda la sicurezza degli script. Non erano forse stati pensati per essere intrinsecamente sicuri? Sappiamo infatti che gli script possono accedere ad un numero limitato di risorse e che il browser impedisce loro, tra le altre cose, di accedere ad un arbitrario file su disco o di eseguire chiamate di sistema. Il fatto è che gli script possono essere considerati sicuri in quanto eseguiti nel contesto dell’applicazione web per cui sono stati scritti. Non è certamente di interesse per un sito divulgare le  informazioni sensibili che gli sono state affidate dall’utente. Diverso è se lo script è pensato da qualcuno che vuole rubare queste informazioni.

Rivalutando gli script in quest’ottica, ecco che le risorse a cui devono poter accedere possono risultare a rischio. Per esempio i dati presenti nella pagina web del sito vulnerabile, i dati prelevabili con richieste Get/Post/XmlHttp al sito di provenienza, i cookie persistenti o ancora dei dati XML usati per esempio da Ajax.

Già nel nostro primo semplice esempio lo script dell’hacker potrebbe intercettare la funzione di onsubmitdelle credenziali del sito e spedirle all’hacker. Visto che gli script hanno pieno accesso al DOM della pagina html che li contiene, l’operazione sarebbe estremamente semplice da realizzare.

Descritto il meccanismo a grandi linee, entriamo in maggiore dettaglio comunciando a suddividere gli attacchi di cross site scripting in due macrocategorie: persistenti e volatili.

Cross site scripting persistente

Gli attacchi persistenti consistono nell’iniettare lo script nel web server in modo che venga salvato e riproposto agli utenti che lo visitano. A prima vista questo tipo di attacco potrebbe sembrare difficile da attuare, ma prendiamo in esame due esempi molto popolari: i forum e i blog.

Nel primo caso l’hacker posta uno script nel messaggio di un forum. I post più recenti tipicamente vengono mostrati a tutti gli utenti che si collegano alla pagina principale del sito e lo script viene immediatamente eseguito dai browser.
Nel secondo caso l’hacker posta uno script in un blog aperto per l’occasione. Gli ultimi post di un blog sono generalmente pubblicati sul cosiddetto “muro” che aggrega i post di tutti gli utenti di quel sito. Forse a qualcuno è già capitato di vedere l’effetto di un Html mal formattato in un post di un blog: nella pagina che aggrega tutti i post la mancata chiusura di un il resto della pagina. In modo similare il sito che ospita il blog che sia vulnerabile al cross site scripting, spedirà lo script dell’hacker a tutti i visitatori di quella pagina.

L’entità del danno provocato da questa vulnerabilità può variare dalla più totale innocuità a un feroce attacco. L’hacker potrebbe firmare dei messaggi a nome dell’utente oppure leggere i suoi dati sensibili. O ancora lo script potrebbe consegnare nelle mani dell’hacker la password dell’utente per quel forum/blog. Quanto queste credenziali possano essere importanti dipende dall’accortezza dell’utente a non usarle, ad esempio, per l’accesso al proprio conto bancario. In sostanza anche i siti che si reputano a zero rischio per la bassa importanza del contenuto del proprio sito, possono creare una grave minaccia. Questo è un chiaro esempio di quanto la sicurezza sia una miscela costruita su più elementi e con tutti gli attori del sistema informatico.

Cross site scripting volatile

Molti siti interessanti dal punto di vista dell’hacker non hanno una struttura come forum o blog, e non è quindi possibile per l’hacker persistere lo script usato per rubare informazioni all’utente, perciò l’attacco può avvenire solo durante una sessione attiva tra utente e sito vulnerabile.

La soluzione è più semplice di quanto non si possa pensare: sarà l’utente stesso ad iniettare lo script dell’hacker nel sito vulnerabile, il quale restituirà all’utente lo script immediatamente eseguito nel suo browser con la stessa capacità dirompente già vista in precedenza.

Uno degli attacchi di cross site scripting più diffusi inizia con un attacco di social engineering che ha come mezzo una apparentemente innocua email che promette una vincita milionaria sicura. In mezzo alle milioni di email di spam che girano su internet, molte sono un attacco di cross site scripting.

Credo che nessuno possa negare che tragicamente non sarebbero pochi gli utenti a cliccare sul link per cercare di riscuotere la presunta vincita milionaria.

Al click dell’utente si apre, ad esempio, il sito della banca che l’hacker ha prescelto in quanto vulnerabile al cross site scripting e di cui presume che l’utente ne sia un cliente. Il risultato è l’apertura del browser che non desta alcun sospetto all’utente che brama la vincita fortunata.

A questo punto il browser esegue una GET o POST della pagina vulnerabile del sito della banca trasmettendo lo script avvelenatore.

Come risultato il browser riceve la pagina inquinata dallo script che viene eseguito immediatamente. Lo script, essendo stato scaricato dal dominio del sito della banca, ha accesso al cookie che incautamente custodisce le credenziali per accedere alle operazioni sul conto corrente, e che viene prontamente trasmesso all’hacker. Infine viene subito caricata un’altra pagina per non insospettire l’utente.

Di tutta questa operazione l’utente non fa in tempo a vedere il caricamento della pagina della banca in quanto avviene in tempi rapidissimi. Il furto delle credenziali è avvenuto e l’utente con tutta probabilità non si è accorto di nulla.

Mini Laboratorio

Allo scopo di fare un semplice test dimostrativo, costruiamo due semplici siti web con Asp.net 2.0: il sito vulnerabile e quello dell’hacker.

Il sito vulnerabile consta di una sola pagina, Default.aspx nella quale dovremo disabilitare esplicitamente ValidateRequest di cui parleremo più avanti:

<%@ Page ValidateRequest="false" …. %>

Inoltre saranno necessari due soli controlli: un bottone di nome “btSetCookie” per creare il cookie persistente da rubare ed una label per consentire l’injection di uno script.

Il gestore dell’evento di click del bottone imposterà ad esempio le ipotetiche credenziali dell’utente, e sarà necessario cliccarlo solo una prima volta per creare il cookie persistente su disco:

protected void btSetCookie_Click(object sender, EventArgs e)

{

HttpCookie ckUser = new HttpCookie("Utente", "Raffaele");

");
ckUser.Expires = DateTime.Now.AddDays(1);
ckPassword.Expire

HttpCookie ckPassword = new HttpCookie("Password", "passwor

ds = DateTime.Now.AddDays(1);

Response.AppendCookie(ckUser);

Response.AppendCookie(ckPassword);



}

Nella Page_Load Load invece daremo il benvenuto all’utente prendendo una stringa dalla QueryString

protected void Page_Load(object sender, EventArgs e)

{

string Name = string.Empty;

!= null)
Name = "Buongiorno " + Reques

if(Request.QueryString["Name"

]t.QueryString["Name"];

lblInjection.Text = Name;



}

Il caso della QueryString è il più semplice da iniettare ma un attacco analogo può essere effettuato usando ad esempio una HTTP-POST.

Aprendo il sito vulnerabile con l’indirizzo: http://sitovulnerabile/Default.aspx?Name=Raffaele vedremo il messaggio “Benvenuto Raffaele”.

Veniamo ora al sito dell’hacker il cui compito è solo quello di raccogliere le credenziali rubate degli utenti che cadono nella trappola.

Qui è presente una sola pagina vuota, default.aspx che raccoglie e salva su disco le QueryString che gli vengono passate.

protected void Page_Load(object sender, EventArgs e)

{

string s = Request.QueryString["Cookie"] + "\r\n";

e.AppendAllText(FileName, s);
Response.Redirect("

string FileName = Server.MapPath("~/Hacked.log");

Fi

lhttp://blogs.ugidotnet.org/raffaele");



}

A questo punto è tutto pronto e non resta che spedire un milione di email con la promessa della vincita milionaria, sperando che qualcuno, la cui banca soffra di vulnerabilità al cross site scripting, abbocchi.

Il messaggio di posta elettronica in formato html, sarà composto in questo modo e inietterà per mano dell’utente lo script fatale nel sito web.

Hai vinto un milione di euro



Clicca 

qui per riscuotere

Al posto del nome utente viene iniettato lo script che redirige il browser dell’utente sul sito dell’hacker passando per intero il cookie del dominio contestuale alla pagina aperta, la banca vulnerabile nel nostro semplicistico esempio.

Come proteggere l’applicazione web

Per portare a compimento un attacco di cross site scripting abbiamo visto che l’hacker deve trovare il modo di far eseguire uno script nel browser utente nel contesto di un sito che abbia delle informazioni preziose da rubare.

In sostanza lo script viene fatto transitare verso l’applicazione web per poi essere erogato all’interno di una nuova pagina ed eseguito dal browser. Nel caso di cross site scripting volatile il browser che eroga lo script è lo stesso che riceve la pagina avvelenata, mentre nel caso del persistente questo non è necessariamente vero.

Negli attacchi di cross site scripting non ha importanza se il canale di trasmissione sia protetto da SSL o se l’utente sia autenticato. Lo schema a blocchi mostra che il sito vulnerabile ha mancato due capisaldi fondamentali nella scrittura di codice sicuro: la validazione dell’input e la codifica dell’output.

La validazione dell’input e la codifica dell’output

La validazione è un controllo di congruità che è tanto più efficace quanto è meno generico. Se ad esempio ci aspettiamo un indirizzo email, la validazione con una regular expression è sicuramente il sistema più efficiente. Se invece è il messaggio di un post in un forum il controllo sarà evidentemente più complesso perché il corpo del messaggio potrebbe contenere emoticon o una formattazione html che potrebbero nascondere delle pericolose insidie.

Il primo passo è quello di identificare nella applicazione tutti i punti di ingresso dei dati che provengono dall’utente, siano essi i dati di una form, della QueryString, di un database condiviso con un’altra applicazione o da una pagina che usa Ajax.

Questi dati in ingresso sono pericolosi non solo per il cross site scripting ma per una più generica script injection o ancora per SQL injection. In parole povere tutto l’input su cui non possiamo mettere la mano sul fuoco deve essere validato in modo rigoroso.

Il tipo di validazione da effettuarsi cambia ovviamente dall’uso che facciamo di questi dati. Se sono destinati a essere rimandati alla pagina web perché l’utente li possa confermare, andranno validati in modo da evitare che contengano tag e script.

Se sono destinati al database potremo demandare la validazione ad esempio alla classe Sql Parameter e non curarci della presenza di tag e script sempre che non vengano rimandati a una pagina web successivamente.

Il processo di validazione non può limitarsi alla mera sostituzione o codifica dei simboli di minore e maggiore.

Come abbiamo visto all’inizio gli script possono anche essere all’interno degli attributi o degli eventi di un tag html, rendendo vana questa contromisura.

Un altro potente veicolo di script è “expression” che consente di iniettare codice con stessa capacità distruttiva già vista in precedenza:

Non farò un elenco dei tag che possiamo considerare sicuri o a rischio. L’elenco rischierebbe di essere poco esaustivo e dovrebbe tenere conto di come vengono processati in ciascun browser. Non ritengo questa strategia sufficientemente sicura anche se in rari casi può essere l’unica soluzione.

I danni

Se non bloccati, questi attacchi possono arrivare a essere estremamente pericolosi. Oggi per motivi di comodità e standardizzazione il contenuto Html e gli script sono spesso presenti anche nei rich client scollegati da Internet.

Naturalmente il problema della validazione vale anche per questi perché potrebbero fungere da mezzi per veicolare un pericoloso script.

La tipologia di danni è molto variabile e può andare dal furto di credenziali all’attacco di altri siti vulnerabili, sistema tipicamente usato dagli hacker per far perdere le loro tracce. Il sistema più diffuso rimane sempre il furto del cookie che è il punto più debole di un’applicazione web vulnerabile.

Se il rimedio migliore è ovviamente quello di applicare le tecniche di validazione dell’input e di codifica dell’output, esiste un modo per mitigare il problema del furto dei cookie ed è un nuovo attributo specifico di Internet Explorer chiamato HttpOnly che è disponibile a partire dalla IE6 Service Pack 1.

I ladri di cookie e i browser

Lo scopo di HttpOnly è di informare il browser che il cookie non deve essere accessibile dagli script ma è disponibile solo per essere inviato al web server.

La sintassi aggiornata per Set-Cookie è la seguente e l’attributo HttpOnly è case-insensitive, cioè non ha importanza se le lettere siano maiuscole o minuscole:

Set-Cookie: =[; =]...

[; expires=][; domain=]

[; path=][; secure][;HttpOnly]

Grazie a questo attributo le tipologie di attacchi di cross site scripting che si basano sul furto delle informazioni presenti dentro un cookie, sono scongiurate. In pratica uno script che, eseguito ad esempio in Internet Explorer 7, dovesse tentare di leggere document.cookie, otterrebbe una stringa vuota.

Questo non significa però che HttpOnly sconfigga la totalità degli attacchi cross site scripting. Infatti lo script potrebbe cambiare la password di un utente registrata nel cookie con una nota solo all’hacker senza neppure farsi mandare il contenuto del cookie.

Bisogna sempre ricordare che è una soluzione lato client il cui più evidente vantaggio, al contrario delle soluzioni lato server, è che l’utente ha in mano la possibilità di ridurre i propri rischi, installando la versione più aggiornata del browser. In altri termini, chi naviga con browser che ignorano HttpOnly (per esempio IE6 senza SP1) è a maggiore rischio nel caso di attacchi cross site scripting.

Http Only ribadisce il concetto, se ce ne fosse ancora bisogno, che l’installazione delle patch e l’aggiornamento delle nuove versioni di applicazioni (specie se sono i browser) e dei sistemi operativi è quanto mai fondamentale.

Cosa comporta l’implementazione di questo attributo per lo sviluppatore? È evidente e auspicabile che una buona protezione nasca dall’adozione di tutte quelle buone pratiche di validazione e codifica dell’output citate in precedenza ma l’implementazione di questo attributo rimane una soluzione molto importante perché la sua messa in opera è molto rapida, ha un impatto estremamente basso sulla revisione del codice e quindi della sua messa in produzione, tutti dati fondamentali per siti di dimensioni medio/grandi.

Per gli sviluppatori Asp classic la soluzione consiste nell’aggiunta di HttpOnly al cookie usando il solito Response.AddHeader. Gli sviluppatori Asp.net possono usare lo stesso sistema o più elegantemente impostare a true la proprietà HttpOnly della classe HttpCookie.

Ancora più rapida è la soluzione del tag http Cookies del web.config che abilita l’attributo HttpOnly per tutti i cookies usati nell’applicazione. Come si può vedere dall’esempio, l’adozione di questa strategia è realmente poco invasiva per lo sviluppatore.

HttpCookie CookieNome = new HttpCookie("Nome", "Raffaele");
CookieNome.HttpOnly = true;

ome);

Response.Cookies.Add(Cookie
N

oppure

In teoria la migliore implementazione dovrebbe tenere conto della versione del browser installata ed evitare ad esempio la registrazione di informazioni sensibili per chi non supporta HttpOnly. Questa strategia purtroppo non è rapida alla luce del fatto che lo User Agent non è sufficiente per sapere se Internet Explorer 6 abbia o meno la service pack 1 installata.

Dal fronte degli altri browser c’è da registrare che purtroppo sono ancora tanti a non aver ancora voluto implementare il supporto per questo attributo; nel caso di Firefox 2.0 l’implementazione è tuttora in discussione dall’anno 2002 ed alla data di questo articolo non è ancora giunta al termine (maggiori dettagli a questo link: https://bugzilla.mozilla.org/show_bug.cgi?id=178993). 

Al posto di HttpOnly, FireFox 2.0 ha deciso una implementazione differente, basata su nuovi metodi non standard javascript, e non compatibile con HttpOnly il cui approfondimento (http://blog.mattmecham.com/archives/2006/09/http_only_cookies_in_firefox.html) va al di là dello scopo di questo articolo.

Gli strumenti offerti da Asp.net

Fin dalla versione 1.1 Asp.net offre un controllo sull’input utente grazie a validateRequest che scongiura gli attacchi più comuni come il post di tag Html, la presenza di script nei cookie, nei form o nelle QueryString.

Di default validateRequest è abilitato e la sua disabilitazione ha senso solo se si vuole dare all’utente la possibilità di postare Html/script e si effettua una scrupolosa validazione su questo input.

<%@ Page validateRequest="true"  %> (true è il default)

Per evitare di disabilitare la validazione solo per uno dei controlli, si potrebbe ricorrere ad un piccolo espediente:

• Durante la onSubmit criptare il contenuto del controllo di cui non si vuole la validazione grazie alla funzione ‘encode’ di javascript
  
• Mettere il risultato criptato dentro un controllo all’interno del form
  
• Usare HttpUtility.Decode per decodificare i dati criptati sul lato server
  
• Validare accuratamente i dati ricevuti
  

Possiamo dire che Asp.net ha risolto il problema della validazione? La risposta è no, in quanto a seconda del contesto è molto facile nascondere codice javascript nei tag della pagina. L’attributo validateRequest rimane solo uno degli strati di difesa che sono necessari nelle applicazioni web.

Un altro valido strumento di difesa che deve essere sempre usato congiuntamente e non in modo alternativo è la codifica di ciò che presentiamo sulla pagina.

Il loro uso è molto semplice e si presta per esempio per evitare che il browser legga il tag

È importante notare che HtmlEncode codifica le doppie virgolette ma non le singole. Perciò è buona abitudine usare le doppie virgolette negli attributi e negli eventi delle pagine in quanto questa semplice precauzione renderebbe inutili le parti di script con singole e doppie virgolette.

Abbiamo già visto che non sono solo i simboli di maggiore e minore a dover essere temuti. L’iniezione di script all’interno della pagina può essere molto più subdola. Per sfruttare al meglio il prezioso filtro della codifica dell’output abbiamo in Asp.net 2.0 un nuovo e potente alleato: la libreria anti cross site scripting.

La libreria anti cross site scripting

In Microsoft esiste un team che si occupa specificamente di problemi relativi alla sicurezza, le performance e la privacy il cui nome è “ACE Team” (http://blogs.msdn.com/ace_team).

Questo gruppo ha creato una libreria chiamata “Anti-Cross Site Scripting Library” arrivata alla versione 1.5 e scaricabile a questo link: http://www.microsoft.com/downloads/details.aspx?FamilyId=EFB9C819-53FF-4F82-BFAF-E11625130C25&displaylang=en

Lo scopo di questa libreria è dare allo sviluppatore dei collaudati e robusti metodi di codifica di tutto ciò che proviene da una sorgente non completamente fidata, tipicamente i dati letti da una form utente o di un database condiviso con altre applicazioni.

Nella attuale versione 1.5 della libreria sono esposti sette metodi statici che prendono una stringa e restituiscono la stringa codificata:

public static string HtmlEncode(string s);

public static string HtmlAttributeEncode(string s);
public static string JavaScriptEncode(string s);

static string VisualBasicScriptEncode(str
public static string UrlEncode(string s);
public
 ing s);
public static string XmlEncode(string s);


public static string XmlAttributeEncode(string s);

Ciascuno di questi metodi è specifico per la destinazione della stringa. Se ad esempio dobbiamo creare un url, il metodo da usare sarà UrlEncode; se invece dovessimo aggiungere un attributo ad un tag Html, dovremmo invece usare HtmlAttributeEncode.

La libreria si basa sul principio di inclusione, vale a dire che a seconda della destinazione della stringa viene definito un set di caratteri ammessi e tutti gli altri vengono codificati. Attributi Html e Url non condividono lo stesso set di caratteri da lasciare inalterati e quindi ecco spiegati i diversi metodi esposti dalla libreria. Una trattazione più ampia sul suo uso si trova a questo link: http://msdn2.microsoft.com/library/aa973813.aspx.

In qualità di Security MVP ho avuto il privilegio di testare lo scorso Novembre in anteprima la libreria e rilevare all’ACE team l’assenza nella libreria di un metodo che permetta di filtrare una iniezione di javascript usando “expression”.

Prendiamo in esame il caso in cui l’utente possa scrivere il colore per personalizzare lo sfondo di un div.

La personalizzazione del colore avverrebbe con:

style="background-color:" + ColoreUtente;

Se al posto del nome del colore l’input dovesse essere "expression(alert('Ciao'));", verrebbe eseguito lo script nella pagina.

Al momento la libreria è sprovvista di metodi che permettano di filtrare questo tipo di injection su cui è importante che ciascun sviluppatore rifletta e prenda le contromisure più opportune come ad esempio una regular expression per filtrare la parola ‘expression’ seguita dalla parentesi tonda ignorando eventuali spazi.


L’ACE team mi ha assicurato che c’è forte determinazione a evolvere la libreria in modo da coprire anche scenari di questo tipo nelle future versioni.

È realistico pensare che in futuro i server control di Asp.net useranno nativamente i metodi di questa libreria diminuendo la superficie di attacco.

Conclusione

Abbiamo preso in esame una piccola rosa di attacchi basati sull’esecuzione di script che possono rendere molto spiacevole la navigazione dell’utente.

La sicurezza dell’utente dipende da tutti gli attori del sistema informatico. L’utente può parzialmente difendersi mantenendo aggiornato il browser e il sistema operativo; lo sviluppatore può rendere più sicura la sua applicazione seguendo le buone norme di validazione e codifica dell’output; l’amministratore di sistema può verificare la corretta configurazione dell’applicazione (ad esempio escludendo il verb TRACE dal web server) e analizzare scrupolosamente i log.

Guida a PHP 5

Lo scopo di questa guida è quello di portare le conoscenze di un neofita del PHP, a livello professionale.

Anche chi non ha mai programmato in PHP puo' tranquillamente avvicinarsi a questo fantastico linguaggio, per la prima volta, con questa guida che illustrerà passo passo e in modo dettagliato tutte le caratteristiche di PHP 5.

Dalla struttura del linguaggio, alle nozioni necessarie per creare delle vere e proprie applicazioni web.

PHP è un linguaggio Server-Side che vi permetterà di creare delle pagine dinamiche, scrivendo il vostro codice anche in mezzo alla stessa pagina HTML.

Server-Side significa che il vostro codice risiederà solo sul server, e che non sarà pertanto possibile accedere ai sorgenti dal lato client, come invece accade con linguaggi Client-Side come JavaScript.

In pratica, quando un utente apre una vostra pagina PHP, il Web Server viene interrogato e restituisce al client niente altro che una semplice pagina HTML o XHTML ecc...

La pagina HTML che il client visualizzerà, sarà prodotta da PHP grazie alle vostre direttive.

Prima di iniziare a programmare, è necessario che vi procuriate il software necessario.

Per testare le vostre applicazioni, AppServ andrà più che bene.

E' un pacchetto autoinstallante per piattaforma Windows, che installerà e configurerò automaticamente tutti i pacchetti di cui avrete bisogno, nel vostro PC.

I software per il programmatore Php

Un confronto tra i moderni linguaggi di programmazione per la scelta del sistema da utilizzare, non può oggi prescindere dal prendere in considerazione anche gli aspetti non direttamente connessi alla "bontà" del codice; una parte molto importante è svolta infatti dai software che aiutano il programmatore ad elaborare codice sorgente con quattro principali caratteristiche:

• velocità di scrittura
• facilità di manutenzione
• portabilità elevata
• velocità di esecuzione

Linguaggi di programmazione come visual basic e delphi hanno fatto dei lorotool rad (Rapid Application Development - Programmi per lo sviluppo rapido di applicazioni) il proprio punto di forza. Anche se il php non dispone direttamente di questi sistemi (e nella maggior parte dei casi non se ne sente molto la mancanza), è possibile rendere il lavoro svolto dal programmatore se non più leggero in quantità, almeno più leggero in qualità attraverso l'utilizzo di editors, strumenti per l'accesso rapido ai database, librerie di codice, cachers ed altro ancora.

Editor

Qualunque sia il sistema operativo che voi utilizziate esisterà sicuramente un editor in grado di permettervi di scrivere codice php: basta un semplice editor di testi come possono essere i vari notepad su windows e i gedit o altri su linux. Essenzialmente gli editor per questo linguaggio di programmazione infatti altro non sono se non editor di testi arricchiti con funzionalità specifiche per la programmazione che possono andare dalle più semplici come il diverso colore associato alle diverse parti del codice (ad esempio un colore per le parole chiave, uno per i commenti, uno per le stringhe, etc.) o la numerazione delle righe, fino a funzioni più complesse come l'autocompletamento del codice, l'integrazione delle "references" del linguaggio, la creazione di file di "progetto" o altro ancora.

Sul forum di html.it, alla sezione php, è stato aperto un thread sui linguaggi di programmazione in cui sono elencati alcuni dei software per scrivere codice in questo linguaggio.

Context

Il mio editor gratuito preferito è senza dubbio Context: parte veloce, non ha fronzoli inutili, legge facilmente file molto grossi (provato con un dump da database da 60 mb), ha l'highlight per molti linguaggi di programmazione e supporta la lingua italiana. Quando lavoro su sistemi Windows lo installo per modificare ogni genere di file testuali e quando programmo su linux ne sento la mancanza.

Non presenta la completezza di alcuni suoi concorrenti per quanto riguarda le funzionalità per il php ma d'altra parte non è stato progettato per essere un edito php bensì un editor per programmazione.

Sito web - Screenshots

Bluefish

Bluefish si presenta come uno dei migliori editor per la programmazione in ambiente linux per Gnome. Personalmente l'ho trovato molto leggero e veloce anche se presentava un bug per cui il programma terminava al passaggio del mouse su un particolare menu, bug tra l'altro che è stato sicuramente risolto. E' stato pensato come editor html ma svolge egregiamente anche il ruolo di editor php. Da considerare il fatto che il progetto sia open source e con una discreta comunità di programmatori alle spalle.

Sito web - Screenshots

Quanta plus

La prima caratteristica di questo programma che salta subito agli occhi è senza dubbio l'interfaccia grafica che sembra essere molto ben curata. A parte l'aspetto puramente estetico, Quanta plus, editor per ambiente Linux con KDE presenta un gran numero di funzionalità aggiuntive tra cui un comodo alberoper avere sempre sotto mano le varie componenti di uno script (variabili, funzioni, file inclusi, classi usate) e un assortito insieme di funzioni per scrivere codice html.

Sito web - Screenshots

Dreamweaver

A differenza dei programmi menzionati precedentemente, Dreamweaver è uno degli editor a pagamento più conosciuti in ambito web. La sua caratteristica principale, cioè l'essere un editor WYSIWYG (What you see is what you get - Quello che vedi è quello che ottieni) non è molto utile allo sviluppo del codice php sotto forma di classi o codice funzionale, ma d'altra parte uno degli ambienti in cui è più utilizzato il php è nella realizzazione di piccole parti dinamiche all'interno di pagine web. Se utilizzate la versione MX di Dreamweaver potrete apprezzare l'integrazione che è stata raggiunta con questo linguaggio per il quale, in versioni precedenti di questo editor, era necessario installare componenti di terze parti come descritto da questa pagina di html.it.

Sito web

Zend studio

Termino questa carrellata rapida sugli editor con il programma di casa Zend, la società a cui si deve il motore del php dalla versione 4, che integra una serie di funzionalità avanzate come un browser cvs, un albero per il codice usato dallo script, il completamento del codice, un debugger interno, un client ftp per caricare il codice scritto direttamente sul sito web di destinazione e un client sql per eseguire query sul database e verificare la correttezza del codice sql scritto (vedremo in seguito dei software in grado di fare questo). Purtroppo qui la qualità si paga eccome: la licenza annuale per lo Zend Studio Enterprise arriva a costare 1495 dollari!

Sito web - Screenshots

iAp Cracker

iAp Cracker è un geniale tweak che ci consente di rendere tutti gli in-app purchase completamente gratuiti.

Quest’applicazione funziona con ogni tipo di iDevice ed è effettuabile solamente su dispositivi aventi il Jailbreak. Grazie ad essa riusciremo ad ottenere vari contenuti che in realtà avremmo dovuto pagare, rendendo quindi molto più semplice il gioco.

Andiamo a vedere come funziona iAp Cracker, il crack per l’in-app purchase!

A volte, dopo aver scaricato gratuitamente o anche pagato un’applicazione, troveremo all’interno di essa uno store o un mercato dove è possibile acquistare contenuti specifici per il gioco, come monete extra per sbloccare armi avanzate o nuovi livelli. Questi contenuti andrebbero pagati, ma grazie ad iAp Cracker riusciamo a comprare tutto ciò senza spendere un soldo. 

Per installare iAp Cracker abbiamo bisogno di:

• Un qualsiasi dispositivo iDevice jailbrekkato
• Le repo di Xsellize oppure Bite Your Apple installate

Apriamo Cydia e dirigiamoci nella schermata Cerca, digitiamo quindi iAp Cracker per trovare i risultati e installarlo. Al riavvio della springboard l’applicazione sarà già dentro al nostro dispositivo e quindi utilizzabile.

Testiamo immediatamente iAp Cracker su un qualsiasi gioco, quindi apriamolo e dirigiamoci nel suo store interno per comprare un qualsiasi contenuto. Premete il pulsante Buy senza paura e noterete che l’oggetto o le monete che volevate sono state immediatamente acquistate.

Se per caso, durante un acquisto, si aprisse la schermata di accesso all’App Store, significa che iAp Cracker non è ancora compatibile con quell’applicazione: questo è l’unico caso in cui non dovrete continuare l’acquisto, o spenderete. Ciò che dovrete fare sarà aspettare un aggiornamento di iAp Cracker, che certamente implementerà anche l’app che non riuscivate a craccare. 

iAd Network

iAd reaches millions of iPhone, iPad and iPod touch users around the world in their favorite apps. With the iAd Network, you can reach the Apple audience, the world’s most engaged, influential and loyal consumers. This audience:

Has installed more than 15 billion applications

Has purchased over 315 million iOS devices

Spends, on average, 73 minutes per day using apps

Engages with iAd ads for an average of 60 seconds per visit

Each ad is shown only to the audience you want to reach, in the apps they love and use the most. 

Our highly-effective targeting can leverage demographic data, as well as unique interest and preference data that taps into user passions that are relevant for your brand. 

Whether they are reading the news, playing a game or checking the local weather, your ad will make an impact.

L'aspirante Blogger

The Brain of the Beginning Blogger è un’interessante infografica in inglese a cura di Problogger che potrebbe essere tradotta il cervello dell’aspirante Blogger: ovvero come ragiona un blogger in erba.

In modo molto semplice si evidenziano i problemi realativi al posizionamento, al SEO, alla grafica, alle tematiche da trattare, alla monetizzazione.