In the spirit of Cybersecurity Awareness Month, here’s a question to ponder, how often do you consider security vulnerabilities when designing and executing your test cases?
- Always, top priority in tests
- Frequently (not every cycle)
- Occasionally when required
- Security is handled by others or another team
Bonus security points for your thoughts (no bad actors please )
2 Likes
Not really on my current project, but I did flag some concerns during the sprint planning session for one story.
Basically the story was for a public-facing web portal, where people who had been issued a fine could go and make a payment for that fine. The validation for the user was to enter the reference number from the fine, and the amount of the fine. Once entered, the user is taken to the next screen where the details of their company and the nature of the fine are shown as a final confirmation.
I pointed out that with only two pieces of data gatekeeping that information (who was fined and why), where one can be easily observed to be sequential and the other can only have a limited number of values, anyone with an interest in brute-forcing the form could scrape a whole lot of non-public information about businesses that had been subject to legal penalties (and with a reasonable chance of some of the scraped data belonging to these people’s competitors).
I suggested adding another factor (e.g. the issue date of the fine) to make the time investment of potential scraping a couple of orders of magnitude harder, but PO decided they would rather not put another barrier to people trying to make the payments.
I didn’t fight it further since it was their risk to take, but I did make sure to go around the room pointing at everyone and reminding them that they were my witnesses to having raised the concern if it ever blew up later lol…
2 Likes
Not so much a test case thing though we will have some basic test ideas used in general exploratory sessions to catch basics.
Often owasp top ten are flagged as risks on every project, discussed early so we can build in protection against them and also plan some testing sessions focused on these risks.
It tends to fall into the unknown or not sure category as we have done those early discussions to rule out what we new at the time.
So then its more about experimenting and investigating each of those risks rather than specific test cases, we have pro version of burp suite to assist in those investigations but often we’d do all the deeper focused security testing sessions at milestone points before release.
The ongoing security monitoring scripts are a bit out of my own knowledge skill depth but we have others who help set them up, again with the use of tools.