Difference between revisions of "How to write insecure code"

Jump to: navigation, search
Line 135: Line 135:
; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise.  Optimize the development by keeping the developers from having to read.
; '''Security is just another option'''
; '''Security is just another option'''

Revision as of 15:41, 5 February 2010

Add to this Article






General Principles

Avoid the tools
Always use default deny


Distribute security mechanisms
Spread the wealth
Use dynamic code

Secure Languages

Type safety
Means anything you enter at the keyboard is secure.
Secure languages
Mix languages

Trust Relationships

Rely on security checks done elsewhere
Trust insiders
Share the love


Use your logs for debugging
Don't use a logging framework


Build your own encryption scheme
Hard-code your keys
Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.
Smart coders don't read manuals
Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };
Pack up your sensitive payload
If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.
Encryption is hard
A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.
HTTPS makes your application bullet proof
If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

Access Control


Build your own authentication scheme
Sessions are inherantly secure
Single Sign-On is easy
If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.


Forget about it
See Authentication. Only ivory tower knuckleheads think there's a difference between authentication and authorization.
Just let your authorization scheme evolve
Privilege makes code just work
Optimize the developer... always
Each developer, independent of one another, must decide where authorization decision and enforcement is made.
Trust the client
RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.


Forget about it
Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
See Authentication. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.
The tool knows how to do it
Let your authentication technology dictate your authorization requirements.

Input Validation

Validation is for suckers
Let developers validate their way
Trust the client
If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.


Security is just another option
Don't document how security works
Freedom to innovate
Print is dead


Most APIs are safe
Don't use security patterns
Make sure the build process has lots of steps


Test with a browser
Don't use static analysis tools
Build test code into every module
Security warnings are all false alarms


Use lots of precompiled libraries