The Fundamentals of Security Every Developer Should Understand

Last week I made this thread:

What are some fundamentals of security every developer should understand?

Ben Halpern ・ Mar 24 '18

#discuss #security

I want to share with you some of the great answers. There is a ton of wisdom here, so read on.

Dian Fay • Mar 24 '18

1. Trust no one. Especially yourself.
2. 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.
3. 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.
4. Assume user input is malicious until proven otherwise.
5. If you're good enough to roll your own crypto, you already have a job working specifically on crypto.
6. If you only need to test whether input matches something you've stored (like passwords), hash, don't encrypt.
7. Bind prepared statements, don't interpolate parameters into queries.
8. If you have a publicly-visible API backing your site, remember that your site isn't the only thing that can hit it.
9. Think about and test edge cases.

Adnan Rahić • Mar 24 '18

1. Validate input data!
2. Seriously, validate input data.
3. Did I mention validating input data?

Donald Merand • Mar 24 '18

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.

edA‑qa mort‑ora‑y • Mar 24 '18

• Security is hard. It's worthwhile to read about various attacks to understand the magnitude of ways in which stuff is attacked.
• Your system will be breached. Mitigation strategy is as important as the "wall".
• A system is never "secure", you can only balance security goals with current risks and available resources.
• Privacy is inseparable from security. Even if you're irresponsible and don't care about your users, the attackers will.
• Security becomes harder as the data becomes more valuable. Most systems are really only secure because nobody really wants the data they store. As a company becomes successful, the attackers will come.
• Security is a moving target. You are are never done implementing security.
• User security is as important as corporate security.
• Being open about security is the only way to know it's correct. There is no security through obscurity.
• Everybody is responsible for security. Every person and every machine is a potential attack vector.

Practical advice:

• Use existing libraries
• Follow best practices
• Keep everything up-to-date
• Be open and ask questions
• Code defensively
• Be aware of risks

Alexandre Plennevaux • Mar 26 '18

Whenever you process data from the outside, always process it in this order:

1. Sanitize
2. Validate
3. Execute
4. Display feedback

Example:

$errors = array();

// 1. Sanitisation
$email = filter_var($_POST['email'], FILTER_SANITIZE_EMAIL);

// 2. Validation
if (false === filter_var($email, FILTER_VALIDATE_EMAIL)) {
   $errors['email'] =  "Invalid email address";
}

// 3. Exécution
if (count($errors)> 0){
    echo 'There are errors : ';
    print_r($errors);
    exit;
}
// At this point, all is fine, let's open the gate...
$bdd = new PDO('mysql:host=localhost;dbname=test', 'root', '');
//...

// 4. Feedback information

Speaking of fundamentals...

Four Security Principles That Software Developers Should Follow

Rob Waller ・ Feb 22 '18

#security #privacy

I hope this was helpful. There are a lot of specific rules we can follow in terms of security, but starting from principle is key. And we can never assume that everyone already knows and grasps the fundamentals. Go forth and secure your software!

Comments

[Ben Halpern]

Of course, thanks to all the dev.to folks that chime in on these kinds of threads. This kind of willing wisdom sharing is such a big part of what makes the dev.to community special. 😇

[Jody Dott]

Regarding prepared statements. Look into what your driver does with them.
Some drivers just concatenate the strings (no protection at all), others do a sanitised concatenation, the best send it to the server to compile and then send the parameters to the server in separate calls (best).

Know what your driver does! Don't assume.

(Also don't rely on this mechanism.. CHECK YOUR INPUTS!)

[Michael O'Brien]

These are great. Here is my 2-cents to add to your list:

This has some good overlap with your items and a few others to add:

Web Developer Security Checklist: dev.to/powerdowncloud/web-develope...

[T.s]

Would be a good to point out essential maturity of security development.

• Level 1 would be developing security awareness.
• Level 2 would be developing security by default.
• Level 3 would be developing security by design.
• Level 4 would be developing defensive security in code.

[Patrick O'Dacre]

Thanks for posting this. I learned a lot, and the Darkwing Duck image just about triples the credibility of the advice here.

[Beatriz]

What are your thoughts about access-controlled documentation and restricting libraries with known vulnerabilities (CVEs)?

[Dolores Greatamsky]

4. Assume user input is malicious until proven otherwise.

Corollary: You cannot prove a negative as in "not malicious".

[1214586]

thanks

[Kresna Satya]

The secure apps or Web is no code. Seriously: github.com/kelseyhightower/nocode