Abuser Stories: thinking like a hacker
“I have a cool idea”, said every bol.commer.
“The customer will love this”, they continue.
“What about security or possible fraud”, someone raised.
Thinking of requirements that limit your cool idea doesn’t sound like a lot of fun right? But actually it is. This blog post is about a concept we came up with to facilitate just that, thinking of features from a different perspective and in a fun way. A very simple idea using something everybody already was familiar with (user stories), but with a little twist.
What is an Abuser Story?
At bol.com day in day out, we are thinking of new cool innovations for our customers. We try to capture these ideas in User Stories, reasoning from the customer perspective why we would like to develop these new features: “As a customer I want… So that…”. But what if we turn it around and try not to reason how a customer would use it, but how someone would abuse it. Abusing functionality in a way that is not attended, to either gain something for personal use or just to mess with others. This is where the term Abuser Story comes from. Where you would reason from someone that wants to hack your functionality, hence a hacker: “As a hacker I want… So that…”. When thinking of a hacker you don’t always have to think of that technical hacker who sits in their dark attic somewhere, it can also be your neighbor that functionally hacks your new feature.
When thinking up Abuser Stories or cases for your new functionality, you are more or less thinking about what kind of abuse you can think of. Because if you know how you can abuse it, you can start to think about how to avoid this abuse. Together with your team you can brainstorm about this, which eventually results in new (security) requirements.
What is the use of it?
We all know preventing is better than fixing. There are a lot of articles and examples about that this is the case for bugs, but the same applies to security vulnerabilities or fraud. This is also why developers and testers have the opportunity at bol.com to attend our so-called Hacker-trainings. In these (technical) trainings, a hacker-mindset is taught by hands-on examples like XSS or SQL injection. Again with the idea that if you know how your technical solution can be hacked, you also know how to prevent this.
But new features start way before the implementation phase. And next to that not all ‘hacks’ have to be technical. You can already start thinking about this abuse in an early stage, for example during the business analysis. This triggers to think about unhappy flows, strange behavior a normal customer would not think of but someone with bad intentions would. Just with user stories you can eventually translate this into new requirements and start to think about the implementation details.
“Developers write code, analysts write user stories.
Hackers write hacks, analysts write abuser stories.”
How do we apply it?
The concept is simple and it can be applied in multiple ways. We don’t write hundreds of abuser stories a month like we do with user stories. But we do take some time to think like a hacker to come up with new requirements for our features. Not just because it’s necessary to avoid abuse, but also because it’s a lot of fun to think evil. Check some examples of how it is applied.
Workshop/game format: at the kickoff of an epic the team (business and development together) is split into two. Attack and defense. The attackers are obviously the one wearing the hackers hat and brainstorm together how the new functionality can be abused. The defense, on the other hand, are the ones who think about how abuse can be avoided or limited. After a while, the hackers present their attacks, where the other team needs to counter this with a defense which makes this abuse impossible. The attackers can try to counter this again, and so on. If only one attack is not countered the hackers win :-) . All attacks and defenses are written down to use as input for the (ab)user stories of the epic. It’s a lot of fun (and sometimes scary) to see how evil your teammates can think.
As part of a user story: analysts brainstorm about possible abuse of a feature when writing the user story. Instead of making it a separate “Abuser Story” they process it in the user story itself. They write down these abuse cases and translate it into some requirements in what kind of abuse needs to be avoided. Same as a user story, but different.
What is the result?
With the use of Abuser Stories we balance functionality and security. You will see that avoiding abuse sometimes means that you have to limit certain functionality. Sometimes we even see that certain features should not be built at all. But there is a balance. Are you not limiting it too much in a way it takes away the value it offers to your customer? What’s the risk? Is it worth it? The most important thing is that we are making more considered decisions about this, however if it happens, be less surprised in hindsight.
Applying this new perspective is not only useful in building more secure features, it’s also just a lot of fun and it brings teams together. We all have this evil genius inside of us, and it’s fun to let him out once in a while. So put on your hackers hat and start thinking about how your (new) features can be abused.
An example.
So enough talk about the concept, lets illustrate it with a (hypothetical) example.
Let’s say we want to avoid disappointing customers who take a break in their shopping at our site and selling products they already put in their baskets to others. In other words, to reserve the product in stock when someone puts it in their basket. Sounds like a nice feature that can help out our customer, what could possibly go wrong?
Just take a little time to think about it yourself… probably you can think of some nice abuse cases.
So... what about putting 1000’s of products in your baskets just to freeze a part of our warehouse. Or why not just the entire catalogue of a few million products? That so we are out of stock for all the other potential customers. It sounds like a good idea to limit this functionality a bit right? See the abuser story and following user story (attack vs. defense) below.
This is an example which can be translated into further requirements like limits and checks. But how its implemented development-wise is not the focus here. It’s about what kind of abuse you would like to avoid in a functional way, just like you do with a user story.
“We all have this evil genius inside of us, and it’s fun to let him out once in a while.”
Are you sure all your (new) functionalities cannot be abused? Or maybe that of your colleagues (be gentle…). Why not take some time trying to break it, maybe together with your team? As you can see it is not rocket science and just take these examples as inspiration how you can use it yourself – no abuse possible. Have fun and hack away!
PS: If you did use it in some kind of way, don’t be shy and share your experiences.