Lately, security has been a hot button issue in regards to China’s open databases and Facebook’s numerous data leaks. The problems of security is something more and more developers are going to have to come to grips with. If you’re an aspiring developer, knowing basic security protocols can give you a leg up during the interview process. By grilling the hiring manager, you can position yourself as responsible developer. Knowledge of security also helps freelancers who can their her client’s trust by making their knowledge of security practices apparent.
- Trust no one. Especially yourself.
- The only perfectly secure system is one that’s been disconnected, powered off, encased in concrete, and dropped into the ocean from a helicopter flown blindfolded.
- Any functionality you can use is functionality someone else with ulterior motives can use. Data you can access through your system is data someone else can access through your system. Backdoors are an inherent security risk.
- Assume user input is malicious until proven otherwise.
- If you’re good enough to roll your own crypto, you already have a job working specifically on crypto.
- If you only need to test whether input matches something you’ve stored (like passwords), hash, don’t encrypt.
- Bind prepared statements, don’t interpolate parameters into queries.
- If you have a publicly-visible API backing your site, remember that your site isn’t the only thing that can hit it.
- Think about and test edge cases.
A big part of my role as Chief Defender Against the Dark Arts at 1Password is helping our very talented development team to build secure code. I have the good fortune of working with people who are highly motivated to do things securely, but they have not necessarily been specifically trained how to. Here are a few broad and narrow lessons in no particular order off of the top of my head.
- Developers need (to be pointed to) the right tools to do things right. It is not enough to say “don’t do X, do Y instead” if you don’t give them the tools to do Y. So when some security expert tells you not to do X, ask them for the tools to do better.
- Instead of addressing specific attacks (as they come up or we can imagine them), it is better to build things in ways to preclude whole categories of attack.
- Ad-hoc regular expressions are rarely the right way to validate input (and all input may be hostile). But (see point 1), we need tools to build safe parsers for input.
- Expanding on the previous point: That stuff that you learned and promptly forgot in your Formal Language Theory or Automata Theory class turns out to be really important for securely handling potentially hostile input.
- Have as few user secrets as possible. (This is an example of 2).
- And users should have as much control as possible over determining what is “secret”.
- Using good cryptographic libraries is essential, but they are very very easy to use incorrectly. Have someone who knows about cryptography to review your use. You may have to pay them.
- Many exploits involve chaining together little, seemingly, harmless bugs. Just because you can’t think of how some issue could be practically exploited doesn’t mean that someone won’t figure it out some day. (This is a variant of 2, but it is worth restating this way.)
- Use debuggers, not printf, to study intermediate values. This prevents accidentally logging things that shouldn’t be logged.
- Heed IDE/compiler warnings. Run static and run-time analytics. Remember, many memory addressing errors can be turned into exploits.
The less data you store, the fewer security hazards you expose yourself to, and the safer your participants will be. Don’t hoard data on the theory that it’ll become useful – only save what you need, and question yourself every time you get into a situation where you think you need it.
If you must store data, especially sensitive data, don’t ever store it in plain-text! Look into hashing algorithms like bcrypt.
Always give your participants the option to delete their data, and actually delete it when they ask you to.
API Keys are just as sensitive as a username and password combination!
- Don’t expose them in publicly accessible repositories or source code.
- Do configure them as server environment variables in a contained environment.
I’d add: never even commit a credential (password/API key/etc) to your repo. I’d argue this applies to any repo, not just open source ones, since you never know what might happen to the repo in the future. Even if you remove the credential in a future commit, it still exists in the history.
The OWASP top ten security vulnerability documents are a great place to start: OWASP. Typically, the top web app security vulnerabilities are SQL injection, XSS and authentication issues. The top web frameworks will address those issues in their documentation so that is another place to begin researching.
Keeping up to date on the best security practices is possible if you can use resources as a sort of guide. Here are some resources that were mentioned in this article, including others.