forked from OWASP/owasp-mastg
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Port mastg test 0020 (by @Guardsquare) (OWASP#3027)
* Test for insecure TLS Protocols * Add covered_by * Review feedback * Spelling * Apply suggestions from code review * fix test IDs --------- Co-authored-by: Carlos Holguera <[email protected]>
- Loading branch information
1 parent
593782a
commit 28d5e3c
Showing
3 changed files
with
69 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
--- | ||
title: Insecure TLS Protocols Explicitly Allowed in Code | ||
platform: android | ||
id: MASTG-TEST-0217 | ||
type: [static] | ||
weakness: MASWE-0050 | ||
--- | ||
|
||
## Overview | ||
|
||
The Android Network Security Configuration does not provide direct control over specific TLS versions (unlike ["iOS"](https://developer.apple.com/documentation/bundleresources/information_property_list/nsexceptionminimumtlsversion)), and starting with Android 10, [TLS v1.3 is enabled by default](https://developer.android.com/privacy-and-security/security-ssl#Updates%20to%20SSL) for all TLS connections. | ||
|
||
There are still several ways to enable insecure versions of TLS, including: | ||
|
||
### Java Sockets | ||
|
||
An app can obtain an SSLContext using an insecure TLS protocol by calling `SSLContext.getInstance("TLSv1.1")` and can also enable specific, potentially insecure, protocol versions using the API call `javax.net.ssl.SSLSocket.setEnabledProtocols(String[] protocols)`. | ||
|
||
### Third-party Libraries | ||
|
||
Some third-party libraries, such as [OkHttp](https://square.github.io/okhttp/), [Retrofit](https://square.github.io/retrofit/) or Apache HttpClient, provide custom configurations for TLS protocols. These libraries may allow enabling outdated protocols if not carefully managed: | ||
|
||
For example, using `ConnectionSpec.COMPATIBLE_TLS` in OkHttp (via `okhttp3.ConnectionSpec.Builder.connectionSpecs(...)`) can lead to insecure TLS versions, like TLS 1.1, being enabled by default in certain versions. Refer to OkHttp's [configuration history](https://square.github.io/okhttp/security/tls_configuration_history/) for details on supported protocols. | ||
|
||
The API call `okhttp3.ConnectionSpec.Builder.tlsVersions(...)` can also be used to set the enabled protocols (["OkHttp documentation"](https://square.github.io/okhttp/features/https/)). | ||
|
||
## Steps | ||
|
||
1. Reverse engineer the app (@MASTG-TECH-0017). | ||
2. Run a static analysis (@MASTG-TECH-0014) tool on the reverse engineered app targeting calls to APIs setting the TLS protocol. | ||
|
||
## Observation | ||
|
||
The output contains a list of all enabled TLS versions in the above mentioned API calls. | ||
|
||
## Evaluation | ||
|
||
The test case fails if any ["insecure TLS version"](https://mas.owasp.org/MASTG/0x04f-Testing-Network-Communication/#recommended-tls-settings) is directly enabled, or if the app enabled any settings allowing the use of outdated TLS versions, such as `okhttp3.ConnectionSpec.COMPATIBLE_TLS`. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,28 @@ | ||
--- | ||
title: Insecure TLS Protocols in Network Traffic | ||
platform: network | ||
id: MASTG-TEST-0218 | ||
type: [network] | ||
weakness: MASWE-0050 | ||
--- | ||
|
||
## Overview | ||
|
||
While static analysis can identify configurations that allow insecure TLS versions, it may not accurately reflect the actual protocol used during live communications. This is because TLS version negotiation occurs between the client (app) and the server at runtime, where they agree on the most secure, mutually supported version. | ||
|
||
By capturing and analyzing real network traffic, you can observe the TLS version actually negotiated and in use. This approach provides an accurate view of the protocol's security, accounting for the server’s configuration, which may enforce or limit specific TLS versions. | ||
|
||
In cases where static analysis is either incomplete or infeasible, examining network traffic can reveal instances where insecure TLS versions (e.g., TLS 1.0 or TLS 1.1) are actively in use. | ||
|
||
## Steps | ||
|
||
1. Set up @MASTG-TECH-0010 (for Android) or @MASTG-TECH-0062 (for iOS). | ||
2. View the TLS version e.g., using @MASTG-TOOL-0081. | ||
|
||
## Observation | ||
|
||
The output shows the actually used TLS version. | ||
|
||
## Evaluation | ||
|
||
The test case fails if any ["insecure TLS version"](https://mas.owasp.org/MASTG/0x04f-Testing-Network-Communication/#recommended-tls-settings) is used. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters