Secure Coding Guidelines

Hello Readers, In my previous blog we saw the different types of Secure Coding Standards. Continue to that, in this blog we will see how we can overcome the vulnerabilities by following the below Secure Coding guidelines.

What are Secure Coding guidelines?

1. Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command-line arguments, network interfaces, environmental variables, and user-controlled files. For example, it should be validated on the client-in Web Application development side if you take input from the user. It should be validated on the client-side. Like if it is a string, check for the length of the string, for integer check using the hasNextInt() method.
2. Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code. Use static and dynamic analysis tools to detect and eliminate additional security flaws. Compilers emit both errors, which prevent your code from compiling at all, and warnings, which indicate a potential problem but still let your code compile.
3. Architect and design security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set.
4. Keep it simple. Your software design should be as simple and small as possible. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex.
5. Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied, and the protection scheme identifies conditions under which access is permitted.
6. Adhere to the principle of least privilege. Every process should execute with the least set of privileges necessary to complete the job. Any elevated permission should only be accessed for the least amount of time required to complete the privileged task. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges.
7. Sanitize data sent to other systems. Sanitize all data passed to complex subsystems such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem. For Example, Data Masking OR Data Encryption.
8. Practice defense in depth. Manage risk with multiple defensive strategies so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment.
9. Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated into an effective quality assurance program. Independent security reviews can lead to more secure systems. For example, in identifying and correcting invalid assumptions.
10. Define security requirements. Identify and document security requirements early in the development life cycle and ensure that subsequent development artifacts are evaluated for compliance with those requirements. When security requirements are not defined, the security of the resulting system cannot be effectively evaluated.
11. Model threats. Use threat modeling to anticipate the threats to which the software will be subjected. Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies implemented in designs, code, and test cases.

By following the above Secure Coding practices we can we can overcome the vulnerabilities.

Thanks, Deepak Naik for your guidance and review.

References

https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices

https://www.perforce.com/blog/qac/secure-coding-standards