Would Heu-risk it? Part 3: The Rift
This time the category is attack (or weapon) so this is an area where developers tend to be weak and/or it is complicated and easy to make mistakes. So, let us start with having a look at the rhyme:
”Gaps, cracks and holes let your enemies through
To spy, steal or cause other problems for you
Make sure that you put proper safety in place
To shelter your castle, your home and your base”
So, what does it mean?
The meaning of this card is pretty straight-forward but might look intimidating because…. security testing is for experts, right?? It´s REALLY complicated, right? Well. Yes and no.
First of all: I´ve already written a post about this so let us start there.
There are SO many ways to get started and even if you might never replace an expert security audit, there are so much to gain from picking all of the low-hanging fruit (or even the middle-high-hanging one!) and starting on the path of moving security from something you order once a year from a security audit firm to something part of your normal pipeline.
Evil user stories, looking into the OWASP testing guide, installing a tool for static code analysis (like Whitesource Bolt) or even learning about privacy-by-design, they are all ways forward that do NOT require you to be a hacker.
Learning about injection attacks, how ”helpful” error messages can also help an attacker get in and/or just playing around in DevTools(most browsers have them!) or BugMagnet will help you become more and more confident.
Another thing I really wish more people did is to actually READ the reports you get from a penetration testing audit and try to understand them.
– How did they test this?
– How would a system that did not have this flaw behave?
– How can I test that this has been fixed?
So many people out there are happy to help!
Send me a ping on twitter and I can almost guarantee that I can connect you to someone who can help you. 🙂
Story time
The first thing that came to mind as an example is from a system that, like so many others, presented users with a receipt upon completing a certain use flow. Basically we mirrored everything the user had provided us with, all wrapped up in a pretty pdf. The pdfs had unique, randomly generated, names.
What we had missed, unfortunately, was that the pdfs were not protected. This meant that if you had the link (say in a browser history on a public computer perhaps) you could get hold of all of that sensitive data.
Additionally, once you figure out how those links worked, it would have been possible to try and brute force those ids and get hold of a lot of sensitive data.
Once we found it, it was a very small change needed in order to protect the files by making sure only the user ”owning” the data could access it.
Another example is that at one point, an application I worked with started throwing warnings that personal number/social security numbers sent in through a certain channel didn´t match neither gender (Swedish personal numbers include such information) nor the name associated with it (collected from en external service by the backend system).
At first, we suspected transactions and/or sessions getting mixed up somewhere along the line and, due to the nature of the data, we shut down services while investigating. We dug through logs, investigated threading, screamed at each other.
Then, at one point, we noticed that most of the transactions came from a very limited set of IP-addresses.Now our fear was that someone was using the services to scrape for personal data.
In the end, it turned out that it was all human error. Someone was, as a service, helping others fill our the rather complicated form and simple entered the wrong data.
Once we found this out we could add the above mentioned checks earlier in the flow, helping the user not make mistakes.
The reason I add this example is that it is an aspect of security that is often forgotten: People.
Quote of the day
“My opinion is it will take a lot of time to practice the mindset,
Quote by Santosh Tuppad
but starting up and passionately investing time in the practice
may take you higher in a quicker way”
Reading suggestions
OWASP testing guide
OWASP cheat sheet project
Security Testing & Mindsett – Q&A With Santhosh Tuppad
MoT Power hour on security testing with me
But I´m not a security tester by Kate Paulk
Getting started in security testing – MoT Masterclass by Dan Billing
(note: requires Pro account)
Previous posts in the series
| Title and link | Category |
| Part 1: Introduction | None |
| Part 2: Mischievous Misconceptions | Trap |
Om författaren
