# Top 10 flaws

## Bugs vs Flaws

A bug is an implementation-level software problem. Bugs may exist in code but never be executed.A flaw, by contrast, is a problem at a deeper level. Flaws are often much more subtle than simply an offby-one error in an array reference or use of an incorrect system call. A flaw might be instantiated in software code, but it is the result of a mistake or oversight at the design level.For example, a number of classic flaws exist in error-handling and recovery
systems that fail in an insecure or inefficient fashion.

## EARN OR GIVE, BUT NEVER ASSUME, TRUST

Software systems comprising more than just a single monolithic component rely on the composition and cooperation of two or more software tiers or components to successfully accomplish their purpose. These designs often depend on the correct functioning of the existing parts.

## 1 Make sure all data received from an untrusted client are properly validated before processing.

Offloading security functions from server to client exposes those functions to a much less trustworthy environment, which is one of the most common causes of security failures predicated on misplaced trust.

Designs that place authorization, access control, enforcement of security policy, or embedded sensitive data in client software thinking that it won’t be discovered, modified, or exposed by clever users or malicious attackers are inherently weak. Such designs will often lead to compromises.

If, nonetheless, security operations must be offloaded
to components running on an untrusted platform, the design should impose extreme caution on how the computation and its output are treated.

A designer might incorrectly) assume that server APIs will always be called in the same order every time. He or she might believe that the user interface is always able to restrict what the user is able to send to the server

For example, some organizations will claim a real business need to store intellectual property or other sensitive material on the client. The first consideration is to confirm that sensitive material really does need to be stored on the client. When it truly is necessary to do so, various binary protection mechanisms can delay the leaking of sensitive material. Possible techniques to consider include obfuscation or anti-debugging

If IP or sensitive material must be stored or sent to the client, the system should be designed to be able to cope with potential compromise. For instance, the same shared secret or other cryptographic material shouldn’t be used on all the clients. Make the validity of what is offloaded to the client limited in time, set expiration dates for data stored in the client, watermark IP, and double-check client computations that are security sensitive

## 2 USE AN AUTHENTICATION MECHANISM THAT CANNOT BE BYPASSED OR TAMPERED WITH

Authentication is the act of validating an entity’s identity. One goal of a secure design is to prevent an entity (user, attacker, or in general a “principal”) from gaining access to a system or service without first authenticating. Once a user has been authenticated, a securely designed system should also prevent that user from changing identity without re-authentication.

**Multi-fator Authentication**

Authentication via a cookie stored on a browser client may be sufficient for some resources; stronger forms of authentication (e.g., a two-factor method) should be used for more sensitive functions, such as resetting a password.

**Use strong hash function to hash passwords then compare the two hashes** to ensure the confidentiality
of data

The ability to bypass an authentication mechanism
can result in an unauthorized entity
having access to a system or service that it
shouldn’t. For example, a system that has an authentication mechanism, but allows a user to access the service by navigating directly to an “obscure” URL (such as a URL that is not directly linked to in a user interface, or that is simply otherwise “unknown” because a developer has not widely published it) within the service without also requiring an authentication credential, is vulnerable to authentication bypass

**Protected Routes** not just hide

Even when IP addresses are tied to particular devices, authentication based on device addresses is not a substitute for user authentication, as IP addresses can be spoofed and are not necessarily associated with specific users for a long time

Credentials must not be easy to forge. Upon successful authentication, the user may be provided with an authentication credential, token, or ticket, which can be provided back to the system so that the user does not need to be re-authenticated for every request or transaction made via the system. At the same time, if it is possible for an attacker to forge the authentication credential, token, or ticket, the attacker can bypass the authentication mechanism

System designers can reuse time-tested authentication
mechanisms such as Kerberos instead of building a new one. Alternatively, system designers are encouraged to use cryptography correctly

## Kerberos / OAuth2

advantages

disadvantages

[disadvantages](https://www.techtarget.com/searchsecurity/definition/Kerberos)

If an authentication system does not limit the lifetime of an authentication interaction, then it may inadvertently grant access to a user to whom it should not. For example, imagine a user who logs into a public terminal and then walks away without logging out (which should terminate
the session). A second user using the public terminal might now be able to use the system or service as the first user

maybe short time refresh token

Just as it is advisable to reuse tried and tested cryptographic algorithms, it is also advisable to re-use already built and tested password management systems instead of building new ones.

It’s preferable to have a single method, component, or system responsible for authenticating users. Such a single mechanism can serve as a logical “choke point” that cannot be bypassed.

## 3 AUTHORIZE AFTER YOU AUTHENTICATE

knowing the user’s identity may not be sufficient before deciding to allow or disallow the user to perform certain actions

**Not everyone should have admin privileges**

Sometimes a user’s authorization for a system or service needs to be revoked, for example, when an employee leaves a company. If the authorization mechanism fails to allow for such revocation, the system is vulnerable to abuse by authenticated users exercising out-of-date authorizations.

For particularly sensitive operations, authorization may need to invoke authentication. Although authorization begins only after authentication has occurred, this requirement is not circular

Hence authorization of a specially sensitive operation (for example, transferring a sum of money larger than a designated threshhold) may require a re-authentication or
a higher level of authentication.
**(re-authentication)rerequire the password when changing permissions for users**

## 4 STRICTLY SEPARATE DATA AND CONTROL INSTRUCTIONS, AND NEVER PROCESS CONTROL INSTRUCTIONS RECEIVED FROM UNTRUSTED SOURCES

Co-mingling data and control instructions in a single entity, especially a string, can lead to injection vulnerabilities

“At lower layers, lack of strict segregation between data and control instructions can manifest itself in memory-corruption vulnerabilities, which in turn may permit attacker-controlled modifications of control flow or direct execution of attacker-controlled data as machine or bytecode instructions.”

In many languages, control instructions and data are often
segregated using in-band syntactic constructs, such as quoting and escaping. If software assembles
a string in a parseable language by combining untrusted data with trusted control instructions, injection vulnerabilities arise if the untrusted data are insufficiently validated or escaped

**validate untrusted data**
**validate email and password for user**

Examples of such vulnerabilities include SQL query injection, cross-site JavaScript injection, and shell command injection.

At lower levels, software platforms can utilize hardware capabilities to enforce separation of code and data. For example, memory access permissions can be used to mark memory that contains only data as non-executable and to mark memory where code is stored as executable, but immutable, at runtime. Modern operating systems take advantage of such hardware features to implement security mechanisms that harden the entire software stack against multiple forms of attack

**Check that they use modern OS that supports that **

When designing languages, compilers, virtual machines, parsers and related pieces of infrastructure, consider control-flow integrity and segregation of control and potentially untrusted data as important design goals.

**Never use eval function**

Eval. Many interpreted languages (such as Python, Ruby, and JavaScript) have an eval function that consumes a string consisting of syntax in that language and invokes the language’s interpreter on the string

## 5 DEFINE AN APPROACH THAT ENSURES ALL DATA ARE EXPLICITLY VALIDATED

Software systems and components commonly make assumptions about data they operate on. It is important to explicitly ensure that such assumptions hold: vulnerabilities frequently arise from implicit assumptions about data, which can be exploited if an attacker can subvert and invalidate these assumptions. As such, it is important to design software systems to ensure that comprehensive data validation actually takes place and that all assumptions about data have been validated when they are used.

Design or use centralized validation mechanisms to ensure that all data entering a system (from the outside) or major component (from another component of the same system) are appropriately validated. For example:

It is desirable for web applications to utilize a mechanism (such as a request filter or interceptor facility provided by the underlying web application framework) to centrally intercept all incoming requests, and to apply basic input validation to all request parameters.

**use middleware in Express to validate parameters for every request with params**

Use common libraries of validation primitives, such as predicates that recognize well-formed email addresses, URLs, and so forth.

**use isEmail lib**

**Validation should be based on a whitelisting approach, rather than blacklisting.**

**Explicitly re-validate assumptions “nearby” code that relies on them**

**XSS**
If an externally controlled string is used in a context in a HTML document where it will be interpreted as a URL, a Cross-Site Scripting (XSS) vulnerability can arise unless it has been validated that the string represents a well-formed URL with a benign scheme (such as http:/https:, nd,in particular, not javascript:,vbscript:, data:, or others).

**Use character encoding**

**validate data before saving in DB** to avoid injection vulnerabilities

## 6 USE CRYPTOGRAPHY CORRECTLY

Standard algorithms and libraries are preferable.

Misuse of libraries and algorithms. Even when using strong libraries, do not assume that just using the libraries will be sufficient. There have been numerous instances
in which standard libraries were used, but the developers using the libraries made incorrect assumptions about how to use the library routines. In other situations,
developers don’t choose the right algorithm or use the algorithm incorrectly. For example, an encryption scheme may protect the confidentiality of data, but may not protect against malicious modifications to the data.

**Understanding the nuances of algorithm and library usage is a core skill for applied cryptographers**

**Poor key management. When everything else is done correctly, the security of the cryptographic system still hinges on the protection of the cryptographic keys**


**Randomness that is not random.**

**Failure to centralize cryptography.** Best practices indicate getting it “right” once and reusing the component elsewhere.

## 7 IDENTIFY SENSITIVE DATA AND HOW THEY SHOULD BE HANDLED

Data are critical to organizations and to users. One of the first tasks that systems designers must do is identify sensitive data and determine how to protect it appropriately.

**GDPR**


Not all data protection requirements are the

Technical data sensitivity controls that a designer might consider include **access control** mechanisms

## 8 ALWAYS CONSIDER THE USERS

The security stance of a software system is inextricably linked to what its users do with it.

**limit access for users that are not admins**


Failure to consider the many different classes
of users (blind users, language proficiency,
children, people with different mental capabilities, etc.) will exclude those classes of users from the software -- or, alternatively, make the software too difficult to use effectively.


**make the default secure**


By fully considering all the relevant stakeholders, designers have the opportunity to create systems that are both secure and usable.

## 9 UNDERSTAND HOW INTEGRATING EXTERNAL COMPONENTS CHANGES YOUR ATTACK SURFACE

The important distinction is that the software being newly included has actually been tried as well as tested and found to stand up to your current standards of software security

**if you are including an external crypto library, understand what values are used by default unless you change them; for example, sources of entropy, algorithms, and key lengths.**

## 10 BE FLEXIBLE WHEN CONSIDERING FUTURE CHANGES TO OBJECTS AND ACTORS

**It is a different proposition to maintain security for a system with 10 users than 10 million users —not at all a simple matter of linear scale**

**Consider that the numbers of employees and users will increase**

Design for secure updates. It is easier to upgrade small pieces of a system than huge blobs. Doing so ensures that the security implications of the upgrade are well understood and controlled