.:: Securnetwork.net Blog – Massimo Rabbi ::.

A poco più di un anno dal lancio di Google Chrome, era il 2 settembre 2008, il gigante di Mountain View ha annunciato il rilascio della versione 3 contenente numerosi bug fixes, miglioramenti e nuove funzionalità.

Secondo un post pubblicato sul blog ufficiale di Google, le performance Javascript sono state migliorate del 150% rispetto alla prima beta e di ben il 25% rispetto all’ultima stable release: tutto questo grazie agli aggiornamenti al motore Javascript V8.

La release include una nuova pagina “New Tab” riprogettata per essere personalizzabile secondo le preferenze dell’utente e customizzabili nel look-and-feel mediante il supporto built-in per i temi.
La barra degli indirizzi “Omnibox” utilizza ora icone diverse per distinguere azioni come la ricerca, bookmarks e pagine precedentemente visitate.
Il nuovo Google Chrome 3.0 inoltre introduce nuove caratteristiche HTML 5, gli elementi <audio> e <video>.

Questa ultima release inoltre corregge un problema di sicurezza riguardante i contenuti dei feed RSS o Atom, onde prevenire i tentativi di injection di codice Javascript e attacchi cross-site scripting (XSS).
La versione è disponibile in 50 lingue differenti per i sistemi operativi Windows XP e Vista.

Ancora da rilasciare invece una versione stabile per Chrome su sistemi Linux e Mac OS X.
L’ultima versione rilasciata circa una settimana fa attraverso il Developer Channel è la 4.0.207.0, e corregge alcuni bug oltre a fixare un problema di XSS.

Stando alla roadmap pubblicata sul wiki di Mozilla la nuova major release del noto browser open source Firefox non vedrà la luce prima dell’ultimo trimestre del 2010.

Sembra infatti che la versione Firefox 4.0 sarà rilasciata ad ottobre o novembre del prossimo anno.

Nel frattempo compariranno le minor release 3.6 e 3.7 previste rispettivamente per la fine di quest’anno e l’inizio/metà del prossimo.

Già all’inizio di questa estate erano stati annunciati alcuni dei cambiamenti all’interfaccia di Firefox che interverranno in occasione della major release.

Leggi il resto dell’articolo »

L’esperto di sicurezza Robert “RSnake” Hansen ha rilasciato un tool in grado di mettere ko anche i web server più “grossi” usando un semplice PC connesso a Internet.
“Slowloris” non sfrutta particolari vulnerabilità, ma utilizza invece una feature del protocollo HTTP nota come “richieste HTTP parziali”.
I client infatti non sono costretti a forwardare l’intero contenuto di una GET o una POST in un solo passaggio, possono suddividerlo in un certo numero di query HTTP.

A seconda di come è configurato il web server, la prima richiesta può quindi fare in modo che vengano mantenute delle risorse per la response in attesa che venga completata l’intera request.
I web server vulnerabili a questa sorta di “freno a mano” remoto sono stranamente proprio quelli che implementano strategie per evitare gli overload, per esempio, consentendo solo un determinato numero di richieste HTTP parallele.
Stando a quanto dichiarato da Hansen fra questi Apache Server 1.x e 2.x, dhttpd, GoAhead WebServer e Squid. Non vulnerabili al problema IIS6.0, IIS7.0 e lighttpd.
I web server possono essere protetti mediante l’utilizzo di load balancers come Perlbal o web applications firewall che forwardino in maniera completa le richieste HTTP al server.
In caso di attacchi improvvisi, il problema può essere “mitigato”, semplicemente riducendo il parametro di time-out per le richieste http.

RIFERIMENTI:
* Remote handbrake for web servers by Heise Security
* Slowloris HTTP DoS, an explanation of the Slowloris concept from RSnake.

Per tutti gli appassionati di Web Application Security, segnalo questo blog che ha aperto i battenti giusto la settimana scorsa.
Si tratta del SANS Web Application Security blog: http://blog.appsecstreetfighter.com/
Gli autori sono Johannes Ullrich and Jason Lam, gestori dell’ISC (Internet Storm Center), oltre ad altri istruttori certificati SANS.

All’ultima conferenza OWASP, gli esperti di sicurezza italiani Luca Carettoni e Stefano Di Paola hanno dimostrato un nuovo modo di manipolare le web applications e ingannare i classici meccanismi di sicurezza: HTTP Parameter Pollution (HPP).
Questa forma di attacco consiste nell’inviare parametri in GET o POST in forma o ordine “anomalo”, o usando caratteri delimitatori strani.
Una richiesta del tipo:
GET /foo?par1=val1&par2=val2 HTTP/1.1
verrà processata in maniera classica, mentre questa:
GET /foo?par1=val1&par1=val2 HTTP/1.1
con due occorrenze dello stesso parametro par1 è suscettibile a varie interpretazioni, a seconda della routine di parsing dell’application/web server destinatario.

Stando a Carettoni e Di Paola, questo può causare comportamenti anomali e indesiderati, oltre a prestarsi a potenziali attacchi di sicurezza.
Gli stessi WAFs (Web Application Firewalls) e i moduli di sicurezza dei server sarebbero vulnerabili ad attacchi di tipo HPP.
Mentre il modulo Apache’s ModSecurity è infatti in grado di riconoscere un attacco SQL-injection come questo:
/index.aspx?page=select 1,2,3 from table where id=1
non è in grado di inviduare quest’altro:
/index.aspx?page=select 1&page=2,3 from table where id=1
La tecnica HPP potrebbe altresì essere usata per lanciare attacchi di tipo Cross-Site-Scripting (XSS) a danno dei vari web browsers.
Il filtro anti-XSS di Internet Explorer 8 è infatti tra i componenti vulnerabili.

Carettoni e Di Paola come “rimedio” consigliano un filtering appropriato e rigoroso dei parametri oltre all’uso dell’URL encoding. Suggerito anche l’uso di un URL rewriting che utilizzi espressioni regolari “sicure”.

RIFERIMENTI:
- New type of attack on web applications: Parameter Pollution, by Heise Security