diff --git a/document/0.1/04-TASVS-ARCH.md b/document/0.1/04-TASVS-ARCH.md index 23c11d4..2a1f117 100644 --- a/document/0.1/04-TASVS-ARCH.md +++ b/document/0.1/04-TASVS-ARCH.md @@ -4,6 +4,7 @@ Architecture and threat modeling are inextricably linked. Threat modeling informs architectural decisions, while architecture provides the context for identifying and addressing threats systematically. This symbiotic relationship is essential for delivering secure software and systems that meet their intended design goals. + ## Testing Checklist | TASVS-ID | Description | L1 | L2 | L3 | @@ -16,4 +17,46 @@ Architecture and threat modeling are inextricably linked. Threat modeling inform | TASVS-ARCH-1.5 | Threat model checked-in to source code repository. | X | X | X | | TASVS-ARCH-1.6 | Threat model updated regularly as part of a documented process within development team's SSDLC. | | X | X | +## Control Group Definitions + +### TASVS-ARCH-1.1 + +#### What defines "Low Fidelity" Modeling? + +"Low Fidelity" modeling greatly reduces the effort to create an initial threat model. A "Low Fidelity" system model still includes assets, links, and trust boundaries, but with limited attributes. + +Recommended "Low Fidelity" baseline: +- Define data assets with CIA (confidentiality/integrity/availability) +- Define technical assets with technology. +- Define communication links with protocol. +- Place technical assets inside trust boundaries. + +That's it! Later, continue to elaborate the model and raise fidelity score. Remember the system model is a means to an end - identifying threats. + +### TASVS-ARCH-1.2 + +"high fidelity" threat modeling is a more detailed and comprehensive approach to threat modeling. It includes all the elements of a low-fidelity model but adds more detail and context to the model. This includes: + +- Detailed data flow diagrams +- Detailed trust boundaries +- Detailed threat identification + +### TASVS-ARCH-1.3 + +Server-side components and dependencies should be included in the threat modeling process to ensure that all potential threats are identified and addressed. This includes cloud APIs, OIDC providers, file storage, and any other external services that the thick client interacts with. By including these components in the threat model, you can identify potential vulnerabilities and design security controls to mitigate them. + +### TASVS-ARCH-1.4 + +Phases of threat modeling include system modeling, auto-threat identification, manual threat identification, and threat mitigation. Each phase is essential to the overall threat modeling process and should be completed thoroughly to ensure that all potential threats are identified and addressed. + +### TASVS-ARCH-1.5 + +The threat model should be checked into the source code repository to ensure that it is accessible to all members of the development team. This allows team members to review the threat model and provide feedback, as well as track changes to the model over time. + + +### TASVS-ARCH-1.6 + +The threat model should be updated regularly as part of a documented process within the development team's SSDLC. This ensures that the threat model remains current and relevant as the thick client evolves and new threats emerge. Regular updates to the threat model help to ensure that the thick client remains secure and resilient to potential threats. + + \newpage{} \ No newline at end of file diff --git a/document/0.1/05-TASVS-CODE.md b/document/0.1/05-TASVS-CODE.md index d924a30..9904466 100644 --- a/document/0.1/05-TASVS-CODE.md +++ b/document/0.1/05-TASVS-CODE.md @@ -42,7 +42,7 @@ To ensure that the application's source code is developed and maintained in a ma | TASVS-CODE-5.2 | Check for design practices that trick or manipulate users into making choices they would not otherwise have made and that may cause harm. AKA "deceptive patterns". See https://www.deceptive.design/types for examples. | X | X | X | | TASVS-CODE-5.3 | Is the thick client only using workflows that do not violate common security advice? | X | X | X | | TASVS-CODE-5.4 | Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. | X | X | X | -| TASVS-CODE-5.5 | Check that import files cannot be abused in | X | X | X | +| TASVS-CODE-5.5 | Check that import files cannot be abused. | X | X | X | | TASVS-CODE-5.6 | If the thick client registers a URL handler / protocol handler, verify that it can't trigger dangerous action or introduces common vulnerabilities (memory corruption, command and argument injection, etc.) | X | X | X | | 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 | @@ -51,4 +51,530 @@ To ensure that the application's source code is developed and maintained in a ma | 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 | +## Control Group Definitions + +### TASVS-CODE-1.1 + +In an effort to avoid unnecesary cross over between the TASVS and the ASVS, this control is merely a reminder to test the server side components of the thick client using the ASVS. + +### TASVS-CODE-2.1 + +The thick client binary should be signed to ensure that it has not been tampered with. This is especially important for thick clients that are distributed to end users, as it provides a way to verify the authenticity of the software. + +### TASVS-CODE-2.2 + +File integrity checks are used to verify that the files used by the thick client have not been tampered with. This can help to detect unauthorized changes to the software, such as the introduction of malware or other malicious code. + +### TASVS-CODE-2.3 + +Runtime integrity checks are used to verify that the thick client has not been tampered with while it is *running*. This can help to detect attacks that attempt to modify the software's behavior while it is in use. + +### TASVS-CODE-2.4 + +The thick client should be built in release mode with settings appropriate for a release build. This ensures that the software is optimized for performance and security, and that any debugging information or other unnecessary code is removed. + +### TASVS-CODE-2.5 + +Framework security features such as byte-code minification and stack protection should be enabled to help protect the thick client from common security vulnerabilities. These features can help to prevent attacks such as buffer overflows and stack smashing. + +### TASVS-CODE-3.1 + +Third party components used by the thick client, such as libraries and frameworks, should be identified and checked for known vulnerabilities. It is important to ensure that these components are up to date and not unsupported, deprecated, or legacy, as they can introduce security vulnerabilities into the thick client. + +### TASVS-CODE-3.2 + +Exceptions that are thrown and not properly handled can lead to security vulnerabilities in the thick client. It is important to search the source code for cases where exceptions are thrown and not properly handled, as these can allow malicious actions to be performed. + +### TASVS-CODE-3.3 + +# what is binary static analysis? + +Binary static analysis is used to verify that the thick client binaries are compiled with the latest compiler and that the compilation settings are appropriate for security. This can help to identify security vulnerabilities in the thick client that may be introduced during the compilation process. + +Framework specific tools like [dnSpy]() or [ILSpy]() can be used to decompile and analyze .NET binaries. Alternatively, tools like [Ghidra](https://ghidra-sre.org/) or [IDA Pro](https://www.hex-rays.com/products/ida/) can be used to analyze binaries in other languages. + + +### TASVS-CODE-3.4 + +Depending on the language(s) in use, appropriate static application security testing (SAST) tooling should be used to analyze the source code of the thick client. This can help to identify vulnerabilities in the code that may be missed during manual code review. + +Tools such as [SonarQube](https://www.sonarqube.org/), [Checkmarx](https://www.checkmarx.com/), and [Veracode](https://www.veracode.com/) can be used to perform static code analysis on the thick client codebase. Plus framework specific tools like [Brakeman](https://brakemanscanner.org/) for Ruby on Rails, [Bandit](https://bandit.readthedocs.io/en/latest/) for Python, and [FindBugs](http://findbugs.sourceforge.net/) for Java. + +### TASVS-CODE-3.5 + +Internal tooling, policies, and test cases should be implemented and evaluated to ensure that they are working correctly. This can help to ensure that the thick client is developed and maintained in a manner that minimizes the introduction of security vulnerabilities. + +These might include code review processes, automated testing tools, and security training for developers. It is important to regularly review and update these tools and processes to ensure that they are effective in identifying and mitigating security vulnerabilities. + +### TASVS-CODE-3.6 + +Unused code should be identified and removed from the thick client codebase. This can help to reduce the attack surface of the thick client and minimize the risk of security vulnerabilities. It is important to use README and changelog files to preserve high-value historical context or deprecated details. Obsolote project repositories should be archived because they risk being used as a source of vulnerabilities in future projects. + +### TASVS-CODE-4.1 + +Untrusted data should be protected from code and command injection attacks. This can be done by sanitizing or sandboxing user input before it is executed. If there is no alternative to including user input in the thick client, it should be sanitized or sandboxed to prevent code and command injection attacks. + + +### TASVS-CODE-4.2 + +The thick client should protect against OS command injection attacks. This can be done by validating and sanitizing user input before it is executed, and by using secure coding practices to prevent command injection vulnerabilities. + +### TASVS-CODE-4.3 + +Unstructured data should be sanitized to enforce safety measures such as allowed characters and length. This can help to prevent security vulnerabilities that may be introduced by unstructured data, such as buffer overflows or injection attacks. + +### TASVS-CODE-4.4 + +The thick client should restrict XML parsers to use the most restrictive configuration possible to prevent XML eXternal Entity (XXE) attacks. This can help to prevent attackers from exploiting XML parsers to read sensitive data or execute arbitrary code on the thick client. + +### TASVS-CODE-4.5 + +The thick client should use memory-safe string, safer memory copy, and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. This can help to prevent attackers from exploiting memory vulnerabilities to execute arbitrary code on the thick client. + +Safe alternatives to common string functions like `strcpy` and `strcat` should be used to prevent buffer overflows. Memory-safe string functions like `strlcpy` and `strlcat` are available in many programming languages and can help to prevent buffer overflows. + +### TASVS-CODE-4.6 + +Format strings should not take potentially hostile input, and should be constant. This can help to prevent attackers from exploiting format string vulnerabilities to read sensitive data or execute arbitrary code on the thick client. + +An attack might look like this: + +```c +char buffer[100]; +snprintf(buffer, sizeof(buffer), user_input); +``` + +If `user_input` contains a format string specifier like `%s`, an attacker could use it to read sensitive data or execute arbitrary code on the thick client. + +For example if `user_input` is `"%s"`, the `snprintf` function will try to read a string from memory and write it to the buffer. This can lead to a buffer overflow or other memory corruption vulnerability. + +If user_input is `"%x %x %x %x"`, `snprintf` will interpret this as reading four hexadecimal values from the stack, potentially leaking stack contents. + +To mitigate this, the format string should be constant, like this: + +```c +snprintf(buffer, sizeof(buffer), "%s", user_input); +``` + +Notice that the format string is constant i.e. `"%s"` and not `user_input`. + + + +### TASVS-CODE-4.7 + +Sign, range, and input validation techniques should be used to prevent integer overflows. This can help to prevent attackers from exploiting integer overflows to execute arbitrary code on the thick client. + +For exmaple in C/C++: + +```c +int a = 100; +int b = 200; +int c = a + b; +``` + +If `a` and `b` are user-controlled, an attacker could set them to values that cause an integer overflow, resulting in `c` being a negative value. This can lead to unexpected behavior or security vulnerabilities in the thick client. + +To mitigate this, input validation should be used to ensure that `a` and `b` are within a valid range before performing the addition: + +```c +if (a > INT_MAX - b) { + // handle error +} +int c = a + b; +``` + + +### TASVS-CODE-4.8 + +Serialized objects should use integrity checks or be encrypted to prevent hostile object creation or data tampering. This can help to prevent attackers from exploiting serialization vulnerabilities to execute arbitrary code on the thick client. + +For example, if an attacker can modify a serialized object before it is deserialized, they could introduce malicious code or data into the thick client. By using integrity checks or encryption, the thick client can verify that the serialized object has not been tampered with before deserializing it. + +In C# a bad example might look like this: + +```csharp +using System; +using System.IO; +using System.Runtime.Serialization.Formatters.Binary; + +public class Program +{ + public static void Main() + { + // Serialize an object + var obj = new MyClass(); + var formatter = new BinaryFormatter(); + var stream = new MemoryStream(); + formatter.Serialize(stream, obj); + var serialized = stream.ToArray(); + + // Deserialize the object + var deserialized = (MyClass)formatter.Deserialize(new MemoryStream(serialized)); + } +} + +[Serializable] +public class MyClass +{ + public string Name { get; set; } +} +``` + +In this example, an attacker could modify the `serialized` object before it is deserialized, potentially introducing malicious code or data into the thick client. To mitigate this, integrity checks or encryption should be used to verify that the serialized object has not been tampered with before deserializing it. + +A good implementation might look like this: + +```csharp +using System; +using System.IO; +using System.Runtime.Serialization.Formatters.Binary; +using System.Security.Cryptography; + +public class Program +{ + public static void Main() + { + // Serialize an object + var obj = new MyClass(); + var formatter = new BinaryFormatter(); + var stream = new MemoryStream(); + formatter.Serialize(stream, obj); + var serialized = stream.ToArray(); + + // Calculate a hash of the serialized object + var hash = CalculateHash(serialized); + + // Deserialize the object + var deserialized = (MyClass)formatter.Deserialize(new MemoryStream(serialized)); + + // Verify the integrity of the deserialized object + if (!VerifyHash(serialized, hash)) + { + // handle error + } + } + + public static byte[] CalculateHash(byte[] data) + { + using (var sha256 = SHA256.Create()) + { + return sha256.ComputeHash(data); + } + } + + public static bool VerifyHash(byte[] data, byte[] hash) + { + using (var sha256 = SHA256.Create()) + { + var computedHash = sha256.ComputeHash(data); + return StructuralComparisons.StructuralEqualityComparer.Equals(computedHash, hash); + } + } +} + +[Serializable] +public class MyClass +{ + public string Name { get; set; } +} +``` + +In this example, a hash of the serialized object is calculated before it is deserialized, and the hash is verified after deserialization to ensure that the object has not been tampered with. This can help to prevent attackers from exploiting serialization vulnerabilities to execute arbitrary code on the thick client. + + +### TASVS-CODE-4.9 + +Deserialization of untrusted data should be avoided or protected in both custom code and third-party libraries. This can help to prevent attackers from exploiting deserialization vulnerabilities to execute arbitrary code on the thick client. + +For example, if an attacker can control the data that is deserialized by the thick client, they could introduce malicious code or data into the application. By avoiding deserialization of untrusted data or protecting it with integrity checks or encryption, the thick client can verify that the data has not been tampered with before deserializing it. + +It is recommended to use safer libraries where possible and to validate the data before deserializing it. For example, in C# the `DataContractSerializer` class can be used to deserialize JSON data in a safer way than the `BinaryFormatter` class. + +```csharp +using System; +using System.IO; +using System.Runtime.Serialization.Json; + +public class Program +{ + public static void Main() + { + // Deserialize JSON data + var json = "{\"Name\":\"Alice\"}"; + var serializer = new DataContractJsonSerializer(typeof(MyClass)); + var stream = new MemoryStream(System.Text.Encoding.UTF8.GetBytes(json)); + var deserialized = (MyClass)serializer.ReadObject(stream); + } +} + +[DataContract] +public class MyClass +{ + [DataMember] + public string Name { get; set; } +} +``` + +In this example, the `DataContractJsonSerializer` class is used to deserialize JSON data in a safer way than the `BinaryFormatter` class. This can help to prevent attackers from exploiting deserialization vulnerabilities to execute arbitrary code on the thick client. + + +### TASVS-CODE-4.10 + +The thick client's handling of spawning processes should be done securely. This can help to prevent attackers from exploiting process spawning vulnerabilities to execute arbitrary code on the thick client. + +For example, if the thick client spawns a process with user-controlled arguments, an attacker could use this to execute arbitrary code on the thick client. By validating and sanitizing process arguments before spawning a process, the thick client can prevent attackers from exploiting process spawning vulnerabilities. + +In C# a bad example might look like this: + +```csharp +using System; +using System.Diagnostics; + +public class Program +{ + public static void Main() + { + // Spawn a process with user-controlled arguments + var process = new Process(); + process.StartInfo.FileName = "cmd.exe"; + process.StartInfo.Arguments = "/c " + user_input; + process.Start(); + } +} +``` + +In this example, the `user_input` variable is used to construct the arguments for the `cmd.exe` process, potentially allowing an attacker to execute arbitrary code on the thick client. A malicious user could set `user_input` to something like `"; calc.exe;` to execute the Windows Calculator application. To mitigate this, process arguments should be validated and sanitized before spawning a process: + +```csharp +using System; +using System.Diagnostics; + +public class Program +{ + public static void Main() + { + // Validate and sanitize process arguments + if (!IsValid(user_input)) + { + // handle error + } + + // Spawn a process with validated and sanitized arguments + var process = new Process(); + process.StartInfo.FileName = "cmd.exe"; + process.StartInfo.Arguments = "/c " + user_input; + process.Start(); + } + + public static bool IsValid(string input) + { + // Validate and sanitize input + // For example, check for allowed characters and length + allowed = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"; + + if (input.Length > 10 || input.Any(c => !allowed.Contains(c))) + { + return false; + } + + return true; + } +} +``` + +In this example, the `IsValid` function is used to validate and sanitize the `user_input` variable before it is used to construct the arguments for the `cmd.exe` process. This can help to prevent attackers from exploiting process spawning vulnerabilities to execute arbitrary code on the thick client. + +### TASVS-CODE-4.11 + +User-submitted filename metadata should not be used directly by system or framework filesystems to prevent path traversal attacks. This can help to prevent attackers from exploiting path traversal vulnerabilities to read sensitive data or execute arbitrary code on the thick client. + +For example, if the thick client uses user-submitted filenames to access files on the filesystem, an attacker could use this to read sensitive data or execute arbitrary code on the thick client. By validating and sanitizing user-submitted filenames before using them to access files, the thick client can prevent attackers from exploiting path traversal vulnerabilities. + +In C# a bad example might look like this: + +```csharp +using System; +using System.IO; + +public class Program +{ + public static void Main() + { + // Use user-submitted filename to access a file + var filename = user_input; + var path = Path.Combine("C:\\files", filename); + var contents = File.ReadAllText(path); + } +} +``` + +In this example, the `user_input` variable is used to construct the path to a file on the filesystem, potentially allowing an attacker to read sensitive data or execute arbitrary code on the thick client. A malicious user could set `user_input` to something like `..\..\..\Windows\System32\cmd.exe` to execute the Windows Command Prompt application. To mitigate this, user-submitted filenames should be validated and sanitized before using them to access files, in C# Path.GetFullPath can be used to resolve the path and more generally a known good list of paths can be used to validate the input. + +```csharp +using System; +using System.IO; + +public class Program +{ + public static void Main() + { + // Validate and sanitize user-submitted filename + if (!IsValid(user_input)) + { + // handle error + } + + // Use validated and sanitized filename to access a file + var filename = user_input; + var path = Path.Combine("C:\\files", filename); + var contents = File.ReadAllText(path); + } + + public static bool IsValid(string input) + { + // Validate and sanitize input + // For example, check for deny listed characters and defined list of allowed directories + + good-directories = new string[] {"C:\\files", "D:\\data"}; + deny-list = new string[] {"..", "/", "\\"}; + + if (input.Any(c => deny-list.Contains(c)) || !good-directories.Contains(Path.GetDirectoryName(input))) + { + return false; + } + + return true; + } +} +``` + +### TASVS-CODE-4.12 + +Memory should be allocated, freed, and used securely in unmanaged code. This can help to prevent attackers from exploiting memory vulnerabilities to execute arbitrary code on the thick client. + +For example, if memory is not allocated, freed, and used securely in unmanaged code, an attacker could exploit memory vulnerabilities to execute arbitrary code on the thick client. By using secure memory allocation, freeing, and usage practices, the thick client can prevent attackers from exploiting memory vulnerabilities. + +In C/C++ a bad example might look like this: + +```c +#include + +void foo() +{ + // Allocate memory + char* buffer = (char*)malloc(100); + + // Use memory + strcpy(buffer, "Hello, world!"); + + // Free memory + free(buffer); +} +``` + +In this example, the `buffer` variable is allocated, used, and freed in an insecure way, potentially allowing an attacker to exploit memory vulnerabilities to execute arbitrary code on the thick client. To mitigate this, memory should be allocated, used, and freed securely: + +```c +#include + +void foo() +{ + // Allocate memory + char* buffer = (char*)malloc(100); + + // Check for allocation failure + if (buffer == NULL) + { + // handle error + } + + // Use memory + strncpy(buffer, "Hello, world!", 100); + + // Free memory + free(buffer); +} +``` + +In this example, the `buffer` variable is allocated, used, and freed securely, with checks for allocation failure and bounds checking to prevent memory vulnerabilities. This can help to prevent attackers from exploiting memory vulnerabilities to execute arbitrary code on the thick client. + +### TASVS-CODE-5.1 + +If passwords or pins are displayed in clear text on the user interface of the thick client, an attacker could easily steal them and use them to access sensitive information. By ensuring that sensitive data is not exposed through the user interface, the thick client can protect sensitive information from unauthorized access. + + +### TASVS-CODE-5.2 + +In thick client implementations, users face significant risks due to deceptive design patterns. These include tactics like fake scarcity, forced actions, hidden costs, and trick wording, which manipulate users into making unintended decisions. For instance, users might encounter fake urgency to rush purchases or hidden subscriptions they didn't consent to. Such practices undermine user autonomy, increase the likelihood of inadvertent commitments, and obscure critical information, leading to potential financial and security implications. Ensuring transparency and user control is crucial to mitigate these risks. + +For more details, visit [Deceptive Patterns.](https://www.deceptive.design/types) + +### TASVS-CODE-5.3 + +The thick client should only use workflows that do not violate common security advice. This can help to prevent attackers from exploiting security vulnerabilities in the thick client. For example, if the thick client uses insecure authentication methods or insecure data storage practices. This control is a reminder to the tester to allow intuition and experience to guide the testing process. + +### TASVS-CODE-5.4 + +The attack surface of the thick client should be reduced to be as small as possible. Sandboxing or encapsulation can help to prevent attackers from exploiting vulnerabilities in third-party libraries. For example, if a third-party library has a vulnerability that allows an attacker to execute arbitrary code, sandboxing or encapsulating the library can prevent the attacker from exploiting the vulnerability to compromise the thick client. We can limit the risk by using encapsulation or sandboxing to expose only the required behavior of the third-party library to the thick client. This allows us to better test and understand the functionality consumed by the application. + +An example of sandboxing a third-party library might look like this: + +```csharp +using System; +using ThirdPartyLibrary; + +public class Program +{ + public static void Main() + { + // Sandbox the third-party library + using (var sandbox = new Sandbox()) + { + // Use the third-party library in the sandbox + sandbox.DoSomething(); + } + } +} +``` + +In this example, the `Sandbox` class is used to encapsulate the `ThirdPartyLibrary` and prevent it from accessing code outside of the sandbox. + + +### TASVS-CODE-5.5 + +To prevent attackers from exploiting vulnerabilities in import files to compromise the thick client, it is important to ensure that import files cannot be abused. This can be done by validating and sanitizing import files before using them. For example, if the thick client imports data from a CSV file, the file should be validated and sanitized. + +### TASVS-CODE-5.6 + +If the thick client registers a URL handler or protocol handler, it is important to verify that it cannot trigger dangerous actions or introduce common vulnerabilities. For example, if the thick client registers a URL handler that allows it to open a file or execute a command, an attacker could use this to exploit memory corruption, command and argument injection, or other vulnerabilities. To mitigiate this, the thick client should validate and sanitize the URL handler or protocol handler before registering it or alternatively use an allow list of known good URLs or handlers. + +### TASVS-CODE-6.1 + +Performing "dumb fuzzing" of the thick client with randomized input can help to identify security vulnerabilities that may be missed during manual code review. By generating random input and testing the thick client with it, the tester can identify potential security vulnerabilities that may be exploitable by an attacker. + +One way to do this quickly is to use a fuzzer like [AFL]() or [libFuzzer](). These tools can automatically generate test cases and run them against the thick client to identify security vulnerabilities. + +### TASVS-CODE-6.2 + +Performing "smart fuzzing" of the thick client can help to identify security vulnerabilities that may be missed during manual code review. By intelligently generating test cases that maximize code coverage and explore complex program states, the tester can increase the likelihood of finding vulnerabilities over "dumb fuzzing". + +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.1 + +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-CODE-7.2 + +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. + \newpage{} \ No newline at end of file diff --git a/document/0.1/06-TASVS-CONF.md b/document/0.1/06-TASVS-CONF.md index f1f2ce9..05a8a0a 100644 --- a/document/0.1/06-TASVS-CONF.md +++ b/document/0.1/06-TASVS-CONF.md @@ -18,4 +18,36 @@ | 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-1.7 | Ensure that all software components, libraries, frameworks, and runtimes used in the application are up-to-date and not end-of-life or obsolete. Outdated or obsolete components can introduce security vulnerabilities, performance issues, and compatibility problems. | X | X | X | + +## Control Group Definitions + +### TASVS-CONF-1.1 + +TBC + +### TASVS-CONF-1.2 + +TBC + +### TASVS-CONF-1.3 + +TBC + +### TASVS-CONF-1.4 + +TBC + +### TASVS-CONF-1.5 + +TBC + +### TASVS-CONF-1.6 + +TBC + +### TASVS-CONF-1.7 + +TBC + + \newpage{} \ No newline at end of file diff --git a/document/0.1/07-TASVS-CRYPTO.md b/document/0.1/07-TASVS-CRYPTO.md index 1bc52cb..a4c89cd 100644 --- a/document/0.1/07-TASVS-CRYPTO.md +++ b/document/0.1/07-TASVS-CRYPTO.md @@ -19,4 +19,39 @@ | TASVS-CRYPTO-3.1 | Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks. | X | X | X | | TASVS-CRYPTO-3.2 | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. | X | X | X | + +## Control Group Definitions + +### TASVS-CRYPTO-1.1 + +TBC + +### TASVS-CRYPTO-2.1 + +TBC + +### TASVS-CRYPTO-2.2 + +TBC + +### TASVS-CRYPTO-2.3 + +TBC + +### TASVS-CRYPTO-2.4 + +TBC + +### TASVS-CRYPTO-3.1 + +TBC + +### TASVS-CRYPTO-3.2 + +TBC + + + + + \newpage{} \ No newline at end of file diff --git a/document/0.1/08-TASVS-NETWORK.md b/document/0.1/08-TASVS-NETWORK.md index 142b290..cafc400 100644 --- a/document/0.1/08-TASVS-NETWORK.md +++ b/document/0.1/08-TASVS-NETWORK.md @@ -27,4 +27,70 @@ | TASVS-NETWORK-4.3 | Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL injection attacks. | X | X | X | | TASVS-NETWORK-4.4 | Verify that the thick client doesn't expose services on the network like debugging features, even if bound to the local host. | X | X | X | + +## Control Group Definitions + +### TASVS-NETWORK-1.1 + +TBC + +### TASVS-NETWORK-1.2 + +TBC + +### TASVS-NETWORK-2.1 + +TBC + +### TASVS-NETWORK-2.2 + +TBC + +### TASVS-NETWORK-2.3 + +TBC + +### TASVS-NETWORK-2.4 + +TBC + +### TASVS-NETWORK-2.5 + +TBC + +### TASVS-NETWORK-2.6 + +TBC + +### TASVS-NETWORK-2.7 + +TBC + +### TASVS-NETWORK-3.1 + +TBC + +### TASVS-NETWORK-3.2 + +TBC + +### TASVS-NETWORK-4.1 + +TBC + +### TASVS-NETWORK-4.2 + +TBC + +### TASVS-NETWORK-4.3 + +TBC + +### TASVS-NETWORK-4.4 + +TBC + + + + \newpage{} \ No newline at end of file diff --git a/document/0.1/09-TASVS-STORAGE.md b/document/0.1/09-TASVS-STORAGE.md index 07a57ef..7e22a1d 100644 --- a/document/0.1/09-TASVS-STORAGE.md +++ b/document/0.1/09-TASVS-STORAGE.md @@ -19,4 +19,44 @@ | TASVS-STORAGE-2.1 | DLL Replacement: Swapping a genuine DLL with a malicious one, optionally using DLL Proxying to preserve the original DLL's functionality. | X | X | X | | TASVS-STORAGE-2.2 |
DLL Search Order Hijacking: Placing the malicious DLL in a search path ahead of the legitimate one, exploiting the application's search pattern. | X | X | X | +## Control Group Definitions + +### TASVS-STORAGE-1.1 + +TBC + +### TASVS-STORAGE-1.2 + +TBC + +### TASVS-STORAGE-1.3 + +TBC + +### TASVS-STORAGE-1.4 + +TBC + +### TASVS-STORAGE-1.5 + +TBC + +### TASVS-STORAGE-1.6 + +TBC + +### TASVS-STORAGE-1.7 + +TBC + +### TASVS-STORAGE-2.1 + +TBC + +### TASVS-STORAGE-2.2 + +TBC + + + \newpage{} \ No newline at end of file diff --git a/document/TASVS-v0.1.pdf b/document/TASVS-v0.1.pdf deleted file mode 100644 index 6f6dfe2..0000000 Binary files a/document/TASVS-v0.1.pdf and /dev/null differ