Focused code reviews - a followup

I promised something more technical than book reviews, so here it goes.

Earlier I posted about how to limit the amount of code for day-to-day security reviews if the code base is huge. I took Confluence (I work for Atlassian) as an example. The application uses Webworks 2, and other frameworks. Source code is not entirely free or public, but you can get it if you have almost any kind of Confluence license. I will keep some details out of this example.

Here are some things to trigger security reviews on this codebase.

Java generalities

Monitor for these being added, but there is no urgent need to review code if any of these get removed by developers. The list in this section is Java generic (and incomplete) and can be used for other apps, the other sections are more Confluence-specific. You might not need to trigger on all of these strings. You can also try structures from the IntelliJ searches from another blog entry.

Class.forName
ZipFile
Statement
Math.random
sendRedirect
"SELECT "
java.sql.Statement
java.sql.Connection
executeQuery
Runtime.
java.lang.Runtime
getRequestURI
java.sql
BeanUtils.setProp
java.lang.reflect

...

Sanitizers

Monitor for disappearance of any sanitisers from your code. There are legitimate reasons for this - for example a sanitiser in a view disappears but the corresponding model starts escaping or filtering data.

htmlEncode

...others skipped...

Filters


Being a Webwork2 webapp, Confluence utilises a number of filters and interceptors. You can get a list of filters your application uses with something like

grep -Rh --include=*.xml "<filter-name" . |sed -e 's/<filter-name>//'|sed -e 's/<\/filter-name>//'|sed -e 's/^[ \t]*//' |sort |uniq

Review the list and decide which ones have important security function. Monitor any change mentioning interceptors (both in web.xml files and for any change of their source)

HeaderSanitisingFilter
SecurityFilter
...
SafeParametersInterceptor
PermissionCheckInterceptor
...

Annotations

Some of these are generic, some are Confluence specific. One way of getting a list of all annotations is

grep -Rh --include=*.java "^\s\+@" . |sed -e 's/^[ \t]*//'  |sort |uniq

Example of what to monitor for:

@AnonymousAllowed	adding
@GET	adding
@POST	adding
@HttpMethodRequired	any change
@ParameterSafe	removal
@Path	adding
@RequireSecurityToken	removal
...

XML config files (new endpoints)

Action mapping etc - they introduce new URL endpoints. Monitor for adding, not removal.

"<action name" 
...

Other XML

Any change mentioning your filters or interceptors in web.xml, for example

<filter-name>header-sanitiser
<filter-name>request-param-cleaner
<filter-name>login

<interceptor-ref name="params"/>
<interceptor-ref name="permissions"/>
<interceptor-ref name="xsrfToken"/>

<interceptor-stack name 

...

Files and path

Look for any change in files used to implement crucial security features - login, session management, authorisation, sanitizers, CSRF protection and so on. 

confluence-core/confluence-webapp/src/main/webapp/WEB-INF/web.xml
confluence-core/confluence/src/etc/standalone/tomcat/web.xml
confluence-core/confluence/src/java/com/atlassian/confluence/security/login/*
confluence-core/confluence/src/java/com/atlassian/confluence/rpc/auth/*
confluence-core/confluence/src/java/com/atlassian/confluence/security/*
...

Monitoring for any web.xml changes is probably an overkill, you will catch interesting stuff with the items from other sections above).

Everyone says do what you love, but what is it?

Hmm, this may be turning into a book blog... Stay tuned, I'll be posting less fluffy stuff as well.

It is a familiar phrase - "do what you love", and it has been repeated over and over again at several hacker/security cons all over the world. I do not know about you, but it took me some time to sit down and figure out what I love. Being a book nerd, I picked up Business Model You for some inspiration. It is a strange book, somewhat an offshoot of a very successful (apparently) book Business Model Generation and applies the same framework to individuals instead of businesses.

What I really liked about this book is not the "business model". Instead, have a look at Chapter 4 "Who are you?" It has a lot of great advice on figuring out what it is that you really love, if you do not know it yet (many people do not).

A thought experiment. Think back to any time before you were 20 years old:
What did you love to do? (I do not think the authors include sex under this rubric, hehe)
What activities - games, hobbies, sports, extracurricular events, school subjects did you enjoy? Recall your natural, uncoerced proclivities.
Think about what kept you absorbed for hours and made you happily oblivious to the rest of the world. What tasks made time fly?

They include a bunch of other thinking prompts - e.g. thinking over what events in your life related to what feelings, what kind of environment you like to be in and so on, yet this "inner teenager" exercise is the most unusual and most powerful. Obviously these memories need to be re-interpreted in the world you are living in, abstracted, re-applied - the core idea still stays.

So, people who love what they do are following their inner teenager..

P.S. If you are wondering, I love solving complex puzzle-like problems (preferably computer-related), working alone or in a small group of peers who share  goals and learn from each other. The rest is, erm, syntactic sugar.

Changing things when change is hard

NB: If the post below makes you think that I have succumbed to managementese and became some kind of consultant, this is a false impression. I am simply reflecting on an unexpected connection between security improvements in code produced by Twitter developers and a management book.

"Switch"

A recent read of mine, recommended by one of the Atlassian owners - Switch: How to Change Things When Change Is Hard. I am not a huge fan of management books - many of them turn out self help books in disguise, others spend 200 pages chewing through an idea that can be explained in a paragraph. "Switch" initially looked like it belonged to the latter category, but to be honest it is worth reading from cover to cover.

The book is about exactly what its title says - changing things when change is hard (Hello there, "security evangelists"!). The premise is simple (and borrowed from another book):

"Jonathan Haidt in "The happiness hypothesis" says that our emotional side is an Elephant and our rational side is its Rider. Perched atop the Elephant, the Rider holds the reigns and seems to be the leader. But the rider's control is precarious because the Rider is so small relative to the Elephant. Anytime the six-ton Elephant and the Rider disagree about which direction to go, the Rider is going to lose. He's completely over-matched."

They draw lessons about change efforts:

Elephant looks for quick payoff over the long term payoff. When change efforts fail, it is usually the Elephant's fault, since the kinds of change we want typically involve short term sacrifices for long term payoffs. Yet it's the Elephant who gets things done in change situations. You need to appeal to both. The Rider provides the planning and direction, and the Elephant provides the energy. Understanding without motivation vs. passion without direction.

...And make another simple but non-obvious observation that change is hard because people wear themselves out. The "one paragraph" summary of the book is that there are three components to a successful difficult change:

1. Direct the Rider - provide crystal clear direction. What looks like resistance is often a lack of clarity.
2. Motivate the Elephant - Engage the people's emotional side. The Rider cannot get his way by force for very long. What looks like laziness is often exhaustion.
3. Shape the path - Shape the situation in a way that facilitates your change. What looks like people problem is often a situation problem.

There are other interesting simple thoughts sprinkled throughout the text. For example:

• Build habits if you want the change to stick
• Shrink change - give simple actions
• Create a destination postcard (pretty vision of the final state) to motivate

Twitter, SADB and elephants

Now, why am I going on about a management book?

In my previous post I included a slideshare link to a talk about security automation from Twitter. There is also a video at http://videos.2012.appsecusa.org/video/54250716. Prominently featured is Twitter's central security dashboard, SADB ("sad-bee", funny) - Security Automation Dashboard.

One of its main functions is checking newly pushed code for known vulnerable patterns with Brakeman (see slides 46+ in the slideshare and quick demo video at https://www.youtube.com/watch?feature=player_embedded&v=0ZZKCyBR8cA and immediately bugging the responsible developer with specific recommendations on what has to be fixed and how.

This strikes me as a perfect implementation of "Direct the Rider" principle and "Shrink the change" approach.

I am going to try similar approach at work, we will see how sticky the resulting improvement is going to be :)

Some links:

Extracts from the book:

http://www.heathbrothers.com/resources/download/switch-framework.pdf
http://www.heathbrothers.com/resources/download/switch-for-organizations.pdf

A related behaviour change framework:

http://www.behaviorwizard.org/wp/ - from Stanford