So my recent Power Hour at Ministry of Testing got me thinking.
To start: I’m sorry, tomorrow-morning-me, apparently I had to write this now, while on the rush of that experience.
Why am I feeling this rush? From a Q&A? Well. I’m doing a workshop about security testing and OWASP Juice Shop this fall and I’ve been worrying about it.
– Maybe it’s too easy and scripted?
– Will people learn anything?
– What if people who know more than me show up and get disappointed?
– What if someone gets stuck and I can’t help them?
Well the questions and reactions on the power hour (and discussions outside of that) have led me to realize a few things:
1. A lot of people are completely intimidated by the concept of security testing
2. A lot of the material out there expects a certain level of basic knowledge
3. And a lot of people can’t make it over that first hurdle
4. I’ve got this.
Yes. A few people will find it too easy. Some might even find it too hard. But you know what? Others will find it exactly right. And then it’s a win.
So. Let us back it up. I need to tell you a story.
My first direct contact with security testing was almost a decade ago. It was my first web project and in a security audit I learned about the concept of SQL injections for the first time. I was intrigued! I learned a bit, enough to make me able to check that it had been fixed, and added another tool to my tool belt without thinking about it.
Enough to understand Bobby Drop Table-jokes but not much more.
In that same project I learned about testing SOAP and how to manipulate calls; and by doing that I made myself a little more versatile, again without realizing.
Next up was sessions and query string. I learned how to manipulate those and just how easily that could be exploited.
I think up until that point it felt like something only ”true hackers” would do, and I didn’t really put much weight on those types of testing but with variables it became so easy! I mean if you put something glaringly obvious in your URL, someone is bound to be curious and try to change it! Someone who might not even mean to do harm.
Along the years I’ve picked up small things, piece by piece, to put on my pearl necklace of security testing and for me a big change came a few years back. In that year I had been reading a lot of audit reports, due to my role at that time, and after the third or fourth I was confused and annoyed.
– Are they just sending in the same reports with switched title pages? Because they sure say the same thing.
– This is not rocket science. I understand this. I know how to check for these things.
– We are making the exact same errors as in that first web project of mine.
Which led to:
– WHY ARE THEY STILL CODING LIKE THIS?? THEY SHOULD KNOW BETTER!
– WHY ARE WE NOT TESTING THIS?? WE SHOULD KNOW BETTER!
– WHY… oh…. damn. Why am I not pushing for this? Why have I not made sure we test this?
Because if I can understand the reports I can figure out how to check it. If I can figure out how to check it I can find someone who knows how to fix it. If I can learn how to fix it and to check for it I can teach others. If I teach others they will grow and learn and somewhere along that line we might just stop introducing those errors over and over again.
And that is where my mission started. I want to find a way to make the bar low enough for anyone with basic software knowledge to take that first step. Learn that one thing. And then the next. And the next. I want people to understand that yes, it is a VERY complex area, and the difference between a TRUE expert and someone like me is huge, but that doesn’t mean I can’t make sure to check that the basic things that frankly all applications should make sure to protect against, are fixed, tested and in the end: never introduced in the first place. And THEN we can add some real penetration testing on top of that, by experts.
The workshop was born from that. And I hope after the workshop we can refine it, make it even better, keep building upon it and hopefully release it into the wild!
Because:
Security should be on our mind from step one and all the way to the end.
– It should be a factor in all requirements (such as: evil user stories, evil personas, threat modeling, just thinking ”how could someone exploit this”)
– It should be a factor in our coding (such as: programming guidelines, SonarQube, Whitesource bolt, ZAP, just thinking ”how could someone exploit this”)
– It should be a factor in our testing (such as: Bug Magnet, OWASP ZAP, Chrome DevTools security audit, Postman, just thinking ”how could someone exploit this”)
– It should be a factor in our operations (such as: monitoring and analyzing behaviour, configurations, audits, logging… I can keep going forever and ever)
Build it into your pipeline. Build it into your culture. Learn it. Preach it. Teach it.
