Thick Client Application VAPT
Application Privilege Level | CWE-250
Description
Application runs with more than minimum required privileges. An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.
Mitigations
Run your code using the lowest privileges that are required to accomplish the necessary tasks.
Identify the functionality that requires additional privileges, such as access to privileged operating system resources.
Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements.
Buffer Overflow | CWE-121
Description
Application does not properly validate the variable’s size before storing it in the buffer causing it to be overwritten. Buffer Overflow attempts from processor gives rise to access violation exception and the program crashes. However attempted buffer overflows, can lead to potential DOS.
Mitigations
Libraries and executables can be compiled with some additional security measures to protect against code exploitation:
Address Space Layout Randomization (ASLR) — An application’s locations in memory are randomized at load time, preventing attacks such as return-to-libc that lead to code execution by overwriting specific addresses.
SafeSEH — A list of safe exception handlers is stored within a binary, preventing an attacker from forcing the application to execute code during a call to a malicious exception.
Data Execution Prevention (DEP) — Areas of memory can be marked as non-executable, preventing an attacker from storing code for a buffer overflow attack in these regions.
Authenticode/Strong Naming — Assemblies can be protected by signing. If left unsigned, an attacker is able to modify and replace them with malicious content.
Controlflowguard — An extension of ASLR and DEP that limits the addresses where code can execute from.
HighentropyVA — A 64 bit application uses ASLR.
Broken Authorization | CWE-285
Description
Object level or/and function level authorization is not implemented or incorrectly implemented in the application. An attacker could read sensitive data, either by reading the data directly from a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.
Mitigations
The authentication and authorization policies are role based, to minimize the effort required to maintain these policies.
The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page.
If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access.
Avoid exposing your private object references to users whenever possible, such as primary keys or filenames.
Instead of sending primary keys (like code in the above scenario) in URL, better to use session to send such a kind of information.
Verify authorization to all referenced objects.
DLL Hijacking | CWE-427
Description
DLL Hijacking attack that exploits the way some Windows applications search and load Dynamic Link Libraries. Can compromise the complete system through code execution. This will also helpful at the time of privilege escalation if the application is accessed by super user.
Mitigations
In order to avoid DLL Hijacking, Use absolute paths to clearly define the expected location of Dynamic Link Libraries in the software code.
Dependencies in Process | CWE-1047
Description
Executable and libraries used by the application connect to application server or to some third-party services and the changes made in registry by the application on the client machine may reveal information about the presence of backdoor in the application. Including these vulnerabilities into you systems opens you (and your users) to data theft, infection by malware, and system takeover.
Mitigations
Automate your build and deployment processes.
Deploy known-good versions of software.
Be careful of private dependencies.
Use dedicated tools to scan your dependency tree for security risks.
Keep on top of security bulletins.
Forced URL Access via Web Browser | CWE-425
Description
Config files and the requests generated reveal the URL used to connect the application server. This URL could be used to connect the server directly using web browser. This allows the attacker to access resources that they should not be able to access. Such resources may contain sensitive information.
Mitigations
The developer must never assume that a publicly accessible URL is impossible to find. If it exists, it can be found. Authentication is a must.
The developer must never assume that once the user is authenticated, they don’t need any other access control. For every URL that is accessed, the developer must make sure that the authenticated user is authorized to access the content.
Injection | CWE-89
Description
User input are not validated/sanitized before being used in a SQL queries, OS Commands, LDAP command, etc. They can lead to data theft, data loss, loss of data integrity, denial of service, as well as full system compromise.
Mitigations
Parameterized queries using bound, typed parameters.
Careful use of parameterized stored procedures.
The preferred option is to properly escape all un-trusted data based on the HTML context. Include data escaping techniques in their applications.
Server side and client side validation. Server side validation is mandatory.
Insufficient Transport Layer Security | CWE-319
Description
Application sends sensitive data to the server in clear text format over the network. An attacker may sniff the packets to breach data confidentiality. This vulnerability can result in compromise of users’ account and data.
Mitigations
Use latest stable version of TLS to protect all sensitive communications passing between the client and the server.
Implement HTTP Strict Transport Layer Security.
If HTTP cookies are used for transmitting session tokens, then the secure flag should be set to prevent transmission over clear-text HTTP.
If implementing HTTPS is not possible, implement salted SHA-256 or salted SHA-512 hashing algorithms on password fields, while using plain SHA-256 or SHA-512 hashing on new password fields.
Improper Error Handling | CWE-755
Description
Application generates error messages that leads to Information gathering, version disclosure, application code disclosure or logs. Depends on the information, such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise.
Mitigations
Ensure that a customized error message is shown for any error that has occurred, which gives out very limited information.
Disable or limit detailed error handling. In particular, do not display debug information to end users, stack traces, or path information.
Application should make secure to prevent revealing of any kind of error and Hardening process should be carried out periodically.
Improper Session management | CWE-613
Description
Application does not secure manage sessions causing session hijacking and account takeover. Attackers can steal passwords, gain access to the application and escalate privilege by sniffing and man in the middle attack.
Mitigations
Follow a secure session management lifecycle which includes proper initialization, maintenance, authentication and termination of the session token.
Authenticated session should be timed out/expire automatically, after a certain period of time when the user is idle.
The token/session must be expiring after the user logout from the application.
Insecure Deserialization | CWE-502
Description
Application uses insecure serialization libraries for storing or transferring data. It allows an attacker to reuse existing application code in harmful ways, resulting in numerous other vulnerabilities, often remote code execution. Even in cases where remote code execution is not possible, insecure deserialization can lead to privilege escalation, arbitrary file access, and denial-of-service attacks.
Mitigations
Deserialization of user input should be avoided unless absolutely necessary.
If you do need to deserialize data from untrusted sources, incorporate robust measures to make sure that the data has not been tampered with.
If possible, you should avoid using generic deserialization features altogether. Serialized data from these methods contains all attributes of the original object, including private fields that potentially contain sensitive information.
Improper Memory Level Protection | CWE-119
Description
If the application is not properly configured with memory level protection checks such as ASLR, DEP, CFG then the application will be vulnerable to buffer overflow attacks. If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow.
Mitigations
Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.
Insecure Data Storage | CWE-922
Description
Sensitive data is being stored in publicly accessible directories, folders or files. Attackers can read sensitive information by accessing the unrestricted storage mechanism.
Mitigations
Do not store credentials on the file system. Make it so the user must identify themselves with a standard login each time the application is opened and that the appropriate session timeouts are put into place.
Be particular about the cryptography that is being implemented and use solutions that avoid the leakage of Sensitive Data.
Avoid using hardcoded encryption or decryption keys.
Add another layer of encryption beyond the default encryption methods provided by the operating system.
Insecure Configuration File | CWE-13
Description
During the installation and execution of thick client applications, these apps tend to write/modify sensitive details in the files and registries. The sensitive data stored by these apps usually include username, passwords, database credentials, license details, cryptographic keys, and configuration details like IP address, port, etc… The attacker can get access to these sensitive details and might compromise the application.
Mitigations
Never store sensitive data on the configuration files. Force the user to authenticate using a standard Web or API login scheme (over HTTPS) to the application upon each opening and ensure session timeouts are set at the bare minimum to meet the user experience requirements.
Where storage or caching of information is necessary consider using an strong encryption.
Insufficient Cryptography | CWE-326
Description
Application uses weak, obsolete or custom cryptography algorithms. An attacker may be able to decrypt the data and gain access to sensitive information.
Mitigations
Use an encryption scheme that is currently considered to be strong by experts in the field.
Log Tampering | CWE-117
Description
This attack targets the log files of the target host. The attacker injects, manipulates or forges malicious log entries in the log file, allowing them to mislead a log audit, cover traces of attack, or perform other malicious actions. The target host is not properly controlling log access. As a result tainted data is resulting in the log files leading to a failure in accountability, non-repudiation and incident forensics capability. Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters.
Mitigations
Carefully control access to physical log files.
Do not allow tainted data to be written in the log file without prior input validation. An allowlist may be used to properly validate the data.
Use synchronization to control the flow of execution.
Use static analysis tools to identify log forging vulnerabilities.
Avoid viewing logs with tools that may interpret control characters in the file, such as command-line shells.
Malicious File Upload | CWE-434
Description
Application allows upload of files with malicious content. The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, client-side attacks, or simple defacement. It depends on what the application does with the uploaded file and especially where it is stored.
Mitigations
Application should check allowed File extension and File type (MIME Type) in the upload module using white-list filter at server side.
File to be uploaded should be restricted to a particular size.
Server side check for not allowing long filename with double extension/double dot(.)/nullbyte(%00)/meta characters.
Assign only Read and Write permissions to the upload folders as required.
Response Modification | CWE-294
Description
Application performs operations based on the response generated by the server, an attacker can intercept and modify the responses to bypass authentication, privilege escalation, etc. Response modification attack allow access to resources which are not otherwise accessible without proper authentication.
Mitigations
Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.
Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.
Reverse Engineering | CWE-656
Description
Application binary can be decompiled to the source code. An attacker can check for the hard coded credentials, cryptographic keys or business rules which could be modified and the application could be recompiled. An attacker may exploit reverse engineering to achieve any of the following:
Reveal information about back end servers;
Reveal cryptographic constants and ciphers;
Steal intellectual property;
Perform attacks against back end systems; or
Gain intelligence needed to perform subsequent code modificationMitigations
Employ “obfuscation logic” to protect source code decompilation and reverse engineering attempts.
A good obfuscator will have the following abilities:
Narrow down what methods / code segments to obfuscate;
Tune the degree of obfuscation to balance performance impact;
Obfuscate string tables as well as methods
Sensitive data in process memory | CWE-316
Description
During the installation and execution of thick client applications, it temporarily stores data into the memory from different environments like users or network for further processing. The sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the application crashes, or if the programmer does not properly clear the memory before freeing it. The attacker can get access to these sensitive details and might compromise the application.
Mitigations
Prefer the system’s authentication dialog (or any other mechanism provided by the OS) for authentication to privileged services.
Do not hard code sensitive data in programs.
Disable memory dumps.
Do not store sensitive data beyond its time of use in a program.
Do not store sensitive data in plaintext (either on disk or in memory).
Securely erase sensitive data from disk and memory.
If you must store sensitive data, encrypt it first.
Weak Authentication | CWE-287
Description
Application suffers from weak authentication mechanisms, brute force, weak password policy or failure to validate 2Factor authentication, etc. Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.
Mitigations
Adopting a strong Password Policy and enforcing it consistently in all applications.
Using Two-Factor or Multi-Factor Authentication when the risk level warrants it.
Integrating an industry standard authentication framework.
Adding Risk-based Authentication and escalating challenges as circumstances warrant.
Ensuring that authentication is a pre-condition to access all application resources.
Keeping the authentication token secure and limited in lifetime.
