Untold: nobody will make a cinema story over this blog and I’m fine

Julie Powell is an American writer who
creates a blog back in 2002. She wrote about an American woman lived in Paris
in 1949-or-something that innovates American cooking scenario writing a book
(in English) talking about novelle cousine.

Starting from the blog, she wrote a book and eventually, this story becomes a
film my and my wife watched it in TV yesterday.

Fact: nobody will use this blog to create a film
script. But application security can be also very funny.

(yes, I’ll talk a little bit about security if you read more)

Appsec is like cooking: teach other people and use recipes

Yesterday I had an awareness session with a development team. We mostly talked
about API and how to find the right balance between funciontality versus data

We talked about REST and CRUD approach when creating an API and how to use HTTP
verbs effectively. Mastering an awareness session is the reason why an
application security specialist must be also a developer.

Teaching is fun and I like talking about my passions.

Cooking involves also using recipes, eventually a chef can customize to best
fit her personal taste. In the same way, secure coding involves the usage of
code snippets (recipes) a developer (the chef) can customize to fit the
software she’s creating.

At the end, we (application security specialists) are a sort of cooking book
writers (like the Julia living in Paris back in ’40s). Our goal is to innovate
how be effective in teaching other people how to deal with security bugs.

The great pretender(s)

Freddy Mercury sang about he was a great pretender, pretending he was doing
well (since I’m not a music history expert I don’t know the topic Freddy was
talking about here). That song is great and Freddy voice is unbelievable.

Also in application security scenario there is a lot of people pretending, me
first, of doing well. We all aspire to be excellent, to be leaders in our

Take this blog. I’m aspiring this would be the reference in the application
security field in the next three years.
Setting ambitious goals is good. It forces you in go deep researching, learning
and applying knowledge. It forces you in embrancing the change, and changing is
always good since it kicks the status-quo out.

Embracing the change means also being prepared to make mistakes. Don’t be
scared about saying “I wrote a sentence about a vulnerability but my
conclusions are completely wrong”.

The very fundamental learning I had is that when I’m going to say something I
need to verify it before and I must prove my claims.
If I say that something is broken without proving it I’m facing the risk to say
something completely wrong.

Go deep in learning, prove your sentences and go for the excellence. and an apparent abuse of procrastination

If you look at the web site, it seems the
project is gone. No improvements, no github
authentication, there’s nothing at the time.

The truth here is that I worked on the fundamentals before putting them on

I created a set of side projects that eventually
would be the application security portal internals.
And I decided all of them will go opensource, codesake users would pay for
having them integrated in the website, glued with github account and for data
mining and representation.

There is no reason to close security controls, it’s not black magic and
everyone must know what I’m going to test over their code.

Railsberry: two weeks to go

In 22 and 23 of April I’ll be in Cracow for railsberry
conference. From the agenda I realized my talk
will last 30 minutes, this has some pros (mostly for the audience): they are
not forced to listen me that much.
However I’m forced to work on my talk schedule.

I guess it will be something like:

  • introducing people to Owasp Top 10 2013 ( 5’ )
  • show how to gather information to narrow an attack: robots.txt && CMS fingerprint ( 5’ )
  • show how to spider a website and look for backup files ( 5’ )
  • show how to bruteforce an authentication mechanism ( 5’ )
  • show how to check for cross site scripting ( 5’ )
  • show how to check a Rails application for CVE-2013-1855 and for CVE-2013-1857 and some basic for code reviewing ( 5’ )
  • Q & A ( 5’ )
  • Beer ( undisclosed but I saw a lot of parties in the schedule )

*** This is a Security Bloggers Network syndicated blog from - the application security blog that gets the job done authored by Paolo Perego. Read the original post at: