Nella recente intervista Stefan Esser, ha annunciato che a Marzo inizierà il “Month of PHP bugs”.
Stefan Esser è un consulente di sicurezza tedesco che da anni ha a che fare con software OpenSource.
Circa 6 anni fa è entrato a far parte degli sviluppatori di PHP, grazie a questa mansione è stato a stretto contatto con i sorgenti di PHP capendo così che essi non erano scritti con la sicurezza come obiettivo. Ha così deciso di creare il security team all’interno di PHP per poter gestire in maniera ottimale il report di bug e il rilascio di patch.
Qualcosa nel frattempo è andato storto tanto da farlo ritirare dal gruppo di sviluppatori PHP.
Dal 2004, Stefan, ha iniziato un progetto personale chiamato “Hardened PHP” il quale fornisce patch per aumentare la sicurezza del codice ufficiale. “Hardened PHP” è stato recentemente rimpiazzato da Suhosin, progetto nato dall’idea di dividere “Hardened PHP” in due parti distinte. La protezione dello Zend Engine, per difendere il “core” da buffer overflow, implementata come patch ai sorgenti originali e un’estensione che integra tutti gli altri tipi di protezione.
Suhosin risulta trasparente sia all’utente sia allo sviluppatore: implementa il controllo sui parametri passati alla funzione mail() per evitare injection di header, effettua la crittografia dei dati delle sessioni e dei cookie, blocca le url nei parametri delle funzioni include e require, ecc…
Stefan Esser mentre parla del futuro “Month of PHP bugs”:
Its goal is to make people and especially the PHP developers aware that bugs in PHP exist. While this sounds obvious for everyone on the outside, it is actually required. PHP has a very bad reputation when it comes to security, which is mostly caused by all the advisories about security holes in PHP applications.
Lo scorso 10 Gennaio è stata rilasciata la OWASP Testing Guide versione 2 RC1.
La guida (rilasciata anche in pdf e doc) si prefigge lo scopo di diventare un framework per il test della sicurezza di applicazioni e infrastrutture di rete.
Una lettura d’obbligo per application/penetration tester e sviluppatori.
This document is designed to help organizations understand what comprises a testing program, and to help them identify the steps that they need to undertake to build and operate that testing program on their web applications. It is intended to give a broad view of the elements required to make a comprehensive web application security program. This guide can be used as a reference and as a methodology to help determine the gap between your existing practices and industry best practices. This guide allows organizations to compare themselves against industry peers, understand the magnitude of resources required to test and remediate their software, or prepare for an audit. This document does not go into the technical details of how to test an application, as the intent is to provide a typical security organizational framework.
Non è facile in poche righe descrivere la qualità elevata di questo documento. Tengo solo a sottolineare il fatto che persone come Matteo Meucci, Mauro Bregolin, Luca Carettoni, Stefano Di Paola, Giorgio Fedon, Andrea Lombardini, Claudio Merloni, Antonio Parata, Carlo Pelliccioni e Alberto Revelli hanno reso possibile spostare il baricentro di un progetto internazionale dagli Stati Uniti all’Italia.
Grazie ragazzi!
Matteo Meucci, coordinatore del capitolo Italiano OWASP, sta curando la OWASP Testing Guide dal 2005.
Paypal per combattere i numerosi attacchi di phishing fatti ai propri utenti ha pensato di dotare loro di un porta chiave che genera one-time password ogni 30 secondi.
In questo modo, anche se un malintenzionato riuscisse a venire in possesso di username e password di un account PayPal senza il security token (meglio key in questo caso) non sarebbe in grado di effettuare il login.
PayPal aferma, tramite un porta voce, che questo dispositivo non servirà ad eliminare le frodi ma solo aumentare il livello di sicurezza nella gestione del proprio account.
Il Security Key è stato sperimentato tra gli impiegati di PayPal per alcuni mesi. La sua sperimentazione tra gli utenti dovrebbe partire dal mese prossimo in U.S, Germania e Australia. Tramite una apposita pagina sarà possibile richiedere l’invio del porta chiave; per account personali avrà un costo di 5$, mentre per account business sarà gratuito.
Il dispositivo sarà basato su tecnologia VeriSign, società con la quale eBay ha stretto una partnership dal 2005.
Captcha, acronimo di “completely automated public Turing test to tell computers and humans apart“, indica, nel campo della sicurezza informatica, una immagine contenente testo utile a capire se l’utente con il quale si sta interagendo è un bot oppure un essere umano.
In questa tecnica si pone un problema non da poco: l’accessibilità. Captcha troppo robusti, ovvero “sporchi”, compromettono l’interpretazione corretta anche all’occhio umano. Senza pensare poi alle persone daltoniche o ipovedenti che anche su immagini semplici si trovano in difficoltà.
Ultimamente molti dei captcha creati si sono resi inutili in quando software studiati appositamente riescono, a volte con probabilità del 100%, ad interpretare numeri e lettere nascoste su sfondi “sporchi”.
I captcha sono nati principalmente per combattere registrazione automatiche su forum e social network. Ma specialmente i primi sono spesso riempiti di spam con software appositamente scritto, da sviluppatori senza scrupoli, per riconoscere in automatico i caratteri presenti nell’immagine.
Ecco un esempio:
C’è chi ha ben pensato di fare pubblicità con i captcha.
Sicuramente una trovata interessante dal punto di vista del marketing ma dal punto di vista della sicurezza può comportare seri problemi. Ci sono spam bot che riconoscono senza problemi captcha complessi figuriamoci quanto tempo impiegherebbero ad interpretare il testo basato su parole di un dizionario o ancor peggio su nomi di marche famose.
Seth Godin, l’ideatore di questo nuovo tipo di captcha, dopotutto non è un esperto in sicurezza ma un esperto in marketing.
