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 security.

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 field.

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.

Codesake.com and an apparent abuse of procrastination

If you look at the codesake.com 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 stage.

I created a set of codesake.com 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 )