Secure Coding Practices for OWASP Top 10 Vulnerabilities

Security is a core element of software products. If you are a software developer or the head of product engineering teams, you cannot ignore the importance of security measures in application development. In this blog, we bring you the new observations in the field of security and software products and the best security measures and practices for the Top 10 Vulnerabilities as stated by the Open Web Application Security Project (OWASP).

 

The following are OWASP Top 10 Vulnerabilities:

1. Injection
2. Broken Authentication
3. Exposure to Sensitive Data
4. XML External Entities
5. Broken Access Control
6. Security Misconfiguration
7. Insecure Deserialization
8. Insufficient Logging and Monitoring
9. Cross Site Scripting
10. Using Components with Known Vulnerabilities

 

Injection:

The most common type of vulnerability is any kind of injection flaw. These flaws are often found in SQL, XPath, NoSQL, LDAP, and other programming languages. During code review, the code can be looked at to find these holes. Static code readers make it easy to find these kinds of flaws in the code.

 

Best security measures for injection:

• For SQL searches, use prepared statements or parameterized query statements, or use Object Relational Mapping tools. Even parameterized queries can lead to SQL injection if the data is added straight to the query.
• Use server-side input validation with a filter to check for special characters.
• Use specific escape syntax for leftover dynamic queries and escape special characters.
• Use LIMIT or other special SQL controls in searches to stop a lot of records from being shown at once.

 

Broken Authentication

This kind of vulnerability is common because the Identity and Access module in the program is poorly designed and implemented. Cyber attackers can find login problems by hand or with security tools that have password lists and dictionary attacks.

 

Best security measures for Authentication Problems:

• Use multi-factor identification to stop attacks like brute-force and automated attacks.
• Do not hardcode any default passwords in any case.
• Set up strong rules about the length and difficulty of passwords and how often they should be changed.
• Make sure that the same texts are used for different situations, such as User registration, Invalid Username/Password, and Forgot Password modules, to prevent account enumeration attacks.
• You can stop brute-force attacks by putting a limit on the number of failed login tries. Keep a record of these failed tries and tell the administrator about them.
• Add a way to lock or suspend an account after several failed login tries.
• Use a server-side session manager that makes a new session ID after you log in. Session IDs shouldn't be used in URLs, should be kept safely, and should be invalidated when a user logs out or waits too long.

 

Exposure to Sensitive Data In the last few years, the most common attack has been letting sensitive info out into the open. Most of the time, this kind of vulnerability happens because private data in the application development is not encrypted. This kind of flaw can still happen if the user used a weak key generation method, a weak algorithm or protocol, or a weak way to store hashed passwords. So, these server-side flaws are easy for an attacker to spot when data is in transit.

 

Best security measures for Exposure to Sensitive Data:

• Find and label private data and get rid of it if it's not needed.
• Make sure that strong algorithms, protocols, and good key management have been used to encrypt all private data that needs to be stored.
• Use safe protocols like SSL/TLS to encrypt all data while it is in transit.
• Turn off caching for a response that has secret information in it.

 

XML External Entities (XXE)

There are connections to external entities in a lot of badly set up XMLs. URI handler, internal port scanning, remote code execution, and denial of service attacks are all ways that external organizations can find out about internal files.

 

Best security measures for XML External Entities:

• Use data forms like JSON that are easier to understand.
• Avoid serialization of sensitive info.
• Update all of the application's XML processors.
• Turn off XML external entity processing and DTD processing in all of the application's XML parsers.
• Use whitelisting for input checking on the server to stop malicious data from getting into XML.
• Use static scanning to look for these kinds of flaws in the source code.

 

Broken Access Control

This kind of vulnerability happens when it's not easy for authorized users to access features, screens, and functions. Attackers can use these holes to get to functions and/or data that they shouldn't be able to. These include being able to access the accounts of other users, view private files, change the data of other users, change access rights, and so on. You can't use automatic static or dynamic analysis to find these kinds of flaws. The best way to find this kind of weakness is to test it by hand.

 

Best security measures for Broken Access Control:

• Put in place a neat way to control access and use it throughout the program.
• Make sure that all requests go through checks for access control. Record every time access control is used.
• Use the "Deny by Default" strategy for accounts that have just been made until access is set up. When a new feature is added to an app, all users should not be able to use it until it is set up correctly.
• Use the Least Privilege principle.
• Don't set the jobs in stone.

 

Security Misconfiguration

Misconfigured HTTP headers, insecure default setups, and incomplete security configuration are the most common causes of security misconfiguration. Using automated scanners, these wrong setups are easy to find.

 

Best security measures for Security Misconfiguration:

• Test, review, and check the network infrastructure, server configurations, HTTP header settings, and cloud storage permissions.
• Add identical security configurations in all environments. To set up a secure setting, this process should be automated so that people don't make as many mistakes.
• A better way to do things is to use segmented program architecture.

 

Cross-Site Scripting (XSS) When an application takes a value from an HTTP request (user-supplied data) and then uses the same value in the immediate response without proper validation, this is called an XSS vulnerability. With this attack, scripts can be run in a browser to take over sessions or send people to hostile sites.

 

Best security measures for Cross-Site Scripting:

• Use security tools that are built to automatically avoid XSS, such as Ruby, React JS, etc.
• Hide or encrypt data from the user that you don't trust in the HTML result.
• Add a content-security policy to the return header so that inline JavaScript won't run in the browser.

 

Insecure Deserialization

This kind of flaw could allow code to be run from afar. Attacks like replay, injection, and permission escalation can be done with this.

 

Best security measures for Insecure Deserialization:

• Check the consistency of every object that has been serialized.
• Make sure there are tight type constraints when deserializing.
• Write down all errors and failures when deserializing.
• Don't let services that deserialize connect to the private network.

 

Using Components with Known Vulnerabilities

Components such as libraries, frameworks are themselves vulnerable. They could be dangerous for application development as it enables various attacks and impacts. If an attack takes advantage of a weak part, a lot of data could be lost or the computer could be taken over.

 

Best security measures for Components with Known Vulnerabilities

• Don't keep any dependencies, tools, files, or components that aren't being used.
• Track client-side, server-side component versions for security vulnerabilities and patches.
• Get components, libraries only from trusted and official sources.

 

Insufficient Logging and Monitoring

This could make it easier for attackers to do more damage to the systems, change the data, steal it, or destroy it. This lack of logging will lead to problems, such as security breaches being found by outside parties instead of internal tracking.

 

Best security measures for Insufficient Logging and Monitoring:

• Make sure that all types of failures, validations, user contexts, and security checks are logged, so that any bad behavior can be found.
• Make sure that all logs are in a certain style that log management tools can easily read.
• Set up effective ways to watch for suspicious actions and let people know about them.