OWASP Proactive Controls: list of mandatory requirements for software developers

We bring to your attention Top 10 Proactive Controls for Software developers - 10 security aspects that software developers should focus on. This article contains a list of security techniques that are required for the implementation of each new project.

Insufficiently protected software undermines the security of critical infrastructure, such as health, defense, energy or finance. Our global digital infrastructure becomes more complex, the number of interconnections between its components increases, so the importance of ensuring application security increases exponentially. Relatively simple security threats can no longer be overlooked.

Owasp

The Open Web Application Security Project (OWASP) is an open source web application security project. The OWASP community includes corporations, educational organizations and individuals from around the world. OWASP is working to create publicly available articles, tutorials, documentation, tools, and technologies.

The OWASP project is referenced by many standards, tools, and organizations, including MITER, PCI DSS, DISA, FTC, and many others.

The “Proactive Defense: OWASP Top-10 Requirements” project is similar to the OWASP Top-10 project , but it focuses on methods and recommendations for protecting against threats, and not on the threats themselves. Each method and recommendation in this document is associated with one or more threats from the OWASP Top-10 list.

Targets and goals

The goal of the project “Proactive Defense: Top 10 OWASP Requirements” is to draw attention to application security by considering the most important aspects of information security that software developers should take into account. We encourage organizations to take advantage of OWASP's proactive protection recommendations and to teach developers to pay attention to application security, emphasizing errors that have occurred in other organizations. We hope that the recommendations of OWASP will be useful for you when creating secure applications.

The target audience

The document is intended primarily for developers. However, it will also be useful to development managers, product managers, quality assurance specialists, project managers, and other participants in the software development process.

Top 10 Proactive Defense Requirements

C1: Defining Security Requirements

Security requirements describe the functions that must be implemented to ensure certain software security settings. They are based on industry standards, current laws, and vulnerability data. The requirements identify the functions that need to be developed or refined to solve specific security problems or eliminate potential threats.

The OWASP Application Security Validation Standard (ASVS) is a directory of available security requirements and verification options. OWASP ASVS can serve as a source of advanced security requirements for development teams.

Security requirements are grouped into categories based on higher-level general security functions. For example, ASVS contains the following categories: authentication, access control, error handling and logging, and web services. For each category there is a list of parameters that are recommended to check.

The process of successful application of security requirements includes four stages: search and selection, documentation, implementation, confirmation of the correctness of the implementation of new security functions and application functionality.

C2: Using secure frameworks and libraries

Secure libraries and frameworks with built-in security features help developers avoid vulnerabilities during the design and implementation phases. Developers who create an application from scratch may not have enough knowledge, time, or means to implement or maintain the security of the application. Using secure frameworks allows you to increase the level of application security.

When including third-party libraries or frameworks in your software, you should consider the following recommendations:

use libraries and frameworks from trusted sources that are being actively developed and widely used in applications;
compile and maintain up to date the catalog of all third-party libraries;
timely update libraries and components. Use tools, such as OWASP and Retire.JS Dependency Checks , to identify dependencies in projects, and also check for known and published vulnerabilities in third-party code;
To reduce the likelihood of attacks, use library encapsulation and only the necessary functionality for your software.

C3: Ensuring secure access to databases

This section is dedicated to ensuring secure access to all data stores, including relational databases and NoSQL databases.

One of the most serious threats to application security is SQL injection. This type of attack is easy to implement: SQL can be injected if untrusted input is dynamically added to SQL queries, which is usually done by attaching it to the main row. Exploiting this vulnerability could lead to theft, deletion or modification of databases. The application can also be used to execute malicious commands in the system containing your database, which will allow an attacker to gain a foothold in the network.

To prevent SQL implementations, it is necessary to avoid interpreting unverified input as part of SQL commands. The best solution would be to use the "query parameterization" method. This method must be applied to SQL and OQL constructs, as well as stored procedures.

Examples of query parameterization for ASP, ColdFusion, C #, Delphi, .NET, Go, Java, Perl, PHP, PL / SQL, PostgreSQL, Python, R, Ruby and Scheme can be found at http://bobby-tables.com and in the OWASP request parameterization memo .

C4: Data Encoding and Shielding

Coding and shielding are methods of protection against code injection. Encoding, also called “output encoding,” is a transformation of special characters into equivalent, non-dangerous for the interpreter, combinations. For example, the <character is converted to the <combination when it is added to an HTML page. Escaping is to add special characters in front of characters or lines to prevent them from being interpreted incorrectly, for example, adding the character \ before "(double quotes) allows you to interpret them as part of the text, and not as a symbol for the end of a line.

Encoding is best applied just before transferring data to the interpreter. If this method is applied at a too early stage of processing a request, then encoding or screening may affect the use of content in other parts of the program. For example, if HTML content is shielded before the database is saved, and the interface automatically shields this data again, the content will not be displayed correctly due to double shielding.

Encoding or screening can be used to prevent other forms of embedding in content. For example, you can neutralize some special metacharacters when entering data for system commands. This is called OS shielding, shell shielding, and so on. Such protection can be used to prevent “command injection”.

There are other forms of escaping that can be used to prevent implementations, for example, escaping XML attributes, protecting against various forms of XML implementations and XML paths, as well as escaping unique LDAP names to prevent various LDAP implementations.

C5: Mandatory verification of all input data

Validation of input data is part of a programming methodology that ensures that only properly formatted data gets into program components.

Syntactic and semantic norm

The application should check the data for compliance with the syntactic and semantic norms (in that order) before using them (including mapping to the user).

The syntactic norm means that the data corresponds to the expected form of representation For example, in an application, a user may specify a four-digit “identifier” to perform certain operations. An attacker can enter data that allows him to inject the SQL code, so the application must verify that the entered data are exactly digits and in the amount of four characters (in addition to using the appropriate query parameterization).

The semantic norm means using only input data that is not beyond a certain functionality and context. For example, when specifying a time frame, the start date must precede the end date.

White and black lists

There are two main approaches to checking the syntax of input data - checking for black and white lists.

The first method is designed to search in the data "potentially harmful" content. For example, a web application might block input containing the word SCRIPT in order to prevent cross-site scripting. However, this protection measure can be circumvented by using lower case letters or a combination of lowercase and uppercase letters for the script tag.

The second method is intended to confirm the compliance of the data with the requirements of a set of “verified” rules. For example, checking the US state on the white list will be a search for a 2-letter code in the list of existing US states.

At least it is recommended to use whitelists when creating secure software. Blacklists can contain errors, they can be circumvented in various ways, and in themselves they can be dangerous. Although it is possible to bypass the limitations of blacklists, they can be useful in detecting obvious attacks. Thus, whitelists help limit the possibility of an attack by checking that the data is syntactic and semantic, while blacklists help detect and prevent obvious attacks.

Client and server side checks

For security, input validation should always be carried out on the server side. Client side checks can be useful in terms of functionality and security, but often they are easy to get around. Therefore, server-side checking is preferable for security. For example, a JavaScript validation can warn a user that the field should contain only numbers, but the server-side application must confirm that the input data are numbers in the allowable range of values.

C6: The introduction of digital identification

Digital identification is a unique representation of the user (or any other object) in online transactions. Authentication is the process of confirming that a person or entity is who they appear to be. Session management is the process by which the server monitors the state of user authentication so that it can continue to use the system without re-authentication. The NIST Special Edition 800-63B : Digital Identification Guide (Authentication and Lifecycle Management) provides detailed guidelines for implementing the requirements for digital identification, authentication, and session management.

C7: Mandatory Access Control

Access control (or authorization) is to allow or deny specific requests from users, programs or processes, and also involves the issuance and revocation of such privileges.

It should be noted that authorization (confirmation of the right of access to special functions or resources) does not equal authentication (confirmation of identity).

Access control typically affects many aspects of software operation, depending on the complexity of the access control system. For example, access control metadata management or caching for scalability purposes are usually additional components of an access control system that need to be created or maintained. There are several different approaches to access control:

Selective Access Control (DAC) - involves restricting access to objects (for example, files or data elements) based on an identifier, as well as the principle of "necessary knowledge" of subjects (for example, users or processes) and / or groups to which the objects belong;
Mandatory Access Control (MAC) - implies restricting access to system resources based on the data criticality (defined by tags) contained in these resources and the formal authority (that is, access) of users to access information of specified importance;
role-based access control model (RBAC) - involves the control of access to resources based on the roles that determine the permitted actions with resources, and not based on the identifiers of subjects;
Attribute-Based Access Control (ABAC) - involves allowing or disallowing user requests based on user attributes and object attributes, as well as environmental elements that can be defined globally and be more relevant to the policies applied.

C8: Pervasive Data Protection

Confidential data such as passwords, credit card numbers, medical records, personal data and trade secrets require additional protection, especially if they are subject to the data privacy law, such as the EU General Data Protection Regulation (GDPR), or the protection law financial data, such as the Payment Card Data Security Standard (PCI DSS).

Attackers can steal data from web applications and web services in many different ways. For example, an attacker can connect to a shared wireless network and view or steal other people's confidential data if it is transmitted over an insecure Internet connection. Also, an attacker can use SQL injection to steal passwords and other credentials from applications, and then put them in open access.

Data classification

It is necessary to classify the data in your system and determine what level of criticality each data block belongs to. Each data category can then be correlated with protection rules defined for each severity level. For example, public marketing information that is not confidential may be related to publicly available data that can be posted on a publicly accessible website. Credit card numbers can be attributed to the personal data of users who require encryption when they are stored or transferred.

Encryption of transmitted data

When transmitting sensitive data over any network, end-to-end connection protection (or encryption) must be applied. TLS is unconditionally the most common and supported cryptographic protocol that provides connection security. It is used in many areas (web applications, web services, mobile applications) for secure data transmission over the network. To ensure the security of TLS connections, you must be properly configured.

The main benefit of the TLS protocol is to protect web application data from unauthorized access and changes when they are transferred between clients (web browsers) and the web application server, as well as between the web application server and the internal server or other non-browser-based ones. , components of the organization.

Encryption of stored data

The first rule for managing sensitive data is to avoid storing sensitive data when possible. If you need to keep confidential data necessary, make sure that they have cryptographic protection against unauthorized access and changes.

Cryptography is one of the most advanced areas of information security, its understanding requires extensive knowledge and experience. It is difficult to choose any one single solution, since there are many different approaches to encryption, and each of them has its advantages and disadvantages, which web architects and web developers must clearly understand. Moreover, serious cryptographic research is usually based on higher mathematics and number theory, which creates a high input threshold.

C9: Implementing Security Event Logging and Monitoring

Most developers already use logging for debugging and diagnostics. It is also important to register security events (data related to security) while the application is running. Monitoring is a “live” analysis of an application and security logs using various automation tools. The same tools and patterns can be applied to operations, debugging, and security.

The benefits of security event logging

Security event logs can be used for:

supplying an attack detection system with data;
analysis and investigation of incidents;
compliance with regulatory requirements.

Implementing Security Event Logging

The following are recommendations for implementing security event logging.

Use standard forms and methods for recording events in the system and between the systems of your organization. An example of a standard event logging platform is Apache Logging Services (Apache Logging Services), which provide logging compatibility between Java, PHP, .NET, and C ++ applications.
Do not log too much or too little data. For example, be sure to register time stamps and identification data, such as the source IP address and user ID, but never record personal or sensitive data.
Pay particular attention to time synchronization between nodes to ensure consistency of timestamps.

Logging to detect and counter attacks

Use logging to determine the activity that indicates the malicious nature of user actions. Potentially dangerous activity to register:

input data is outside the expected numeric range;
the input data modifies components that must remain unchanged (selection list, checkbox fields, other components with limited input);
requests that violate server side access control rules;
A more detailed list of attack markers can be found here .

When an application detects such an activity, it should at least register this event and mark it as dangerous. Ideally, the application should counteract the attack, for example, by canceling the user's session and blocking his account. The countermeasure mechanism allows the program to respond to detectable attacks in real time.

C10: Mandatory handling of all errors and exceptions

Exception handling allows an application to respond to various errors (for example, a network failure or a database connection) in various ways. Proper handling of exceptions and errors is simply necessary to ensure the reliability and security of your code.

Errors and exceptions are handled at all levels of the application, including critical business logic, security features, and frameworks.

Error handling is also important in terms of attack detection. Some attacks on applications can cause errors that can detect an attack during its execution.

Incorrect error handling

Researchers at the University of Toronto found that even a small mistake in handling errors or ignoring them can lead to critical disruptions in the operation of distributed systems .

Incorrect error handling can cause various vulnerabilities.

Data leakage. Disclosing confidential information in error messages can inadvertently help attackers. For example, a message containing a stack trace or details of an internal error could provide an attacker with information about your environment. Even small differences in error handling (for example, a message about entering an incorrect username or incorrect password with an authentication error) can be a source of important information for an attacker. As described above, it is necessary to provide detailed error logging for investigations and debugging, but at the same time avoid disclosing this data, especially to external clients.
TLS security bypass. Apple’s “goto fail” vulnerability was the result of a management error in error handling code that completely compromised Apple’s TLS connections.
Denial of service. Lack of basic error handling can lead to system malfunction. This is usually a relatively easy-to-use vulnerability. Other problems with error handling can lead to increased utilization of CPU or disk resources and thus degrade system performance.

Useful tips

Manage exceptions centrally to avoid duplication of try / catch locks in your code. Ensure the correct handling of unexpected operating modes within the application.
Make sure that the displayed error messages do not contain critical data, but at the same time contain enough information to respond to them appropriately.
Provide exception logging so that experts from the technical support team, quality control, incident investigation, or attack response have enough data to solve the problem.
Test and verify your error code carefully.

Conclusion

This document should be considered as a starting point, not as an exhaustive set of methods and practices. We once again want to note that the presented materials are intended to familiarize with the basics of developing secure software.

When creating an application security program, we recommend the following steps:

familiarize yourself with the OWASP Top 10 and OWASP Top 10 (mobile devices) to understand the risks associated with web application security;
according to the requirement number 1 of proactive protection, included in the program to ensure the safe development of a detailed list on the basis of safety requirements for standards such as Standard safety confirmation OWASP Web Application (ASVS) and confirm the safety standards of mobile applications OWASP (MASVS) ;
familiarize yourself with the provisions of OWASP OpenSAMM for a more general understanding of the key blocks for creating secure software.

Full version of the translation and the original . In the translation and adaptation took part: JZDLin , Alexey Skachkov , Ivan Kochurkin and Taras Ivashchenko .

This document was released under the Creative Commons Attribution ShareAlike 3.0 license, translated and adapted with the participation of the Russian branch of the OWASP consortium .

Tags:

OWASP Proactive Controls