How to write insecure code - Revision history

Nawwar: "Testing is overrated"

2017-05-15T17:14:30Z

"Testing is overrated"

Myilmaz: /* Authentication */

2017-04-21T19:43:52Z

‎Authentication

Myilmaz: /* HOW TO WRITE INSECURE CODE */

2017-04-21T19:38:04Z

‎HOW TO WRITE INSECURE CODE

Myilmaz: /* Testing */

2017-04-21T19:20:34Z

‎Testing

Myilmaz: /* Authentication */

2017-04-21T19:18:08Z

‎Authentication

Myilmaz: /* Authentication */

2017-04-21T19:16:40Z

‎Authentication

Jeff Williams at 20:46, 12 November 2014

2014-11-12T20:46:03Z

Jeff Williams at 20:40, 12 November 2014

2014-11-12T20:40:25Z

Shady: Introduction

2013-05-12T17:14:50Z

Introduction

Jesse Ruderman at 05:54, 19 June 2011

2011-06-19T05:54:26Z

@@ Line 171: / Line 171: @@
 ==Testing==
+; '''Testing is overrated'''
 ; '''Test with a browser'''
 : All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users.  And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.
@@ Line 200: / Line 201: @@
 ; "Hello, this is an internal application, so security doesn't matter"
-: We have firewalls and stuff      [[Category:How To]]
+: We have firewalls and stuff       [[Category:How To]]
 == DevOps ==

@@ Line 94: / Line 94: @@
 '''Just use a hash'''
-Salt is for pigs.  Its way too much work to salt hashed passwords.  Besides, only the application can get to the database and hashes are one way trap doors, so why would you need it?
+Salt is for pigs.  Its way too much work to salt and hash passwords.  Besides, only the application can get to the database and hashes are one way trap doors, so why would you need it?
 ; '''Sessions are inherently secure'''
 : Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.
@@ Line 200: / Line 200: @@
 ; "Hello, this is an internal application, so security doesn't matter"
-: We have firewalls and stuff     [[Category:How To]]
+: We have firewalls and stuff      [[Category:How To]]
 == DevOps ==

← Older revision		Revision as of 19:38, 21 April 2017
Line 200:		Line 200:

	; "Hello, this is an internal application, so security doesn't matter"		; "Hello, this is an internal application, so security doesn't matter"
−	: We have firewalls and stuff [[Category:How To]]	+	: We have firewalls and stuff [[Category:How To]]
		+
		+	== DevOps ==
		+	'''Automation is enough security'''
		+
		+	Forget about integrity, if we have a problem with a node, all we need to do is kill it and stand another up
		+
		+	'''Automated Scanning'''
		+
		+	It just creates more garbage nobody is going to read anyways
		+
		+	'''Access Control on DevOps systems'''
		+
		+	IAM roles and how keys are managed don't matter much, we can just check them right into GitHub and it'll be lost in a world of anonymity. Hell, we can even put all our code there so we can just pull it from anywhere.
		+
		+	'''Static Analysis'''
		+
		+	See automated scanning
		+
		+	'''Dynamic Analysis'''
		+
		+	See automated scanning
		+
		+	'''Dependency checking'''
		+
		+	No one would ever think to put a payload in a library, and hey, the signature on libraries are probably always there.
		+
		+	'''Auditing is a waste of money'''
		+
		+	There is no reason to check actual configurations written when we are using playbooks and configuration automation the tell us a node started out with a good configuration. Why would it ever change? Also see Automation is enough security
		+
		+	'''We'll never lose control of our nodes'''
		+
		+	Let's just write that root key down on paper and share it with the team. Nobody would ever leak it and create a botnet on our dollar.
		+
		+	'''CORS'''
		+
		+	The cloud is all about sharing! Let's CORS * everything!
		+
		+	'''Logging Services'''
		+
		+	We're using other peoples infrastructure anyways, why bother with logs or alerts? It's just a waste of time

@@ Line 174: / Line 174: @@
 ; '''Test with a browser'''
 : All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users.  And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.
 ; '''Build test code into every module'''
 : You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.
@@ Line 198: / Line 200: @@
 ; "Hello, this is an internal application, so security doesn't matter"
-: We have firewalls and stuff   [[Category:How To]]
+: We have firewalls and stuff    [[Category:How To]]

@@ Line 94: / Line 94: @@
 '''Just use a hash'''
-Salt is for pigs.  Its way too much work to salt hashed passwords.  Besides, only the application can get to the database and hashes or one way trap doors, so why would you need it?
+Salt is for pigs.  Its way too much work to salt hashed passwords.  Besides, only the application can get to the database and hashes are one way trap doors, so why would you need it?
 ; '''Sessions are inherently secure'''
 : Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.
@@ Line 198: / Line 198: @@
 ; "Hello, this is an internal application, so security doesn't matter"
-: We have firewalls and stuff  [[Category:How To]]
+: We have firewalls and stuff   [[Category:How To]]

@@ Line 1: / Line 1: @@
-==Add to this Article==
+__NOTOC__
-Help us out and add your favorite ways to discourage secure coding below.
+=HOW TO WRITE INSECURE CODE=
 ==Introduction==
@@ Line 57: / Line 57: @@
 : Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.
-; '''Share the love'''
+; '''Code wants to be free!'''
 : Drop your source code into repositories that are accessible by all within the company.  This also prevents having to email those hard-coded shared secrets around.
 ==Logging==
@@ Line 96: / Line 93: @@
 : Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.
-; '''Sessions are inherantly secure'''
+; '''Sessions are inherently secure'''
 : Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.
@@ Line 124: / Line 121: @@
 ==Policy==
 ; '''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.
@@ Line 129: / Line 127: @@
 ; '''The tool knows how to do it'''
-: Let your authentication technology dictate your authorization requirements.
+: Let your automated tools dictate your security requirements. Tailoring is for suckers.
 ==Input Validation==
@@ Line 174: / Line 172: @@
 ; '''Test with a browser'''
 : All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users.  And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.
 ; '''Build test code into every module'''

@@ Line 91: / Line 91: @@
 : 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==
+==Authentication==
 ; '''Build your own authentication scheme'''
@@ Line 104: / Line 103: @@
 : A one-way hash cannot be decrypted.  Therefore, this is a way to take the latter approach and make it unbreakable.
-===Authorization===
+==Authorization==
 ; '''Forget about it'''
@@ Line 124: / Line 123: @@
 : When a service you are calling, for example, has inappropriate access controls just be nice and live with it.  After all it will be your fault when a direct object reference permits any user of your system to see any data on their service.  Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.
-===Policy===
+==Policy==
 ; '''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.
@@ Line 190: / Line 189: @@
 : Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.
-==Jedi Mind Tricks==
+; '''Don't worry about using the latest version of components'''
-; '''Defensive Insecurity: Always be ready with a good offense.'''
+: Just because a library has known vulnerabilities doesn't mean it's not safe to use. If there's no proof that *my* application is vulnerable then you're just wasting my time.
-===You're too important===
+==Culture==
-* Don't you know who I am?
-===They are not important===
+; "I got a security approval"
-* Who are you to question this?
+: So what if it was several years ago, it's basically the same code anyway.
-===You know important people===
-* I was having a beer with Joe Topexec yesterday, and he really wants to see this project online.
+; "Security has to *prove* it before I do anything"
-===Too late===
+: So what if you exploited my application, you cheated by using hacking
-* This has to be released tomorrow night at 10 PM.  We have SLAs to satisfy.
-===Vague references===
+; "Hello, this is an internal application, so security doesn't matter"
-* We got approval from the security team over a year ago on this.
+: We have firewalls and stuff
 [[Category:How To]]

@@ Line 7: / Line 7: @@
 In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.
-The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.segfault.net/root/phun/unmaintain.html one page version more readable].[[category:FIXME|broken link]] Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.
+The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.org/root/phun/unmaintain.html one page version more readable]. Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.
 ''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''

@@ Line 208: / Line 208: @@
 * This has been done this way for 5 years so why does it matter now?
 * Everyone else does it this way, why are you making me deal with it?
 ===Magical thinking===
 * It's internal network only, so security doesn't matter.