Vai al contenuto
Home » Come usare questo blog

Come usare questo blog

E’ passato un mese e mezzo dal primo post su
heartbleed

ed arrivati ad una decina di post, l’ultimo dei quali, sulle
startup

ha riscosso parecchio successo in termini di visite e commenti1, è ora di
stendere un piano di pubblicazione che dia un senso a questo post.

Questo post non fa del repost di notizie prese dall’estero la sua forma
principale di contenuti. Di blog che riportano che la società X è stata bucata,
senza dare neanche un bit in più di valore aggiunto, è pieno il web. Quindi se
cercate qualcuno che vi racconti ad esempio che ebay è stata
bucata
e così anche spotify, bhé usate un po’

Google
e non rimarrete delusi.

Probabile che la storia di intrusione sia lo spunto per un post tecnico, come
ad esempio l’upload di una web shell su un server di ebay
sarà lo spunto per un articolo sull’hardening di
WordPress. Diciamocelo, ci saranno migliaia di
intrusioni al mondo, se stiamo qui solo ad elencarle facciamo sera senza aver
detto niente di concreto.

Ho pensato che post di meditazione, come quello sulla figura
dell’application security
specialist
,
sono interessanti e mi diverte scriverli, però serve qualcosa di più
strutturato.

Per questo motivo, troverete d’ora in avanti i post organizzati in 5 categorie distinte2:

  • Pick’n’chic: usare ruby in un penetration test applicativo
  • Sicurina: pillole per scrivere codice più sicuro
  • Doctor is in: lo sportello dell’awareness
  • L’angolo del libro
  • Spinaci: storie di hardening

Pick’n’chic: usare ruby in un penetration test applicativo

Una delle cose più divertenti nel testare il codice altrui è quello di
inventarsi nuovi modi per attaccarlo, magari scrivendo script nuovi o
modificando tool esistenti. Nei post della serie Pick’n’chic,
useremo ruby come linguaggio di scripting per scrivere i nostri tool. Perché
proprio ruby? Perché è nato per parlare il webbese, ha delle ottime API, ci
puoi scrivere al volo anche una GUI WEB con Sinatra
e poi perché mi piace.

Sicurina: pillole per scrivere codice più sicuro

Sicurina sarà la cura per lo sviluppo non sicuro. Vedremo in post
molto vari tra loro, come usare API esistenti (e.g. Owasp
ESAPI
)
o come scrivere codice custom che risolva i principali problemo di application
security. Volendo riassumere, gestire l’autenticazione, l’autorizzazione e
filtrare l’input e già siete a cavallo.

Doctor is in: lo sportello dell’awareness

Lo sviluppatore non è che non filtra l’input perché non è in grado di farlo,
non lo fa perché non ne vede il motivo. Sappiamo tutti che lo sviluppatore è
tendenzialmente pigro e cerca di essere essenziale nel codice che scrivere. Per
fare in modo che spenda tempo e righe di codice per introdurre check di
security, dovremo spiegargli nel dettaglio i rischi che la sua creatura corre
quando pubblicata su Internet.

No, non se ne può più di vedere il cross site scripting come un alert box in
javascript, altrimenti comincio a stare pesantemente dalla parte del developer.

I post nella categoria Doctor is in serviranno ad educare il mondo
sui rischi e pericoli che un’applicazione web corre. Se poi voi non fate
niente, almeno non potrete dire che non ve l’ha detto nessuno.

L’angolo del libro

Volevo trovare un modo per monetizzare questo blog senza farcire l’HTML di
adwords che, sinceramente, odio. Non mi andava inoltre di imbarcare chi legge
qui di storie, e vendervi che la mia VPS è a costo 0. Quindi mi sono iscritto
al programma di affiliazione di Amazon e, nei post della categoria de l’angolo
del libro
vedrete un link allo store amazon. Questo link contiene
il codice di questo blog quindi, se deciderete di comprare il libro sullo store
amazon seguendo questo link, amazon darà una percentuale a me. Se rimuovete il
codice e comprate il libro, amici come prima, solo che non vi voglio prendere
in giro, un po’ di pubblicità c’è.

Però mi sembrava brutto mettere un link e dirvi “cliccate e fatemi diventare
milionario”, quindi farò una recensione del libro che sponsorizzerò.

Spinaci: storie di hardening

Consigli non solo per sviluppatori, perché il codice più robusto del mondo non
vale nulla se fatto girare su una Linux non mantenuta da anni con telnet aperto
e la password di root uguale a hax0r o 31337.

Nella categoria spinaci parleremo di hardening, di configurare i nostri
servizi in maniera sicura. Focus principale sono i servizi che fanno girare
web application, quindi web server, application server, DBMS. Avranno spazio
anche i CMS più popolari, come wordpress prendendo proprio spunto dal recente
hack di ebay, e il mondo NoSQL.

Off by one

Categorie alla mano, qualche titolo di post lo potete leggere sul
README
del progetto. Qualche post ce l’ho già in mente per il prossimo futuro e
verranno portati in forma aggiornata alcuni post interessanti che avevo scritto
su armoredcode.com.

Per rendere la navigazione più fluida tra i vari post, rivedrò a breve anche la
home, quindi aspettatevi cambiamenti.

Enjoy it!

  1. speriamo anche i post più in topic arrivino agli stessi risultati. 

  2. a parte le categorie meditazione e chiacchiere da pub che mi servono così, per scaricare un po’ i toni. 

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.