Are there any books I should read or techniques I should learn? I mostly write Python and C++ if that makes a difference
- https://latacora.micro.blog/2018/04/03/cryptographic-right-a...
- https://dchest.com/authbook/
- https://cheatsheetseries.owasp.org/index.html
- https://ssl-config.mozilla.org/
Also looking for suggestions!
1- The basics. Read about securing data, hashing and salting, not logging or committing secrets, etc.
2 - Think. Think about what you are doing at all times, and how it can be attacked. Even theoretically.
3 - The OWASP top 10 is a pretty good starting point to understanding what's going on.
4 - Don't roll your own crypto.
I'm always amazed at the creativity of attackers, so there's no way to write perfection. The best most folks can do is keep up with current attacks, understand how they work, and make sure you aren't writing things vulnerable to it.
I think the most important advice of value I could give is that you must always keep reading, learning, and integrating. Security, like most fields such as medicine, law, or tax codes for example, requires constant learning and adapting.
The classic for C++ is Seacord's "Secure coding in C and C++". As for techniques, you'll want a mix of:
* design (using smart pointers, taking advantage of array, vector and string, using optionals, atomics, etc)
* compiler flags (gcc can for example make integer overflows which are normally undefined behaviour defined by wrapping)
* static analysis (e.g. clang static analyser, clang-tidy, many commercial products)
* dynamic analysis (e.g. the clang/gcc sanitizers or whatever VC++ is offering nowadays). They work well together with automated tests.
* code review. It's extremely helpful to have an experienced engineer review your code.
* fuzzing combined with sanitizers
You'll probably want to read about threat modelling (e.g. Adam Shostack's book), to understand common attacks and how to think about them in relation to your projects.
This is important, because you will encounter situations where fixed rules won't work. Making this attackers live hard is something that should be part of every decision you take during development.
E.g. when you have the thought of dyamically loading code for your logging framework from remote systems, your inner attacker would say: "Wow thanks, that makes it much simpler to run my malicious code on your systems". Then you decide if the risk is really worth it or think about how ot could be done in a guaranteed safe way (hint: sometimes there is no guarantueed safe way).