-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MASWE-0103] - RASP Techniques Not Implemented #3074
base: master
Are you sure you want to change the base?
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
--- | ||
title: Demonstration of RASP Presence in a Mobile Application | ||
platform: android | ||
code: [kotlin] | ||
id: MASTG-DEMO-0021 | ||
test: MASTG-TEST-0228 | ||
--- | ||
|
||
### Sample | ||
|
||
The following code snippet demonstrates the implementation of the freeRASP security library SDK. freeRASP periodically scans the device for threats, monitors its state, and gathers data to generate detailed threat reports. Threats are detected and communicated to the app via listeners. In this example, the root detection scenario is simulated. | ||
|
||
{{ MastgTest.kt }} | ||
|
||
### Steps | ||
Check failure on line 15 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md GitHub Actions / markdown-lint-checkHeadings should be surrounded by blank lines
|
||
Start the device, in this case, the Android emulator: | ||
```bash | ||
Check failure on line 17 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md GitHub Actions / markdown-lint-checkFenced code blocks should be surrounded by blank lines
|
||
emulator -avd Pixel_3a_API_33_arm64-v8a -writable-system | ||
``` | ||
|
||
**Note:** The snippet implements a simulated test for the freeRASP security library's root detection feature. The MastgTest class, which implements the ThreatDetected interface, includes various threat detection methods such as root detection, debugger detection, and emulator detection. The test specifically focuses on mocking the root detection functionality by invoking the onRootDetected() method, which logs the detection event and simulates app termination using the closeApp() method. | ||
|
||
Launch the app from Android Studio and check the log. The snippet will log the “freeRASP Threat: onRootDetected”. | ||
|
||
|
||
Check failure on line 25 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md GitHub Actions / markdown-lint-checkMultiple consecutive blank lines
|
||
### Observation | ||
Check failure on line 26 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md GitHub Actions / markdown-lint-checkHeadings should be surrounded by blank lines
|
||
The RASP policy is only configured for root detection, other threats are not evaluated. The threat was detected immediately after app start. Sample includes commented-out code to forcefully terminate the app. | ||
|
||
|
||
Check failure on line 29 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md GitHub Actions / markdown-lint-checkMultiple consecutive blank lines
|
||
### Evaluation | ||
Check failure on line 30 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md GitHub Actions / markdown-lint-checkHeadings should be surrounded by blank lines
|
||
The app didn’t utilise all the available security checks. It would be possible to bypass freeRASP API with Frida script or disable the termination method. |
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This demo seems to focus on demonstrating how to implement a specific RASP solution, rather than a demo to achieve the test. If I am a developer who has a RASP solution for my application and I am testing it, I think I would need a demo that focuses on how I can demonstrate/confirm that RASP is implemented for my app. For this reason, I think this demo does not relate well to the Test. It is also not typical for the OWASP demos to endorse tools (exceptions of course and preference for open-source utilities that are helpful in performing a given test). |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,91 @@ | ||
package org.owasp.mastestapp | ||
|
||
|
||
import android.content.Context | ||
import android.util.Log | ||
|
||
|
||
// mock: freeRASP ThreatDetected interface | ||
interface ThreatDetected { | ||
fun onRootDetected() | ||
fun onDebuggerDetected() | ||
fun onEmulatorDetected() | ||
fun onTamperDetected() | ||
fun onUntrustedInstallationSourceDetected() | ||
fun onHookDetected() | ||
fun onDeviceBindingDetected() | ||
fun onObfuscationIssuesDetected() | ||
} | ||
|
||
|
||
// MastgTest class implementing ThreatDetected | ||
class MastgTest(private val context: Context) : ThreatDetected { | ||
|
||
|
||
companion object { | ||
const val FREERASP_THREAT_TAG = "freeRASP Threat: " | ||
} | ||
|
||
|
||
fun mastgTest(): String { | ||
return simulateThreatDetection() | ||
} | ||
|
||
|
||
// Simulate a test by calling onRootDetected | ||
fun simulateThreatDetection() : String { | ||
onRootDetected() // mock root was detected by freeRASP | ||
|
||
|
||
return "freeRASP Threat: onRootDetected" | ||
} | ||
|
||
|
||
fun closeApp() { | ||
// finishAffinity() // Closes all screens of the app | ||
// System.exit(0) // Completely exits the app process | ||
} | ||
|
||
|
||
|
||
|
||
override fun onRootDetected() { | ||
Log.d(FREERASP_THREAT_TAG, "onRootDetected") | ||
closeApp() // Standard method to forcefully terminate the app | ||
} | ||
|
||
|
||
override fun onDebuggerDetected() { | ||
Log.d(FREERASP_THREAT_TAG, "onDebuggerDetected") | ||
} | ||
|
||
|
||
override fun onEmulatorDetected() { | ||
Log.d(FREERASP_THREAT_TAG, "onEmulatorDetected") | ||
} | ||
|
||
|
||
override fun onTamperDetected() { | ||
Log.d(FREERASP_THREAT_TAG, "onTamperDetected") | ||
} | ||
|
||
|
||
override fun onUntrustedInstallationSourceDetected() { | ||
Log.d(FREERASP_THREAT_TAG, "onUntrustedInstallationSourceDetected") | ||
} | ||
|
||
|
||
override fun onHookDetected() { | ||
Log.d(FREERASP_THREAT_TAG, "onHookDetected") | ||
} | ||
|
||
|
||
override fun onDeviceBindingDetected() { | ||
Log.d(FREERASP_THREAT_TAG, "onDeviceBindingDetected") | ||
} | ||
|
||
|
||
override fun onObfuscationIssuesDetected() { | ||
Log.d(FREERASP_THREAT_TAG, "onObfuscationIssuesDetected") | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,43 @@ | ||
--- | ||
title: Detection of RASP presence in mobile application | ||
platform: android | ||
id: MASTG-TEST-0228 | ||
type: [static, dynamic] | ||
available_since: 24 | ||
weakness: MASWE-0103 | ||
mitigations: | ||
prerequisities: | ||
--- | ||
|
||
## Overview | ||
Check failure on line 12 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md GitHub Actions / markdown-lint-checkHeadings should be surrounded by blank lines
|
||
RASP (Runtime Application Self-Protection) is designed to monitor and protect the application during runtime by detecting and responding to threats in real-time. The test verifies if the application can identify and react to unauthorised modifications, such as code tampering, root or jailbreak environment, and attempts to bypass security mechanisms. It also checks if the application has the ability to protect sensitive data and prevent unauthorised access to critical operations or features. | ||
|
||
By conducting this test, we ensure that the app is capable of defending against runtime attacks and maintaining its integrity even in compromised environments. If RASP techniques are not implemented or are improperly configured, the app may be vulnerable to various security threats, including data breaches, unauthorised access, and malicious modifications. | ||
|
||
## Steps | ||
Check failure on line 17 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md GitHub Actions / markdown-lint-checkHeadings should be surrounded by blank lines
|
||
1. Ensure that all security checks and protection mechanisms expected from RASP are present and enabled with the application. To test the RASP policy that the app enforces, a written copy of the policy must be provided. The policy should define available checks and their enforcement. For example: | ||
Check failure on line 18 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md GitHub Actions / markdown-lint-checkTrailing spaces
Check failure on line 18 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md GitHub Actions / markdown-lint-checkLists should be surrounded by blank lines
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would advocate for requiring an up-front test step that requires the determination of "in scope" RASP checks, I don't know if it needs to be captured as a written policy per se. Could simply be a statement of, prior to evaluating RASP checks ensure the test scope is defined based on your organizations required, or designed/implemented RASP checks, as the RASP configuration strategy may differ from organization-to-organization. Alternatively, you could always rely on testing for all RASP checks related to the weakness, and failing the test, and leaving it to the organization to annotate why a failed test is acceptable based on their desired RASP configuration approach. |
||
- Root detection. | ||
- Screen lock enforcement. | ||
- Code integrity checks. | ||
- Detection of dynamic analysis. | ||
|
||
2. Based on the previous step, attempt to simulate threats to test if the application reacts as expected. This can involve various scenarios such as: | ||
- Launching the mobile application on a rooted device. | ||
- Launching the mobile application on a device without a screen lock enabled. | ||
- Attempting to repackage the application and launching it. | ||
- Launching the application in an emulator. | ||
|
||
3. Verify that the application properly detects and responds to potential threats. There are various scenarios in which a mobile application can respond to these threats, such as: | ||
- Killing the app. | ||
- Warning the user about the detected threat. | ||
- Logging information about potential risks to a database or SIEM. | ||
|
||
## Observation | ||
The output depends on the specific reactions set up for the mobile application. The results should demonstrate the app’s behaviour when a threat is detected or triggered, for example: | ||
- Application is terminated. | ||
- Application displays a warning message. | ||
- Application sends information to a database or SIEM. Testers should ensure that the collected threat intelligence data are rich enough. | ||
|
||
|
||
## Evaluation | ||
The test case fails if the mobile application does not react as expected to the detected threats. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This demo seems to focus on demonstrating how to implement a specific RASP solution, rather than a demo to achieve the test. If I am a developer who has a RASP solution for my application and I am testing it, I think I would need a demo that focuses on how I can demonstrate/confirm that RASP is implemented for my app. For this reason, I think this demo does not relate well to the Test.
It is also not typical for the OWASP demos to endorse tools (exceptions of course and preference for open-source utilities that are helpful in performing a given test).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"This demo seems to focus on demonstrating how to implement a specific RASP solution, rather than a demo to achieve the test."
I think the test can be used to assess majority of mobile app RASPs. At the same time the test tries to avoid duplicating other resiliency MASWEs (root detection, integrity verification, etc. are separated issues). I like that the demo is a minimal example utilizing the RASP that is free to use and has a public docs - easier to maintain in the future. It would be great to add more other RASPs in the future if possible. Do you have an experience with other RASPs that could be added?
"If I am a developer who has a RASP solution for my application and I am testing it, I think I would need a demo that focuses on how I can demonstrate/confirm that RASP is implemented for my app. For this reason, I think this demo does not relate well to the Test."
This is inherently dependent on the RASP product itself and the individual configuration / expected features / reaction etc. I think this works well as an example / guideline that could be extended in the future.
"It is also not typical for the OWASP demos to endorse tools (exceptions of course and preference for open-source utilities that are helpful in performing a given test)."
In this case we could make an exception for obvious reasons.