Currently my company just assumed that Spring handles all those issues for us.
Currently my company just assumed that Spring handles all those issues for us.
- Sending data to an external system that processes commands, including destructive ones like DROP DATABASE? Verify what you're sending doesn't contain commands you don't want to run, each time, every time.
- If you are programming in C or derived, and using expressions that will be involved in array indices or pointer arithmetic, make sure the expression falls within acceptable range before using the resultant data. Since NULL or 0 is an invalid pointer value, it shouldn't ever reach the code that tries to access pointers.
- Should a sensitive function only be called from certain other functions? Should a sensitive variable only be modified/accessed from certain other functions? Enforce that.
- Someone will eventually find anything that's not documented, so don't rely on that for security. Don't expose an interface (especially not through any network accessible method) without an authentication or verification mechanism if it's not OK for it to be 100% public.
- Define everything. A function call should never have an unexpected result. Invalid inputs should cause the function to return errors or throw exceptions.
The above is a good percentage of it I think.
A lot of developers do not know that data should be validated.
The hard part is identifying the invariants of your system. But (and I know I'll sound like Dijkstra), that hard part is also the minimum bar. If you don't know what it takes for your system to behave correctly, how can you hope to build a correct (and therefore secure) system to begin with?
Some people love to say "don't roll your own crypto", with the strong implication that whoever is trying to it is not competent enough. Well, the same applies to any server exposed to the internet, any moderately interactive website, any network library, any video decoder, any compiler… all those things have the potential to go catastrophically wrong in the face of hostile input, and therefore should be held to similarly high standards.
Here's my advice:
1. Make sure you understand invariants, and why they matter.
2. If you don't, train yourself. It may take years.
3. Validate your inputs (but you already know that by now).
Not helpful? Sorry pal, programming takes time to learn, and I don't have the time to teach.
Two books I like to start this process:
* Threat modeling by Adam Shostack
* CISSP all in one handbook by Shon Harris
You don't need to get a CISSP cert, but the resources and education are generally applicable in most situations.
It is astonishing how often people neglect basic programming best practices (input validation, error handling, logging, access control) which in turn leads to security vulnerabilities. My theory is this is caused moreso by Agile Management forcing developers to cut corners, rather than just developers being ignorant/lazy.
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top...
Threat modeling can be a good practice to learn, because it gets you into the habit of thinking about how you could hack each new thing you're developing.
I dont think the CISSP is a good recommendation for this person's case, unless they plan on becoming a cyber security manager.
Also, having a developer understand the value and need for code security from the perspective of a security person is important to the overall success of an infosec program. Otherwise both engineering and infosec are going to be grating on each other.