[titze]

This PR closes #2958.

Couple of notes:

• I did not move the original dynamic analysis, as I believe this does not really test if pinning is performed, or would give much information (e.g., for which domains). happy to discuss
• The old test also had in its headline "Testing Custom Certificate Stores". This is not really there anymore now. The Network Security Configuration does not allow this, and I am not sure there is even a good reason to do this at all. The MASWE-0047 is also about pinning only

[sushi2k]

Added comment to NSC config

[sushi2k]

Thank you for the new test cases and the PR @titze! Please check the suggestions below.

[cpholguera]

Hi @titze there's a problem with the PR, it now affects 240 files. Could you please recheck/fix the merging of the main branch so that only your changes are showing?

[titze]

Fixed. I messed up the rebase on master...

[cpholguera]

No problem, thanks so much for the fix!

[cpholguera]

Suggested change

	The Network Security Configuration can be used to pin [declarative certificates](https://developer.android.com/training/articles/security-config.html#CertificatePinning) to specific domains. This is done by providing a `<pin-set>` in the Network Security Configuration, which is a set of digests (hashes) of the public key (`SubjectPublicKeyInfo`) of the corresponding X.509 certificate.
	The **Network Security Configuration (NSC)** is the preferred and recommended way to implement certificate pinning in Android, as it provides a declarative, maintainable, and secure approach without requiring code changes. It applies to all network traffic within the app, including `HttpsURLConnection`-based connections and `WebView` requests (unless a custom `TrustManager` is used).
	To use [NSC for pinning](https://developer.android.com/training/articles/security-config.html#CertificatePinning), a `<pin-set>` is defined in the `network_security_config.xml` file. This `<pin-set>` contains the **hashes of the public key (`SubjectPublicKeyInfo`)** from the X.509 certificate of the trusted server.

[titze]

It applies to all network traffic within the app

this is not completely true, the NSC only applies to connections done through the Android stack. Communication via low level APIs (e.g. from native code) do not take this into account.

[titze]

I changed this to:

The Network Security Configuration (NSC) is the preferred and recommended way to implement certificate pinning in Android, as it provides a declarative, maintainable, and secure approach without requiring code changes. It applies to all network traffic managed by the Android framework within the app, including HttpsURLConnection-based connections and WebView requests (unless a custom TrustManager is used). For communication from native code, NSC does not apply, and other mechanisms need to be considered.

[sushi2k]

One small change from my side. Otherwise this looks good to me.

Thank you for the work @titze and the suggestions @cpholguera!

[sushi2k]

MiTM change

[cpholguera]

Excellent, thanks for the updates! I'm reviewing the tests now and will post my suggestions soon.

[cpholguera]

We need to split the tests according to the sections we defined in 0x05g.

For example, here we can create another static test for the custom Trust Manager case. Does the app use this approach and if it does, is it correct? For example: uses a Trust Manager that does nothing and therefore trusts everything.

You can open a ticket for that if you prefer, so we can get this PR merged soon and keep this test focused on the NSC way. Please update the content below to be NSC specific only.

Suggested change

	title: Missing Certificate Pinning in Code
	title: Missing Certificate Pinning in Network Security Configuration

[titze]

I created a task, this PR is getting quite big.
#3183

[cpholguera]

And monitor logcat for clues while doing this?

[titze]

@cpholguera which clues do you have in mind?
The way I did this before was to just look at the intercepting proxy, logcat from the device never added anything too useful for this particular test.

[cpholguera]

Doesn't it output a javax.net.ssl.SSLHandshakeException / java.security.cert.CertPathValidatorException when pinning fails due to the presence of the MITM?

Or maybe I/X509Util: Failed to validate the certificate chain, error: Pin verification failed

See the original test: https://mas.owasp.org/MASTG/tests/android/MASVS-NETWORK/MASTG-TEST-0022/#network-security-configuration

[titze]

The log message largely depends on how this is implemented. There might be some, but if the app follows best practise, it would not give an attacker any information in the logs.
The log message itself could also mean very different things. Does it mean the connection succeeds even in the precence of a Mitm, or that it was not established.
Imo, the real test is in the proxy itself: were you able to intercept, or not.

[cpholguera]

I think you're right, but I also think it may be helpful to at least mention this as a testing tip, as the original test did. If you're trying to intercept and you get these log messages, that can be useful info. Also, if I'm not mistaken, some of these logs are coming from the system. Also, if the app doesn't follow best practices, even better for you as a tester.

I suggest we add it as a test tip, and once the demos are in place, if it's not helpful, we can remove it.

[titze]

Added here: https://github.com/OWASP/owasp-mastg/pull/3035/files#diff-f80e3f6500270dd6399fc42dfbaca162f8015f5150a380d544f7f20066dc7bafR14

[cpholguera]

Doesn't it output a javax.net.ssl.SSLHandshakeException / java.security.cert.CertPathValidatorException when pinning fails due to the presence of the MITM?

Or maybe I/X509Util: Failed to validate the certificate chain, error: Pin verification failed

See the original test: https://mas.owasp.org/MASTG/tests/android/MASVS-NETWORK/MASTG-TEST-0022/#network-security-configuration

[cpholguera]

@titze this is almost ready, just a couple of suggestions and we can merge. Thank you!

[cpholguera]

Thanks a lot @titze!!