Security testing can feel like a scary thing. There is so much you need to know to be a security expert. However, you need a lot less knowledge to help security experts. This article lists some practical ways you can help your local security experts.
Attackers
Software security is an act of defense. As defenders, we create armor for our applications so attackers can’t reach their end goals. The end goals include money, data, making you suffer, and the thrill. These are difficult things to defend against.
Instead, we’re better off focusing on the attacker’s intermediary goals. No matter the end goal, they’ll constantly need to achieve one of the intermediary goals. Attackers want to:
- Find out how your system works
- Run their code on your machine
- Collect data
If we deny attackers the chance to reach these intermediary goals, they can’t hack into your system.
What to defend
The OWASP top 10 is a great place to start for every security skill level. It lists the most common security vulnerabilities in the real world. The top 10 contains a mix of basic and advanced security concepts. I will highlight a few security issues you can reasonably test for if you’re not a security expert.
Broken Access Control
Broken access control is number 1 on the list, making it the most common security issue. It relates to data exposed to the wrong user. For example, you can see some data intended for your supervisor. Or maybe you can see a page without logging in.
Security experts without intimate domain knowledge and automated tools can’t detect all access control issues. You need domain knowledge to figure out who should be allowed to access what.
To test this security issue, you don’t need any testing tools. When testing, you look for data you can access without an account or with the wrong account.
For more information on this security issue, see the OWASP cheat sheets:
- Authorization Cheat Sheet
- Insecure Direct Object Reference Prevention Cheat Sheet
Insecure Direct Object Reference is the jargon version of ‘manually change a URL and see if you can find something.’
Injection
Injection attacks allow attackers to run their code on your machine. It happens when your application treats user input as application code.
There are many types of injection attacks. The exact type of injection your application might be vulnerable to depends on your tech stack. For example, if your application uses an SQL database, it might be vulnerable to SQL injection. When attacking, you must know the exact type of injection. When testing, it’s not as important.
No matter the type of injection, the mitigation is always the same: Sanitize all user input. When sanitizing text, you strategically replace some characters. Replacing a few characters is enough to prevent these attacks. Which characters to replace depends on the type of injection and is listed in the cheat sheet.
Injection attacks can get quite sophisticated. However, when testing, we only check for user input sanitization. Missing sanitization means a potential attack vector to fix. This way, we can ignore the technical details of attacks.
When testing, check that all user input is sanitized. Test sanitization of all form inputs, URL parameters, and API parameters. None of these user-controllable inputs should ever be executed as code.
Automated tools can help you detect unsanitized inputs. The most notable tool is
OWASP ZAP. Please note that this tool can be quite a rabbit hole. You may want to ask a developer or security expert for help.
For more information on this security issue, see the OWASP cheat sheet:
Vulnerable dependencies
When you release your application, you also release all its dependencies. Since these dependencies are code, they may contain security vulnerabilities.
Thankfully, you don’t have to test or review these dependencies yourself. We can rely on a network of security experts who find and report
Common Vulnerabilities and Exposures (CVEs) in dependencies. We can use this database of issues when testing. The reported security issues are often fixed in a newer dependency version. So all we need to do is update our dependencies.
There are a whole bunch of automated tools that can test this. Some of these tools are open source while others are commercial. For a complete and up-to-date list of tools, see the cheat sheet.
For more information on this security issue, see the OWASP cheat sheet:
Conclusion
It takes a lot of knowledge to become a security expert. However, even with basic knowledge, we can help the experts so they can focus on the complex stuff. If you’re not a security expert, there are still a few things you can reasonably test for. These include broken access control, injection attacks, and vulnerable dependencies.
Which security issues are you going to test for?