Add new MASWE: Device or/and Attestation improperly implemented

[Diolor]

Add a new MASWE placeholder when device or app integrity is improperly implemented, e.g., missing attestation challenge when (asymmetric) keys are generated.

See :

• https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setAttestationChallenge(byte[])
• https://developer.apple.com/documentation/devicecheck/dcappattestservice/attestkey(_:clientdatahash:completionhandler:)/#parameters

[cpholguera]

@Diolor how's this different from MASWE-0100 Device Attestation Not Implemented?

#38

[Diolor]

@cpholguera the way #9 is formulated focuses on "if". This focuses on "how", which assumes that device/app attestation is implemented, but not correctly.

Reading the WEs in RESILIENCE they focus on "if", including this one. Reading the WEs in CRYPTO, they focus on "how". That also makes sense. The RESILIENCE give awareness to the reader, while the CRYPTO give "weakpoints knowledge".

It has merit to provide advice for the RESILIENCE practices focusing on the "how" and their weak points, similar we do in CRYPTO. Wdyt?

This points to a general question on how we wish to write WEs in RESILIENCE. A practical solution would be to expand the Not Implemented WEs in RESILIENCE (including this one) to the somewhat more generic "missing or misconfigured".

[cpholguera]

The intention behind those MASWEs was precisely that. There's no benefit for us in having two weaknesses that cover "not implemented" and "implemented incorrectly." The weakness is the same. Therefore, we're open to updating the titles to reflect this.

We've done a consolidation of terms for a glossary some months ago (I'll send you a link to the draft that will be published to the OWASP MAS website soon).

The terms to use would be "Missing or Incorrect". Example: "Missing or Incorrect Device Attestation"

[Diolor]

Awesome, let's use existing WEs when needed for misconfigurations