Merge pull request #6 from matreurai/Dev-01

Added to various TASVS categories

document/1.0/02-Frontispiece.md

@@ -19,6 +19,7 @@ John is a distinguished security architect at Bentley Systems with many years of
 
 - Einaras Bartkus
 - Thomas Chauchefoin
+- Samuel Aubert
 
 
 ## Special Thanks

document/1.0/03-Using_the_TASVS.md

@@ -29,8 +29,9 @@ The standard is divided into various groups labelled `TASVS-{word}` that represe
 - TASVS-CODE-4 - Client Side - Validation, Sanitization and Encoding
 - TASVS-CODE-5 - Client Side - Business Logic
 - TASVS-CODE-6 - Client Side - Fuzzing
-- TASVS-CODE-7 - Client Side - Privilege and Rule of two
+- TASVS-CODE-7 - Client Side - Secure Coding Practices
 - TASVS-CONF-1 - General Configuration Checks
+- TASVS-CONF-2 - Privileges and Permissions
 - TASVS-CRYPTO-1 - Communication
 - TASVS-CRYPTO-2 - Storage
 - TASVS-CRYPTO-3 - General

document/1.0/05-TASVS-CODE.md

@@ -47,9 +47,9 @@ To ensure that the application's source code is developed and maintained in a ma
 | TASVS-CODE-6    | Client Side - Fuzzing.                                                                                                                                                                                                                                                                          |    |    |    |
 | TASVS-CODE-6.1  | Perform "dumb fuzzing" of the application with randomised input to try to cause a crash.                                                                                                                                                                                                       | X  | X  | X  |
 | TASVS-CODE-6.2  | Perform "smart fuzzing". Intelligently generate test cases that maximize code coverage and explore complex program states to increasing the likelihood of finding vulnerabilities over "dumb fuzzing".                                                                                         |    |    | X  |
-| TASVS-CODE-7    | Client Side - Privilege and Rule of two.                                                                                                                                                                                                                                                        |    |    |    |
-| TASVS-CODE-7.1  | Ensure that the software follows the principle of least privileges and runs with the lowest level of privileges for it to work as expected. If several levels of privileges are required, their IPC interfaces are well-defined and do not expose more features than required.                 | X  | X  | X  |
-| TASVS-CODE-7.2  | The thick client follows the "Rule of 2", where it cannot have more than 2 of: works with untrustworthy inputs, is written in memory unsafe language, runs with high privileges / without a sandbox.                                                                                           | X  | X  | X  |
+| TASVS-CODE-7    | Client Side - Secure Coding
+Practices.                                                                                                                                                                                                                                                             |    |    |    |
+| TASVS-CODE-7.1  | Ensure that fully qualified paths are specified when calling/loading executables or DLL files to prevent the OS from searching in other directories that could contain malicious files or for files in the wrong location and help prevents Dynamic Link Libraries (DLL) and EXE Hijacking attacks.                                                                         | X  | X  | X  |
 
 ## Control Group Definitions
 
@@ -571,23 +571,24 @@ Performing "smart fuzzing" of the thick client can help to identify security vul
 
 One way to do this is to use a fuzzer like [AFL]() or [libFuzzer]() with custom test case generation strategies, such as harnesses or mutators. These tools can automatically generate test cases and run them against the thick client to identify security vulnerabilities.
 
-### *TASVS-CODE-7 - Client Side - Privilege and Rule of two*
 
-### TASVS-CODE-7.1 - Ensure that the software follows the principle of least privileges and runs with the lowest level of privileges for it to work as expected. If several levels of privileges are required, their IPC interfaces are well-defined and do not expose more features than required.
+### *TASVS-CODE-7 - Client Side - Secure Coding Practices*
 
-The thick client should follow the principle of least privileges and run with the lowest level of privileges required for it to work as expected. If several levels of privileges are required, their IPC interfaces should be well-defined and not expose more features than required. This can help to prevent attackers from exploiting privilege escalation vulnerabilities to compromise the thick client.
+### TASVS-CODE-7.1 - Ensure that fully qualified paths are specified when calling/loading executables or DLL files to prevent the OS from searching in other directories that could contain malicious files or for files in the wrong location and help prevents Dynamic Link Libraries (DLL) and EXE Hijacking attacks.
 
-For example, if the thick client runs with elevated privileges, an attacker could exploit a vulnerability in the thick client to gain access to sensitive information or execute arbitrary code. By running the thick client with the lowest level of privileges required for it to work as expected, the attack surface is reduced and the risk of privilege escalation vulnerabilities is minimized.
+DLL Hijacking is an attack technique that consists of tricking an application into loading an altered DLL file. Under normal operation, when an application depends on a DLL file, it loads it into memory. However, a malicious actor can take advantage of this process by injecting malicious code into the DLL file. As a result, the application unknowingly executes the malicious code, altering its behavior. EXE Hijacking is the same idea, but for EXEs calls on runtime.
 
+For example, if the program is running with elevated privileges, DLL Hijacking may lead to privilege escalation. DLL hijacking can also be used to evade anti-malware detection, by leveraging a legitimate, whitelisted application to load a malicious DLL. Furthermore, since many applications load DLL files during startup, the attacker can gain access each time the system boots. Therefore, ensuring persistence.
+
+Example:
+```c
+LoadLibrary("example.dll"); // Unsafe, instead use:
+LoadLibrary("C:\\Program Files\\MyApp\\example.dll"); // Safer
+```
 
-### TASVS-CODE-7.2 - The thick client follows the "Rule of 2", where it cannot have more than 2 of: works with untrustworthy inputs, is written in memory unsafe language, runs with high privileges / without a sandbox.
 
-The thick client should follow the "Rule of 2", where it cannot have more than 2 of the following characteristics:
+### TASVS-CODE-7.2 - Ensure that safe file operations, such as when creating or opening files, are used to prevent Symlinks attacks.
 
-- Works with untrustworthy inputs
-- Is written in a memory-unsafe language
-- Runs with high privileges or without a sandbox
 
-This can help to prevent attackers from exploiting security vulnerabilities in the thick client. For example, if the thick client works with untrustworthy inputs and is written in a memory-unsafe language, an attacker could exploit memory vulnerabilities to execute arbitrary code. By following the "Rule of 2", the thick client can reduce the risk of security vulnerabilities and protect sensitive information from unauthorized access.
 
 \newpage{}

document/1.0/06-TASVS-CONF.md

@@ -18,6 +18,10 @@ This control objective helps mitigate security vulnerabilities, ensures complian
 | TASVS-CONF-1.4 | Verify that all unneeded features, documentation, sample applications and configurations are removed.                                                                                                                                                                              | X  | X  | X  |
 | TASVS-CONF-1.5 | Verify that third party components come from pre-defined, trusted and continually maintained repositories.                                                                                                                                                                         | X  | X  | X  |
 | TASVS-CONF-1.6 | Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use.                                                                                                                                                                                 | X  | X  | X  |
+| TASVS-CONF-2    | Privileges and Permissions.                                                                                                                                                                                                                                                        |    |    |    |
+| TASVS-CONF-2.1  | Ensure that the software follows the principle of least privileges and runs with the lowest level of privileges for it to work as expected. If several levels of privileges are required, their IPC interfaces are well-defined and do not expose more features than required.                 | X  | X  | X  |
+| TASVS-CONF-2.2  | The thick client follows the "Rule of 2", where it cannot have more than 2 of: works with untrustworthy inputs, is written in memory unsafe language, runs with high privileges / without a sandbox.                                                                                           | X  | X  | X  |
+| TASVS-CONF-2.3  | Permissions are properly configured on all folders opened, deleted, modified or created during the installation process, upon using a feature (e.g. Logs created locally on demand) and at runtime.                                                                                           | X  | X  | X  |
 
 
 ## Control Group Definitions
@@ -49,4 +53,47 @@ Third-party components should come from pre-defined, trusted, and continually ma
 A Software Bill of Materials (SBOM) should be maintained of all third-party libraries in use. An SBOM provides a detailed inventory of all software components used in the application, including third-party libraries, frameworks, and runtimes. This helps track dependencies, identify vulnerabilities, and ensure compliance with licensing requirements.
 
 
+### *TASVS-CONF-2 - Privileges and Permissions*
+
+### TASVS-CONF-2.1 - Ensure that the software follows the principle of least privileges and runs with the lowest level of privileges for it to work as expected. If several levels of privileges are required, their IPC interfaces are well-defined and do not expose more features than required.
+
+The thick client should follow the principle of least privileges and run with the lowest level of privileges required for it to work as expected. If several levels of privileges are required, their IPC interfaces should be well-defined and not expose more features than required. This can help to prevent attackers from exploiting privilege escalation vulnerabilities to compromise the thick client.
+
+For example, if the thick client runs with elevated privileges, an attacker could exploit a vulnerability in the thick client to gain access to sensitive information or execute arbitrary code. By running the thick client with the lowest level of privileges required for it to work as expected, the attack surface is reduced and the risk of privilege escalation vulnerabilities is minimized.
+
+
+### TASVS-CONF-2.2 - The thick client follows the "Rule of 2", where it cannot have more than 2 of: works with untrustworthy inputs, is written in memory unsafe language, runs with high privileges / without a sandbox.
+
+The thick client should follow the "Rule of 2", where it cannot have more than 2 of the following characteristics:
+
+- Works with untrustworthy inputs
+- Is written in a memory-unsafe language
+- Runs with high privileges or without a sandbox
+
+This can help to prevent attackers from exploiting security vulnerabilities in the thick client. For example, if the thick client works with untrustworthy inputs and is written in a memory-unsafe language, an attacker could exploit memory vulnerabilities to execute arbitrary code. By following the "Rule of 2", the thick client can reduce the risk of security vulnerabilities and protect sensitive information from unauthorized access.
+
+
+### TASVS-CONF-2.3 - Permissions are properly configured on all folders opened, deleted, modified or created during the installation process, upon using a feature (e.g. Logs created locally on demand) and at runtime.
+
+The thick client should restrict permissions on all folders created during its installation and at runtime to reduce the risks of Symlinks attacks and other persistence or privilege escalation scenarios.
+
+Processes may automatically execute specific binaries as part of their functionality or to perform other actions. If the permissions on the file system directory containing a target binary, or permissions on the binary itself, are improperly set, then the target binary may be overwritten with another binary using user-level permissions and executed by the original process. If the original process and thread are running under a higher permissions level, then the replaced binary will also execute under higher-level permissions, which could include SYSTEM.
+
+Adversaries may use this technique to replace legitimate binaries with malicious ones as a means of executing code at a higher permissions level. If the executing process is set to run at a specific time or during a certain event (e.g., system bootup) then this technique can also be used for persistence.
+
+When creating or opening files:
+- Check if the file already exists before creating it
+- Depending on the programming language, use flags to prevent following symlinks (e.g. O_NOFOLLOW in Golang)
+- Implement proper error handling
+- Be cautious of race conditions between checking file existence and performing operations. Use atomic operations where possible in order to mitigate risks of Time-of-Check-to-Time-of-Use (TOCTOU) Vulnerabilities.
+
+For example:
+```go
+file, err := os.OpenFile("filename", 
+os.O_RDWR|os.O_CREATE|syscall.O_NOFOLLOW, 0666)
+if err != nil {
+  // Handle error
+}
+```
+
 \newpage{}