Thick Client and Desktop Application Penetration Testing
Thick client penetration testing proves the client side trust assumptions, local data storage and backend communication flaws of desktop applications. Reverse engineering, authorization bypass, insecure storage and business logic, when it is needed and the proof based approach with KAOS.
Quick answer: Thick client penetration testing is a security service that examines, through an attacker's eyes, the flaws of desktop applications installed on the user's computer. The core problem of these applications is this: part of the code runs on the user's computer, that is in an environment under the attacker's full control. The most common flaws are excessive trust in the application, that is important decisions made on the client side, data stored insecurely on the local disk, credentials left in the application's memory and unencrypted backend communication. DSET runs this test with its local AI engine KAOS and verifies every finding with a working proof.
While many organizations regularly test their web and mobile applications, they overlook the installed applications on employees' desks. Yet an accounting program, a bank terminal or a production control software often reaches the most sensitive data and the most critical operations. This article explains what thick client penetration testing is, which flaws it targets and the DSET and KAOS approach.
What is thick client penetration testing
Thick client penetration testing examines three layers of a desktop application together. The first layer is the application itself, that is examining the executable through reverse engineering and searching for secrets embedded in it. The second layer is local data storage, that is whether the data the application writes to disk or the registry is stored securely. The third layer is backend communication, that is whether the application encrypts its traffic when talking to the server and whether that traffic can be modified. When these three layers are not tested together, a complete security picture does not emerge.
Which flaws it targets
The flaws of thick client applications stem from the code running in an environment under the user's control. The attacker can examine the application, modify it and read its memory.
| Flaw class | What it means | Typical result |
|---|---|---|
| Client side trust | An important decision is made on the client | Authorization and business logic bypass |
| Insecure local storage | Sensitive data is written to disk in clear | Data exposure |
| Embedded secret | A key or password is found in the executable | Credential leakage |
| Unencrypted communication | Traffic is plaintext or modifiable | Interception, data tampering |
| Weak update | The application pulls an unsigned update | Malicious update |
The essence of the table is this: because the attacker has full access to the environment in a thick client application, leaving security to the client is the biggest mistake. Every critical decision must be re verified on the server side. The same trust problem applies to mobile applications; for a comparable logic mobile application penetration testing and OWASP MASVS offers a comparative view.
Why client side trust is dangerous
When a thick client application decides within itself whether a user can perform an operation, the attacker can change that decision. Because the application runs on the attacker's computer and the attacker can change the application's memory and behavior. For this reason the test centers on a single question: does the application make a security decision only on the client side, or does it re verify it on the server side? For testing the backend services the application talks to, our API penetration testing service is complementary.
Reverse engineering and memory analysis
A strong part of thick client testing is examining the executable through reverse engineering. This examination uncovers the secrets embedded in the application, hidden features and how the security controls are built. The memory is also examined while the application runs, because credentials and sensitive data are often found in clear in memory. These methods are used to prove that a flaw can actually be exploited, not to show a theoretical risk.
When is it needed
Thick client penetration testing should be done before a new desktop application is deployed, when there is an important change in the application and at regular intervals. It is especially important for desktop applications that run critical operations in finance, health and production. The scope and type of the test must be set in advance, for which the penetration testing types and scope guide is the reference point.
The KAOS and DSET approach
DSET runs thick client penetration testing with its local AI engine KAOS. KAOS examines the executable through reverse engineering, tests local storage and backend communication, tests client side trust assumptions and reports every flaw it finds with a working proof, under the principle of proof based verification. The difference is this: it does not settle for saying a trust assumption could theoretically be abused, it proves that the assumption is actually bypassed. After a finding is verified, retest and remediation verification is applied to see that the fix works.
Frequently asked questions
Does thick client testing use the same methods as web application testing? Partly. The methods are similar in backend communication and business logic testing, but thick client testing additionally includes reverse engineering of the executable, local storage examination and memory analysis. These extra layers stem from the code running on the user's computer.
My application is not open source, is reverse engineering still possible? Yes. Even if an application's source code is closed, its executable is on the user's computer, so an attacker can examine it. For this reason security must rest on sound design, not on the secrecy of the code. The test also uses the same reverse engineering methods to prove what an attacker could do.
Will the test harm my application or data? No. The test focuses on proving the existence of a flaw, not on erasing data or breaking the application. Which application and which environment will be tested are set in advance by contract, and when possible the test is run on a copy environment.
Sources
- OWASP Application Security Verification Standard (ASVS): https://owasp.org/www-project-application-security-verification-standard/
- NIST SP 800-115, Technical Guide to Information Security Testing: https://csrc.nist.gov/pubs/sp/800/115/final
- DSET Penetration Testing and Security Services: https://dset.com.tr/hizmetler
To examine your desktop and thick client applications with a proof based test, contact DSET. We provide thick client penetration testing and consulting from our Ankara Hacettepe Teknokent laboratory.
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.