

Top 10 Secure Coding Practices - gongfudoi
http://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

======
wallflower
"The only system which is truly secure is one which is switched off and
unplugged, locked in a titanium lined safe, buried in a concrete bunker, and
is surrounded by nerve gas and very highly paid armed guards. Even then, I
wouldn't stake my life on it."

(the original version of this is attributed to Gene Spafford)

~~~
hoffmabc
Sounds like an Austin Powers movie.

------
tptacek
I'm going to point out that in practice, #8 ( _Practice Defense in Depth_ )
rarely works.

The reason is simple: it's Hard to bulletproof any one security control, and
the cost of getting controls even slightly wrong is the same as not doing it
at all.

It can be tricky to come up with an example of a system that met a real-world
security requirement only because a stack of security controls held together
despite breaks the individual controls. Windows XP SP2 is a famous anti-
example. Secure runtime: good! Security development lifecycle: better! Memory
corruption vulnerability: often still game-over!

For assessors of applications (I'm one), the words "defense in depth" are
usually blood in the water. It's code for, "we made a bunch of assumptions
here, but that's OK because use modsecurity".

~~~
derefr
I've never understood "defense in depth" to be in the context of a single
application. Rather, an entire _network_ will have "defense in depth" if it
has such things as a firewall with proper rules at every gateway, machines
with proper virus protection that aren't running silly services, and users
with proper responsibility to not run things sent to them via e-mail.

In that context, if a supposed "hacker" wants to gain access to files on
machine X, they may be able to penetrate gateway A, router B and firewall C,
but they still will be blocked by NIDS D or end up in honeypot E.

~~~
tptacek
The cold, hard truth is: "defense in depth" really means, "don't do anything
wrong".

------
mk
Unfortunately something as simple as input validation often does not occur. It
baffles me when I look over at code from contract work or I come into a new
job and see GET requests modifying the database, and POST's going completely
unchecked. Madness!

~~~
henning
what bothers me most about the PHP community is that it's taken for granted
that you should have to do all that yourself from scratch every time.

~~~
noodle
i think that any php developer who uses any substantial framework would
disagree with you.

~~~
henning
most PHP developers don't use frameworks. there have been no "substantial
frameworks" for nearly all of PHP's history, and the attitude among common
users is that PHP isn't responsible for helping you out with security.

it doesn't help that coding style in nearly every PHP book I've seen is
insecure and unmaintainable.

------
graywh
I'm surprised there aren't any good comments about the photo.

------
nickb
0) Use a dynamic language with garbage collection.

~~~
johnm
Are you kidding or referring to a specific such language? I.e., PHP is
arguably the most popular such language on the server and it's also the most
insecure.

~~~
tlrobinson
It's even easier to shoot yourself in the foot with compiled languages like C
or C++ (strcpy, etc are especially dangerous)

~~~
johnm
Easier to create problems than in PHP? Naw, just different.

------
hoffmabc
I think that #4 - "Keep it simple" is such a key part of creating secure
applications. I think that as software is modified and grows and expands and
more people touch the source we add in complexity that often blows away the
security of the software. We need to make sure that we consistently apply our
security conscious programming skills throughout the entire project.

