I continue the look at 5 more of the Top 25 Most Dangerous Programming Errors. Here's part 1 (25-21)
20. Download of Code Without Integrity Check
You might not think of this at first, but it's a doozy. If you are downloading things, like files, code, updates, whatever, they could be compromised. DNS poisoning or redirects could make your request for a file go to a different location. There could be a man in the middle messing with your data, or the download could just be corrupt.
Regardless, if anything happens along the way, it could wreak havoc on your running application.
Ways around it
The obvious way around this is checking the integrity of downloaded packages with a SHA1 or other secure hash algorithm. The non-obvious extra protection is doing proper DNS checks (forward and reverse) on your network requests (as per the CWE prevention techniques). A third way (again, by the CWE), is to actually encrypt (using an encryption algorithm like AES) your downloaded content.
Doing all three is not that much work when you think about it. Checking
a hash is an extra method call and an extra if statement to confirm
the hash. Doing the DNS lookups is a small method. Doing the full
decryption isn't that bad either, as most encryption algorithms have
nice APIs for whatever language you are working in.
The point is: don't just download stuff and execute it. It's not cool.
19. Missing Authentication for Critical Function
This one is a little more tricky. You can't just add some code in a few spots to make this happen. All of the CWE recommendations are architecture related, in that you have to think about them before you go and write a bunch of code.
Ways around it
The latter two points the CWE makes regarding mitigation are more obvious.
- Duplicate client side security checks on the sever side. Duh. Don't ever rely on just client side authentication. If you authenticate solely on the client side, it's sending a message to the server at some point saying that everything is all good. If the client has full control over this message, an attacker pretty much owns your system. Have fun with that.
- Avoid custom authentication systems. If you are using a framework that provides authentication, use it. If you can't, but the operating system provides features you can leverage, use them.
The first point they make is a little more interesting, and harder to implement. If you have a C library, for example, and you only expose so much in your header file, it doesn't really matter. There are ways to see what functions are defined and you can create your own header file to expose those functions to your program. If they don't require authentication…
Same thing with web applications. Assume you have your authentication page A, and a secure page B. If you can navigate to page B manually, and it assumes you came from A so you must be authenticated, then your application needs work.
18. Incorrect Calculation of Buffer Size
This error occurs in languages where you need to explicitly allocate a certain amount of memory. C, C++, Java, C# all require you, in certain cases, to make a decision about how much memory to allocate. Ruby arrays, as an example, can expand dynamically, as well as some types in C# and Java. Know your datatypes!
If you allocate a certain amount of memory, but then try to read more
data into that block of memory than it can hold, hilarity chaos
ensues.
Bad: