Article by Maureen Robinson
People often believe that if a developer is capable of creating clean, functional code that they will by default be writing secure code.
Unfortunately, this is not always the case.
Security vulnerabilities can result from poor code, functional bugs can be security bugs too, but the trickiest security issues result from code that does more than you expect...
The application may test all of its functional tests but in addition it may have additional unintended functionality that can result in a vulnerability. For instance, a web site with a SQL Injection vulnerability could work perfectly well for a normal user and then work a little too well for a malicious user.
It's important to think of abuse cases, not just use cases. Consider what are threats to this application? How would an attacker visualize (and subsequently attack) it? How do I code defensively against these threats?
Although there are many skills and abilities that may be on your personal development wish-list, if you want to write secure code, consider adding the following skills to your repertoire:
- Ability to create a mental threat model
- Should include all assets worth protecting and possible threats
- Sound knowledge of secure coding standards (known good patterns that work)
- Ideally this takes the form of both a repository of best practices and a library of secure routines you can call into
- Understand and map input paths and trust boundaries
- Enables you to make decisions on how much to trust the data your code is processing
- Know (or have a reference of) patterns of bad code and checklists to check against
- These are useful to keep in mind while coding as well as to check during a review. In pair programming the second developer can keep these in mind while the first developer is writing code
- Know how your application functions and interacts with its environment
- You can’t understand how they’d be attacked if you don’t know how they work. Applications ultimately transmit data and operate on hardware, in a network, etc. So you need to understand protocols, dependencies, communications (encryption), etc.
Cross-posted from CIOZone