Did you know that Gorisco is also into development and maintenance of special applications? This includes both web and mobile applications.
So, today we decided to write about the secure coding practices, which we recommend being followed in order to enhance the experience and confidence of the customers and end users.
Why is a secure coding practice important?
Unsafe coding practices result in costly vulnerabilities in application software that leads to the theft of sensitive data.
Secure coding standards are important because they help to ensure that software is safeguarded against software security vulnerabilities
The aim of the secure coding standard is to not only detect security risks with rules but also provide suggestions that can improve code quality with recommendations.
The scope of the secure coding standard is a whole program coding standard and the goal is to produce safe, reliable, and secure systems.
Let’s look at some of best Secure Coding Practices
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.
2. Heed compiler warnings
Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code [C MSC00-A, C++ MSC00-A]. Use static and dynamic analysis tools to detect and eliminate additional security flaws.
3. Normalize strings before validating them
Many applications that accept untrusted input strings employ input filtering and validation mechanisms based on the strings' character data. For example, an application's strategy for avoiding cross-site scripting (XSS) vulnerabilities may include forbidding <script> tags in inputs. Such blacklisting mechanisms are a useful part of a security strategy, even though they are insufficient for complete input validation and sanitization.
4. Keep it simple
Keep the design 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. Prevent XML Injection
The extensible mark-up language (XML) is designed to help store, structure, and transfer data. Because of its platform independence, flexibility, and relative simplicity, XML has found use in a wide range of applications. However, because of its versatility, XML is vulnerable to a wide spectrum of attacks, including XML injection.
A user who has the ability to provide input string data that is incorporated into an XML document can inject XML tags. These tags are interpreted by the XML parser and may cause data to be overridden.
6. Limit accessibility of fields
Invariants cannot be enforced for public nonfinal fields or for final fields that reference a mutable object. A protected member of an exported class represents a public commitment to an implementation detail. Attackers can manipulate such fields to violate class invariants, or they may be corrupted by multiple threads accessing them concurrently [Bloch 2008]. As a result, fields must be declared private or package-private.
7. Do not suppress or ignore checked exceptions
Programmers often suppress checked exceptions by catching exceptions with an empty or trivial catch block. Each catch block must ensure that the program continues only with valid invariants. Consequently, the catch block must either recover from the exceptional condition, rethrow the exception to allow the next nearest enclosing catch clause of a try statement to recover, or throw an exception that is appropriate to the context of the catch block.
8. Secure Database Design and access
As you all know the database is one of the most critical part of any application, which holds entire data of the application in one place. Sometimes, due to insecure coding, attackers can easily view the data that one should not be allowed to and can manipulate the entire data which leads to delivering false information to the real users and worst, attackers can also deliver malicious attacks through the database.
9. Do not serialize unencrypted sensitive data
Although serialization allows an object's state to be saved as a sequence of bytes and then reconstituted at a later time, it provides no mechanism to protect the serialized data. An attacker who gains access to the serialized data can use it to discover sensitive information and to determine implementation details of the objects. An attacker can also modify the serialized data in an attempt to compromise the system when the malicious data is deserialized. Consequently, sensitive data that is serialized is potentially exposed, without regard to the access qualifiers (such as the private keyword) that were used in the original code. Moreover, the security manager cannot guarantee the integrity of the deserialized data.
10. Use SSLSocket rather than Socket for secure data exchange
Programs must use the javax.net.ssl.SSLSocket class rather than the java.net.Socket class when transferring sensitive data over insecure communication channels. The class SSLSocket provides security protocols such as Secure Sockets Layer/Transport Layer Security (SSL/TLS) to ensure that the channel is not vulnerable to eavesdropping and malicious tampering.
All security vulnerabilities are the result of a human error. All web application security issues are introduced by developers. Therefore, the best approach to building secure software is to do all that is possible to avoid introducing such errors in the first place instead of fixing them.
In conclusion, we would like you to realize that the security policies, while necessary, are not enough if they are perceived as a limitation, not an enhancement. Security begins with the right attitude when building applications. And even the best tools used to maintain security must be used in the correct way in the process so that they are perceived as helpful, not as a burden.
About CERT
The CERT is the coordination center of the computer emergency response team (CERT) for the Software Engineering Institute (SEI), a non-profit United States federally funded research and development center. The CERT/CC researches software bugs that impact software and internet security, publishes research and information on its findings, and works with business and government to improve security of software and the internet as a whole.
CERT is a secure coding standard that supports commonly used programming languages such as C, C++, and Java. In addition, for each guideline included in the secure coding standard, there is a risk assessment to help determine the possible consequences of violating that specific rule or recommendation.
The CERT Program partners with government, industry, law enforcement, and academia to develop advanced methods and technologies to counter large-scale, sophisticated cyber threats.
The CERT/CC works directly with software vendors in the private sector as well as government agencies to address software vulnerabilities and provide fixes to the public. This process is known as coordination.
References
SecureIca(Infosec Daily). (n.d.). Importance of Secure Coding with it’s best practices.(Infosec Daily).
SEI CERT Standard Coding. (n.d.). SEI CERT Coding Standards.
Tomasz Andrzej Nidecki. (n.d.). Secure Coding Practices – The Three Key Principles.