Introducing…Ticket Magpie

Solving a problem of learning

I’d like to introduce you to a little project that David Hatanian and I have been working on. David is a member of the fantastic team at Codurance, and we first started working together on this project in February 2016.

Following my experiences at European Testing Conference in Bucharest, I realised the time had come for me to create and build my own vulnerable application. This was so that I would be able to run my own workshops on security testing, coach my colleagues and other testers aswell as demonstrating vulnerabilities; such as the OWASP Top 10.

My initial forays into learning security testing relied upon learning from a number of publicly available web applications. These include AltoroMutual, Gruyere from Google, and  Supercar Showdown by Troy Hunt.

I also worked closely with Bill Matthews, initially shadowing him, but then helping him to deliver workshops at international conferences. For these workshops, he built his own web application, Ace Encounters, which is a travel and wild adventure website.

Of course, using a real world application to practice these skills is highly illegal. So, students of security testing need a safe place to practice and learn. We aren’t hackers after all, we are testers. We aren’t there to steal, undermine or attack. We are there to explore and learn.

Pairing with David has been incredibly rewarding for us both. I’ve supported him with his understanding of security vulnerabilities, and he has supported me with my learning of object orientated programming (in this case Java).

A couple of months ago I ran a session using Ticket Magpie,  for the testers at NewVoiceMedia. The session was well received, and everyone appeared to have fun. The team there are really great at generating interesting test ideas, developing their skills, and following through with practical application of their learning. Taking this out into the wider community of testers was to be the next step, at Test Masters Academy.

i-love-shiny-things

Get Ticket Magpie

Ticket Magpie is easy to get, from David’s Github project. Check it out here and follow the instructions on the page. Here is some additional installation guidance.

Local Installation

  1. Install the components locally on your machine. You’ll need Maven, Java Development Kit and the Ticket Magpie project.
  2. Configure the JAVA_HOME and PATH environment variables, appropriate to your operating system. (Supports MacOS, Windows and Linux)
  3.  Run the application from the command line.
  4. You may choose to set up your own database, or run it in memory whilst the application is running.

Virtual Machine Installation

  1. Install Oracle VirtualBox or your favourite virtualisation tool on your machine
  2. Create a virtual machine using your OS of choice.
    • I like to use Linux Mint for this. It’s lightweight and easy to configure.
    • Remember to give your VM enough space, or make it dynamic. 8gb should more than suffice
  3. Follow the steps above and on the Github page for the project and you can’t go wrong.

Docker (this is by far the quickest and easiest way of getting things running)

  1. Install Docker on your machine
  2. Run the application from the Docker Hub image, using the provided command line:
    docker run -e "SPRING_PROFILES_ACTIVE=hsqldb" -p8080:8080 "dhatanian/ticketmagpie"

Running TicketMagpie

Once TicketMagpie is installed on your chosen environment, run the appropriate command line, then navigate your browser to:

http://localhost:8080

If you are successful, your browser should display the application, and it should look like this:

ticketmagpie-the-place-to-get-all-the-tickets

Ticket Magpie

Bug Hunt

I invite you to have a go at exploring Ticket Magpie. There are some fun features for you to take a look at. I’m not going to spoil things for you by listing everything here. You might also find some interesting problems.

Because the application runs on your local machine, docker or VM, you can use any technique, tool and gnarly hack you want, without harming anything or anyone else.

Take your time and let me know what you think. If you feel the need, you are welcome to use this form to provide feedback about the application: Ticket Magpie Survey. Alternatively, just message me on Twitter, or comment on this blog.

Good Luck, and Thanks!

game-over-man-game-over

 

Journeys – in time and space

We’re all on a continuum. Life will take you in all sorts of strange directions, be it professionally or personally. These are some reflections on some of the goings on I have experienced recently.

Goodbyeee

blackadder

Going over the top… Blackadder: Goodbyeee Copyright BBC (1989)

Up till the end of September, I had been working at NewVoiceMedia for nearly three years, initially as a contractor, and then latterly as a permanent member of the development team.

It was an incredible time. The opportunities that working at NVM afforded me were huge. Learning new skills, particularly in security testing, and working within strong, fast paced, agile (Agile) teams.

I thank everyone that I worked with at that time, especially Rob Lambert for giving me that chance, and enabling great testing and work in general.

I want to be a part of it…

New York. My first visit to this incredible city afforded me many great opportunities for learning, as much about being a citizen of the world (which Theresa May insists that I am not), than it was about anything else. Whilst the traffic, noise and hubbub are all consuming and sometimes overwhelming, especially in Manhattan, there is a sense of energy that I have felt that is unlike any other city.

I was there for Test Masters Academy, which was organised by Anna Royzman. Whilst I have presented workshops and talks on the subject of security testing before, this was my first time presenting in the United States. Also, this was the first time presenting using a tool that I had helped to build myself.

I came to a conclusion earlier in the year, following European Testing Conference in Bucharest. I needed to step up my game. The best workshops I had been to had been well planned, with great resources and learning opportunities. The course teacher had often created or supplied applications for the attendees to explore and test. I needed to do the same.

At ETC I met Franziska Sauerwien, of Codurance, who put me in touch with the Software Craftsmanship Slack group. There I paired up with Java developer David Hatanian, also of Codurance. Together, we created Ticket Magpie, a vulnerable web application written in Java. (More on Ticket Magpie in a future blog post)

ticketmagpie-the-place-to-get-all-the-tickets

Ticket Magpie

 

During the workshop, a few technical issues were to be had regarding deployment and hosting of the application on the attendees laptops. I wasn’t to be deterred, and adapted using a couple of publicly available web based vulnerable applications.

However, I quickly found that basing the content solely upon a list of well known application vulnerabilities was a mistake. It’s more important to understand the concepts of security testing rather than the vulnerabilities, without a framework in which to understand them, and the skills to explore them. This realisation was further clear to me after discussing them with Maaret Pyhäjärvi, and having a post mortem discussion with Jess Ingrassellino at the conference.

Future workshops will be supported by Ticket Magpie being deployable via a stable Docker Hub image, rather than relying on Virtual Box images, or attendees setting up the system themselves. Also there will be more of a focus on the techniques and skills of security testing, rather than just vulnerabilities.

New Pastures

This is now the beginning of my second week at Medidata. This is a new way forward for me in a number of ways. It’s my first time working in the medical and life sciences sector. Medidata build cloud platforms for their clients to manage clinical trials on new drugs and treatments. There is a lot of new domain knowledge to learn, people to meet and company culture to become a part of. It’s exciting.

Next, and this is often the tricky part…adapting to a new role. I have come from a role where I focussed predominantly on the security testing needs of the business. The objectives were to support the team with my security knowledge, plan and execute penetration testing against our services, as well as provide coaching and mentoring to my peers on the topic.

My new role has somewhat a broader remit. It’s not focussed solely on security for a start, which means I’ll get to re-explore other aspects of the testing craft. This is exciting to me. I’ll be working at a more strategic level, supporting the testers, test managers, senior management and other team members across the entire business, globally. They’ll be opportunities for training, coaching and mentoring too! I can’t wait to get my teeth stuck in to it!

Another great aspect of this, is my new commute. Now, I could complain about the cost of the British rail network. It’s one of the oldest in the world, but it does run, and usually gets me to London on time. My commute is usually between 90-120 mins each way, which affords me a great deal of time for reading, learning, and maybe catch up on some work. (Sure, I’ll probably sneak in an episode or two of my favourite TV show, or have a nap if I need one).

Time is a great resource. We shouldn’t waste it. If I’m going to spend up to four hours a day in a tin can, I’m not going to squander it.

Life is always better with two – Let’s Test 2015 Reflections Day 2 & 3

Day 2

Crunch time. Day 2 comes and so does the Exploring App (In)Security workshop alongside one of my most important testing mentors, Bill Matthews.

We had been planning this workshop for some time, and we really wanted to make this work for the attending delegates. Bill had pulled out all the stops to create a really brilliant learning resource in the Ace Encounters web application, and together we planned the learning objectives we wanted to achieve.

Our aim was to provide a safe learning environment where the delegates could learn about security test design techniques, the key vulnerabilities in web applications and how to exploit them. It was also our intention to elicit discussion around these issues in the context of software testing, rather than hacking.

Bill Matthews in Action!

Bill Matthews in Action!

There were lots of great opportunities for Bill and I to learn as well, feeding off the needs of the attendees, and also their experiences. It’s the best way for us to get better at presenting the content, making it more relevant and exciting for everyone. Here are some photos of the day, where we got to work with some really great testers!
          Let’s Test is famous for it’s more social activities. You can’t go far from the conference venue, as it is in the middle of nowhere. So, we all have to create our own entertainment.

As Day 2 drew to a close and after a great chat with some awesome people in The Test Lab, a few of us retired to the games room – ostensibly to play pool, but as always things descended into testing games and chat!

This is part of the attraction of Let’s Test, where you can just hang out, with a few beers (or whisky in our case) and talk about test, the universe and everything.

Chris Chant, Dan Ashby and Phil Quinn

Chris Chant, Dan Ashby and Phil Quinn

On to Day 3, which was again a fantastic day of learning. This conference was my first chance to speak to many testers that I had admired and followed for sometime – such as Patrick Prill – @testpappy on Twitter. I hooked up with Patrick, Christina Ohanian and Dan Ashby at lunch time, and we did an impromptu recording of Testing in the Pub! I can’t wait for that episode to come out.

Patrick Prill

Patrick Prill

The morning lead me to more facilitation responsibilities, this time trying to manage the events at Jean-Paul Varwijk’s very well researched presentation and debate on the proposed ISO 29119 standard.

It wasn’t my job to get involved so much in the debate, but ensure that all the participants of the meeting at least got a chance to take part (If they wanted to) and ensure there was some sort of order to the questions, follow ups and burning issues being raised.

There was a lot of passion in the discussion. Clearly this issue has sparked much interest and concern within the context driven testing community. My main issue however that there was no real moderate or conflicting view arising from this discussion  – most if not all people who spoke up had little that was positive to say about the proposed standard, or opposed it out right.

Still, Jean-Paul had presented a tonne of material he had researched and gathered over time, and presented a cogent argument in as balanced a way as he possibly could. All in all, I am glad I volunteered for this session, as it allowed me to see testers debating in action!

Jean-Paul Varwijk

Jean-Paul Varwijk

Without doubt the highlight of Day 3 for me though was the fantastic session “Coders to the Left” lead Jan Eumann and Philip Quinn. This workshop encouraged us to work in pairs and small groups, with each activity with a different focus, for example working as a tester, developer or observer.

They had created an excellent resource for learning via a GitHub project called Fixture Finder. It essentially allowed you to search football match fixtures, using date and country as search criteria. More than that though, the workshop allowed us to explore what working like a developer might be like – and it was a challenge.

Rather than just finding bugs, we would isolate the cause and fix it on the fly, within our own instance of the app in Chrome. There were some very interesting bugs to find, such as blatant security flaws, or little bits of code that stripped search results from the list, or tampered with the results of football matches under certain conditions.

I know a bit of code. Not so much that it would allow me to call myself any kind of developer. I can use code, and other tools to help me solve testing problems. However this activity really did let us get to grips with how testers and developers can really work well together, reducing and improving the feedback loop as we test and code together. A brilliant exercise in collaborative learning.

Jan Eumann and Phil Quin

Jan Eumann and Phil Quin

Anders, Dan and me pairing up

Anders, Dan and me pairing up

So, as my first experience of Let’s Test draws to a close I want to reflect on what has been a most rewarding and exhausting experience in equal measure. The learning from the workshop I ran helped us feed this learning into the following session at Nordic Testing Days, yet it made me realise that I don’t really blog much about security. I should rectify that.

Let’s Test allowed me to engage deeply with my personal approaches to testing, and what I value about myself as a human being. The impromptu chats, podcast recordings, Reiki healing workshops with Dawn Haynes, the testing games, workshops and talks I attended all helped with that. I do attend to go again, as it is such an intense and engaging place to be.

Promiscuity and the tester

Last week I had the great fortune of attending the London Tester Gathering, where first time speaker Mark Winteringham was leading the discussion with a great talk about mental models around testing tools. A write up and copy of his slides are here: What’s So Great about Webdriver

He was talking about how using Webdriver to automate (testing/checking…I’m not getting into that argument now) has helped him in his work as a test consultant.

However he also referred to the fact that when we use tools, whatever they are, they shape the way we think, how we behave and interact with software, solve problems and communicate. Essentially, through the use of the tool, they end up defining how we test…if we let them.

Referring to one of the highlights of Test Bash 3 – Iain McCowatt’s talk Automation: Time to change our models; (watch the video here) Mark raises the issue that we should be wary of tools, how we select them, use them to solve problems and achieve our end goals.

During the talk, Mark dares us to “Be Promiscuous” with our use of tools, to shop around, not to limit the way we work through limited use of tools, because ultimately that then leads to limited thinking. Whilst the analogy he used sparked a few laughs, he’s dead right.

Mark examined data on the number of conference talks about automation, and the number of automated testing jobs out there, and a large proportion of those are linked to specific tools – mostly Webdriver.

In itself this isn’t too worrying. Webdriver is clearly a popular tool, works well for most people and organisations that use it, and solves a lot of their testing problems. I asked Mark whether the ubiquity of Webdriver presented any dangers to us as testers, and his response was (If you’ll pardon me paraphrasing, it was a noisy room and I had drunk a couple of beers by then) if you define a tool, and eventually it will define you through its use. Essentially, that we should not let the industry or the ubiquity of a specific set of tools define us as testers, nor define our testing.

Whilst I am not a webdriver user, I do use other tools to solve some of the security testing problems that I encounter. In recent months, whilst I have been using tools such as Zed Attack Proxy and BurpSuite, I have found that my approach to testing has been limited by my ability to use these tools, rather than looking around the tool, or using them in different ways to solve problems.

Essentially, the tool was beginning to define how I tested…something to be avoided I feel. The tools that I have mentioned are great, and have a lot of useful features. However through using them, I focussed on what feedback they were providing me, rather than focussing on what was important – what I needed to do to identify vulnerabilities, understanding the underlying functionality and security of the application under test, and by trying to think like someone who wanted to undermine that application in order to protect it.

If that’s not clear, then perhaps this analogy would help – when we learn to drive for example, we are with an instructor, or a parent, in a car with a steering wheel, handbrake, accelerator, brake pedal, clutch pedal etc. It’s usually a small car, on urban roads with a bit of traffic. We build up a mental model of how to drive in our mind based on the tool we are using; the car, and the environment we are in, our local area.

Lets say then, you switch from one car to another – this one might have an automatic gear box and no clutch pedal. This then removes the need for the driver to make their own judgements about when to change gear, as the car will do it for you.

Lets take this a step further…the car has parking assistance technology, or anti collision or adaptive cruise control. These driver aids might then reduce our need to focus on the important skills of parking, or safe driving distances, maintaining a decent speed etc. We become reliant on the tool to do the job for us, rather than using our own mental models for a task to do it. Is these breeding better drivers? I’m not sure that it is.

At some point I will try to take this discussion a bit further and apply some of this learning to the security testing I have been doing. Last year, when I ran the talk ‘New Adventures in Security Testing’ I came up with this mnemonic: Cartoon Tester: EXTERMINATE (Thanks Andy for the great cartoon)

This is my personal developing mental model for security testing, and in the very near future I will work on challenging and modifying this model. Where appropriate I’ll work on sharing and discussing it.

Mark’s talk (and Iain’s) has really inspired me to think again about how I use tools effectively to solve testing problems, but also to remember that a tool, like any device, is only as good as the person controlling it.

Something for the weekend, sir?

In what seems to now have been a storming comeback, the European chapter of Weekend Testing was a breath of fresh air in the learning opportunities for testers. You can find a link to the latest session here. Ably facilitated by Amy Phillips (@itjustbroke) and Neil Studd (@neilstudd) the session was dynamic and a great chance to talk with other testers in a relaxed environment. I didn’t even have to leave my house!

The main focus of the session was heuristics, how we understand, use and learn from them. There is a lot of great material on what heuristics are and how they can be used to inform and drive our testing ideas and execution. I won’t dwell too much on these areas but just hope to point you to some useful material:

Elizabeth Hendrikson’s Testing Heuristics Cheat Sheet

Michael Bolton’s blog post – heuristics for understanding heuristics

Anyway, my main take away from this session was the ruts that sometimes as a tester that we might sometimes get stuck in. I chose the Constraints heuristic, utilising data type attacks upon the World Chat Clock application we were all discussing.

I found myself falling back onto what now I feel to be a bit of a party piece. I immediately decided to perform a few simple XSS and SQL Injection attacks against the application. As I expected but couldn’t be sure, was that the application’s user interface would prevent these kinds of basic security vulnerabilities from being exploited. I did ultimately find a way of injecting XSS, via OWASP Mantra, but not getting it to expose any data. The bug did however cause some interesting display and wrapping issues.

Rather than looking at the functionality, usability, accessibility and its overall purpose somehow I have begun to think the worst about the software under test before I have given myself a chance to really take the time to evaluate it critically, honestly and objectively. I immediately questioned how secure the application was before I considered any other factors.

In my work at New Voice Media, I am part of a cross functional development team, and part of a community of testing interest within the business. During this time I’ve taken onboard a lot of security testing skills, with still a lot more left to learn. It may be that I have taken these skills to heart and want to use them at any opportunity, to develop them further, to discover more about the underlying behaviour of the application under test.

Yet sometimes I feel guilty that I am not approaching the testing of software from any number of other directions, using other skills and techniques. Maybe the newer skills I have learned are higher up in my priority list in my mind before I take other approaches. So, there are of course biases at play here. I’d like to explore that further and challenge them in the future.

Perhaps this has something to do with the way I personally learn things? Early in my career everything was driven from scripts and spreadsheets. There was no impetus to learn better ways of testing, only how to get testing done faster with fewer bugs and more coverage. I was learning how to manage my testing, but not being critical of the testing I was doing, nor evaluating the testing of other people.

Now this kind of learning is the bread and butter of the testers I work with now. We learn, explore, test, check, learn some more, share, improve and the cycle continues. A much more positive way of working. It’s not without its problems, as quite rightly so, you are much more accountable for your work, justifying your choices and decisions. There is a certain level of emotional maturity that we as testers need to develop in order to sustain this cycle, be accountable, share our learning appropriately, learn well from mistakes and improve from them.

This is one of the reasons why I enjoyed Weekend Testing so much. You can’t really hide or be a silent observer. You need to get stuck in and get your hands dirty!

A couple of hours on a Sunday afternoon in the past has not been a huge cost to me, as I would only be doing a bit of housework, DIY, gardening, Scouting, sport or watching something geeky on TV. Soon though however my weekends will be taken up with the ultimate challenge of parenthood, so chances to learn with peers in a relaxed environment will become fewer and far between. More on that learning experience and how it relates to testing another time.

Weekend Testing: infinitely better and more rewarding than mowing your lawn. Thanks to Neil and Amy for running such a fun and exciting session. The same goes to the other participants for the opportunity to learn from you and the excellent conversation.