Secure Coding Techniques 3.6

Question 1

Secure Coding Concepts

Answer 1

Balance time and quality. Security isn’t always at the forefront of developer priorities. Vulnerabilities will eventually be found.

Question 2

Error and Exception Handling

Answer 2

Bad guys love if your error message reveal too much information. Do not use the default error messages. It will give away too much information.

Question 3

Input Validation

Answer 3

Make sure that all of your input fields are only allowing exactly what’s necessary. If you allow too much leeway, the bad guys will do everything they can to find an opening. Document all input methods and make sure your application is only receiving the input that its expecting. Use a fuzzer to check if your app is properly validating the information.

Question 4

Stored Procedure

Answer 4

For SQL the clients send detailed requests for data from a particular part of the database. These requests can be complex. If the user malicious modifies the request, they can gain information they shouldn’t have access to. To combat that, use a pre-designed stored procedure. This eliminates creative uses of the SQL programs.

Question 5

Code Signing

Answer 5

After an app is deployed, users run the app or scripts. In order for us to tell if the application is legitimately from who designed it, the code can be digitally signed by the developer. It uses asymmetric encryption. Trusted certificate authorities sign the developers public key and the developer signs with their private key. For internal applications, use our own CA.

Question 6

Encryption

Answer 6

If you can see the source code, you can find security holes. Source code is closely guarded. Development platforms should use encryption.

Question 7

Obfuscation/Camoflage

Answer 7

Take readable code and make it look like nonsense. It helps prevent the search for security holes.

Question 8

Code Reuse/Dead Code

Answer 8

Using old code that has vulnerabilities just creates more problems for everyone. Dead code can potentially create security problems. The less code for the program, the less potential risk.

Question 9

Validation Points

Answer 9

Use both server side and client side validation.

Question 10

Memory Management

Answer 10

Never trust user data input. Buffer overflows are a huge security risk. Make sure the data that comes in matches your available buffer sizes.

Question 11

Third Party Libraries and Software Development Kits (SDK’s)

Answer 11

Programming languages does a large amount of how applications are developed. Sometimes you need third party libraries to help your app do something it needs to do. These libraries can be a risk however because it was written by someone else. Do extensive testing on it.

Question 12

Data Exposure

Answer 12

There is so much sensitive data. How is your app handling all this data. You need to think about every step in which this data is handled to include its input and output processes.