My success story, a story about failures

I have a lot of things to say about CAST, to people who would like to speak at a test conference, about personal development and about my own presentation. But first a few stories I want to share, hopefully busting any ideas about "some people are born to speak while others aren't".

Messing up a play

My first memory of something presenter-like was in 4th grade. 4th, 5th and 6th graders were mixed together in drama groups and something like once a month each group performed a play for the other groups. My group's first play was ruined. How? Well I couldn't shut up. I interrupted the other actors, screwed up jokes by explaining even the most obvious ones and was too nervous to remember any of my lines giving everyone else a hard time... The self elected leader of the group (a 6th grader) was furious when all of us gathered afterwards to discuss the play.

My first presentation

Moving on to 7th grade and the first time I presented to a larger group of people (~30). For this presentation each of us were given a famous author to talk about, mine was Charles Dickens. I was so nervous, but I had rehearsed a lot and prepared a rather detailed script so everything should be fine. I went up on stage, took a couple of deep breaths and said... Blaghl...bl..br, which unfortunately doesn't make any more sense in Swedish. I couldn't form a single word! I couldn't even say my name! I tried several times with every failed attempt just inducing more and more panic. Finally I threw away the script and just relied on my memory, which was no problem at all since I had rehearsed sooo much. When the torture was finally over several class mates came up and said: Wow, you were really calm when presenting... I was still shaking.

At the university

I volunteered to become a university ambassador. One part of that job was to speak to groups of high school students. One time the group was rather large, about a hundred people. I froze! I froze for something like 30 seconds (felt like 10 minutes) before I started and when I finally did I think I forgot to tell them like half the stuff I was expected to present.

Improving legacy code
Moving on a few years, now as an employed software tester. I had suggested a very vague idea, basically saying we had to work with the quality of our legacy code. So I was asked to present my ideas to the rest of the department. To make matters worse I got sick a few days before and due to that I had basically no time to prepare myself. I also knew that the material was way too abstract due to the fact I didn't really understand the details. Any professional would say: "I'm very sorry but I'm not ready to give this presentation" (a question I was even asked due to my sickness)... I didn't. The result?
"We need to work with the quality of our legacy code. A few things I've thought of izzzz...", what happened after that is a bit blurry but apparently one of the managers saw I was about to pass out and caught me before I fell, while someone else grabbed a chair. I got some water and actually finished the talk sitting down, still a bit dizzy... it was a memorable talk but not for the reasons I would have liked.

CAST warmup
Let's finish with a much less dramatic story. Just a few months before CAST I presented at a local test meetup in Malmö, Sweden. I would give a short talk on security testing. I felt calm until the moment I sat down in the room. After that anxiety rapidly (and for me surprisingly) built up. I think one of the main reasons was I simply hadn't rehearsed my talk. When Henrik Andersson offered us a beer I quickly grabbed one and it was perfect to ease the anxiety (something I haven't told him). However, knowing I "needed" a beer during one of my last public presentations before CAST was not really... comforting.

CAST 2013
Let's save this one for another post but short story is it went great!

Why am I telling you this?
Long ago I had the misconception that speakers at, for instance, conferences were natural talents who just had something I didn't possess. A misconception with an interesting twist as today I often hear people call me a naturally talented speaker. What I've learned, and hope my stories help you see as well, is that that something is mostly hard work. If you decide you want to learn to present there's no exotic gene stopping you.

Why am I telling you this... 2?
You might look at the stories I shared and say: "Why not focus on your successes?", but here's something cool: The stories above are my most important events as a speaker. Without them I wouldn't be in the position I am today as a speaker and if I sound insane, let me give you some examples:

Messing up a play

• I need to sometimes stop myself and simply shut up.
• I need to think about what's interesting to the listener, not just what I want to say.
• Being well prepared (rehears) is key!

My first presentation

• I can actually present.
• I don't need a script.
• Even the worst case scenario wasn't that bad (you could argue that passing out is worse than not being able to say a word but they're pretty close).
• There are things I can't seem to learn/fully understand without actually failing first.
• There's no such thing as a failure or success, we always fail to some degree and we miss out on a lot of potential success if we don't take the opportunity to learn from these small or big failures.
• As long as I rehears, things seem to work out okay no matter what.

At the university

• Silence is actually not that bad.
• Less is more, I forgot a lot of the prepared material but in the end that seemed to make what I said, stick better (based on reactions from students after the presentation).
• You can turn a bad start or problematic presentation into something great, it's never too late. This one actually turned out as one of my better presentations as an ambassador.

Improving legacy code

• Doctors didn't find any problems with my heart, lungs or head (obviously physical health was enough). That's actually quite comforting.
• Due to all the medical tests I had to leave a whole bunch of blood samples which eased my fear of needles and hospitals.
• ... and that taught me a valuable lesson about fear: Fear is much about not knowing the outcome, not about the experience itself. Understand that and a whole lot of things stops being scary (very, very powerful insight).
• I know my limitations better.
• I know when to say no better.
• I know the possible consequences which further helps me say no when I really should.
• I've learned the value of understanding the content I'm about to present.
• I need to rehears.
• I need to rehears.
• I need to rehears.
• I've learned code quality is much more complex than I once thought it was.

CAST warmup

• I need to rehears
• I need to rehears
• I need to rehears
• Open season with K-cards is actually not that scary (I had not tried that as a speaker before)
• Beer solves a lot of problems... kinda.

You can do it!
If you feel like presenting at a major conference would be cool but you hesitate since you're not a "natural speaker", Think again!

Practice
At work, local meetups, small conferences, at home or maybe checkout Toastmasters International (Credit to whoever gave the lightning talk about Toastmasters at CAST, just found out we have a local club where I live so I'll give it a try!).

Challenge yourself
Try new things, get out and speak in front of people, record yourself, test various formats, present without slides, try drama or stand-up, present in front of more people, present in a non-native language...

Wrap up
I think I'm a talented speaker today, and that's not just based on my CAST performance. But it has little to do with my amazing genes, it has to do with practice and challenging my limits. I'm pretty sure all your favorite speakers have similar stories (or at least I hope) and that their biggest secret too is practice.

So don't wait to become a great speaker, act to become a great speaker!

Oh, I forgot!
A key inspiration for this post as well as one of the real highlights for me during CAST, was Dawn Haynes' keynote. Make sure you check it out!

Oh, I forgot... 2!
During open season, several people asked me about my failures and how I dealt with them. Hopefully this post answers some of those questions. If not, please ask your question again (Peter, Simon and Jonathan were the ones I remember, did I miss anyone?).

Thank you for your time and good luck with your presentations!

ConTest (meetup) - Security Testing

What is ConTest?
ConTest (link in Swedish) is a local test meetup in Malmö, Sweden started by Henrik Andersson (please correct me if I'm lying). Each meetup they have a theme and participants provide content by sharing short presentations/lightnings talks (approx 5 mins) that are followed by a facilitated discussion.

First Talk: Martin Thulin: Learning Security Testing
Martin, just like me, started exploring the world of security testing quite recently. In his talk he went through his top three resources for self-education in security testing:

• Google security blog
  General information about online security
• OWASP
  Great cheat sheets, basic security information, list of security testing tools and much much more.
• Hack this site
  Step by step hacking challenges used for practice/learning.

But maybe most importantly he shared the message:
"Anyone can become a hacker"

Great topic and great presentation!

In the discussion that followed tons of resources came up. I won't list them all here, instead I urge you to check out the #foocontest hashtag in Twitter..

Second Talk: Me: Quick Tests in Security Testing

Quick tests are cheap (quick, simple, low resource), general tests that usually indicate the existence, or potential existence, of a common problem or group or problems. Even though rarely proving the absence of a certain problem they can often be a good start to help you highlight common problems early (disclaimer: this definition/description of quick tests might not match with James Bach's and Michael Bolton's that is used e.g. in RST).

I spoke about two quick tests (for web) I've used:

• Refresh
• Cocktail string

Refresh means whenever I find a page that seems to make a lot of database calls, heavy calculations or connect to external servers (like an email or SMS server) I simply press and hold F5 (refresh) for a short while. What I'm looking for doing this is database errors, any changes in content/design, error messages in general and a finally fully context dependent stuff like received mails when the page is calling an email server or alarming patterns in logs.

In practice I've used this to take down a couple of databases (or rather connection to the databases). Simple and effective. Credits to Joel Rydén by the way who taught me this.

The idea with the Cocktail String is described in a separate post.

As a bonus I can provide you with a few other:

• Scramble cookies
  Just quickly change the contents of cookies a page creates. Try both to generate errors by e.g. use strings where a number is set, use other plausible values (0 is always interesting, negative values as well) and combine with the cocktail string.
• Back button
  When viewing sensitive data, log out and try pressing back. Is the data visible? Common and scary bug in some systems (systems expected to be used on any shared computer/handling very sensitive data), irrelevant in others (remember browsers deal with caching differently).
• Bob
  When creating an account first try password "bob". It's so insecure very few systems should allow it (but does).

Final Talk: Sigurdur Birgisson: Security, Usability... huh?

I was a bit disappointed about Sigge's talk, not that it was bad (it was actually awesome) but because I was hoping he would share something really smart about how to deal with the often conflicting wishes of security and usability (like captcha). It also had very little to do with security testing, but who cares...

So what was it about? Sigge talked about how he thought the quality characteristics (CRUSSPIC STMPL mnemonic) were often interpreted as too abstract when talking to stakeholders. Instead he used the Software Quality Characteristics published on the Test Eye. What he did was he printed a card for each "sub characteristic" and, for best effect, tried to add matching examples from the product examined. The goals were both to get the cards (characteristics) prioritized to aid the testing focus, to support a healthier discussion of what the product needed to do as well as to make stakeholders care for them (it's not just about new features).

- It must be quick, quick is above everything else!
- What about data integrity?
When I said that, the customer started to hesitate
// Sigge

Henrik Andersson also shared an interesting story related to this presentation where he had gotten the top managers in a company to prioritize the original 8 quality characteristics (CRUSSPIC) in the context of a product and used this both when testing and when reporting status. Brilliant as well!


There are a lot more to say about this presentation and I might get back to it in the future. For now, just check out Sigges blog. Finally it made me think of ways to improve my own ongoing prioritization job with my product owner, for that I'm really grateful!

Summary of ConTest
Great people, great mix of people, great discussions, great presentations, great facility, great to meet Sigge before his Australia adventure, great to meet Henrik Andersson for the first time, great to try ConTest's format and great to get new insights about security testing. ConTest was a blast! Thank you Malmö, Foo Café and all the ConTest participants!

Cocktail Strings - Quick Test for Web Security Testing

This is a part of my talk on ConTest this evening. I started blogging about the whole event but time is running out so I'll start with this and provide you with the rest tomorrow.

Cocktail String?

Cocktail String are a form of quick test that can be used in security testing. The idea is a general string with a mix of ending characters and other stuff that can be used for MySQL injections, XSS and similar. Here's the example I provided:

'"$%>*<!--

The initial single and double quotes are to screw up badly sanitized query strings or similar, the $ is to get an error in case the string is evaluated as PHP, %> is to end a PHP or HTML tag, the star I don't know what it's for but since it's often used as wildcard in various situations I figured it might provide something and the ending <!-- is my secret weapon as it safely, but with a cool effect, exposes possibility to execute user defined HTML (and thus potentially scripts like javascript).

Where to use?

The string, or variations of it, can be used wherever users can send data to a server like in forms (especially look for hidden form named "id" and similar), cookies, file uploads, HTTP requests etc.

What are you looking for?

Exactly what to look for depends on context but here are a few suggestions:

• Any kind of errors like no database connection, faulty query errors, code errors etc.
• Garbage being printed on the page
• Any irregularities on the page (even subtle design changes like an extra line break)
• Check HTML code for occurrences of the string
• Check for errors in any logs
• If used in combination with databases, check the database content
• Check cookie content

Actual examples

I names my user this on a server application. Everything was fine until I started the administration interface, suddenly I couldn't see anything but a few garbage characters on a white background. The reason was the user's name wasn't sanitized on the admin pages but everywhere else.

Another similar example was when I used it as name for an item occurring in a log blanking out everything showing up after that log entry.

Finally I  used it on a friend's project to highlight MySQL injection possibilities.

Ways to improve it

Many great suggestions to improve the string came up during the meetup. One was to add unicode versions of certain characters since this for instance fools some sanitation functions built into PHP as well as other sanitation plugins. Another was to add international characters including stuff like Arabic and Japanese. Finally Mattias suggested using an iframe instead of the comment tag at the end since loading a scary page is even more striking than blanking out half the page (as well as actually proving a really destructive bug exists). Cred to a lot of people for all the great suggestions (especially Simon for unicode, I'll add that for tomorrow's testing!).

Finally notice you'll have to change this string to fit your context, for instance a string used on an ASP.NET application or a Java desktop application looks different.

Automation

One interesting comment that came up was automating this (which is typically what security scanners do already, by the way). First off, it's suited really well for random automation that just sends various combinations of dangerous characters into every field it finds and compares for instance HTML output to a control. Might miss stuff / give a lot of false positives but still a great way to work with it. It also addresses one of the weaknesses with the string; since it uses so many different commonly filtered out characters the string might get filtered out due to one character while a couple of the other would have worked in isolation (this is typically what I mean when saying quick tests rarely provide evidence that a certain problem can't exist), with the speed of automation (assuming you achieve that) you could test them more one by one as well as in more combinations.

Summary

So a bit of a messy post but long story short:

Instead of Bob, name your next test user '"$%>*<!-- and let it live in the lovely city of '"<!-- with interests in  '"$% and >*<.

Good night!