Create rule S7204: Obfuscation should be enabled for release builds (SONARKT-579) (#4691)
* Create rule S7204 * Add initial rule text * Take out empty lines from example * Implement suggested review changes --------- Co-authored-by: egon-okerman-sonarsource <egon-okerman-sonarsource@users.noreply.github.com> Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com>
This commit is contained in:
parent
b34a35ee48
commit
e9f98eab67
38
rules/S7204/kotlin/metadata.json
Normal file
38
rules/S7204/kotlin/metadata.json
Normal file
@ -0,0 +1,38 @@
|
||||
{
|
||||
"title": "Obfuscation should be enabled for release builds",
|
||||
"type": "VULNERABILITY",
|
||||
"status": "ready",
|
||||
"remediation": {
|
||||
"func": "Constant\/Issue",
|
||||
"constantCost": "5min"
|
||||
},
|
||||
"tags": [
|
||||
"cwe"
|
||||
],
|
||||
"defaultSeverity": "Major",
|
||||
"ruleSpecification": "RSPEC-7204",
|
||||
"sqKey": "S7204",
|
||||
"scope": "All",
|
||||
"securityStandards": {
|
||||
"CWE": [
|
||||
200
|
||||
],
|
||||
"OWASP Mobile Top 10 2024": [
|
||||
"M7",
|
||||
"M8"
|
||||
],
|
||||
"OWASP Top 10 2021": [
|
||||
"A5"
|
||||
]
|
||||
},
|
||||
"defaultQualityProfiles": [
|
||||
"Sonar way"
|
||||
],
|
||||
"quickfix": "unknown",
|
||||
"code": {
|
||||
"impacts": {
|
||||
"SECURITY": "HIGH"
|
||||
},
|
||||
"attribute": "COMPLETE"
|
||||
}
|
||||
}
|
59
rules/S7204/kotlin/rule.adoc
Normal file
59
rules/S7204/kotlin/rule.adoc
Normal file
@ -0,0 +1,59 @@
|
||||
Obfuscation makes reverse engineering significantly more difficult by making code harder to understand. This helps to deter malicious actors from easily discovering vulnerabilities or stealing proprietary algorithms in publicly deployed software. It is therefore recommended to enable obfuscation in release builds.
|
||||
|
||||
== Why is this an issue?
|
||||
|
||||
When you build a release version of your application, you're creating a distributable package of your code. Without obfuscation, the compiled code retains readable names and structures, making it much easier for someone to reverse-engineer your application. This means they can potentially understand your code's logic, extract sensitive information like API keys, or even modify your application for malicious purposes. Obfuscation scrambles these names and structures, making it significantly harder to reverse-engineer and understand, thus protecting your intellectual property and sensitive data.
|
||||
|
||||
Release builds are meant for distribution to end users and is therefore under constant scrutiny. Skipping obfuscation in these builds creates a serious vulnerability. While debugging builds often disable obfuscation for easier troubleshooting, failing to enable it for release builds exposes your application to unnecessary risks.
|
||||
|
||||
== How to fix it in Android
|
||||
|
||||
=== Code examples
|
||||
|
||||
==== Noncompliant code example
|
||||
|
||||
By default, obfuscation is not enabled for the release build type.
|
||||
|
||||
[source,kotlin,diff-id=1,diff-type=noncompliant]
|
||||
----
|
||||
android {
|
||||
buildTypes {
|
||||
release {}
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
==== Compliant solution
|
||||
|
||||
Obfuscation can be enabled by setting `minifyEnabled` to `true`. The `proguardFiles` function then specifies the ProGuard configuration files that will be used.
|
||||
|
||||
[source,kotlin,diff-id=1,diff-type=compliant]
|
||||
----
|
||||
android {
|
||||
buildTypes {
|
||||
release {
|
||||
isMinifyEnabled = true
|
||||
proguardFiles(
|
||||
getDefaultProguardFile("proguard-android-optimize.txt"),
|
||||
"proguard-rules.pro"
|
||||
)
|
||||
}
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
=== How does this work?
|
||||
|
||||
Setting `isMinifyEnabled` to `true` and providing `proguardFiles` in your Android Gradle configuration activates code shrinking and obfuscation. R8 (or ProGuard in older projects) then analyzes your code, removing unused parts and renaming classes and methods to obscure their purpose. This process makes it significantly harder for someone to reverse-engineer your application.
|
||||
|
||||
The `proguardFiles` let you define exceptions for code that shouldn't be altered, ensuring that essential parts of your application remain functional while still benefiting from the security enhancements of R8/ProGuard.
|
||||
|
||||
== Resources
|
||||
=== Documentation
|
||||
* Android Documentation - https://developer.android.com/build/shrink-code[Shrink, obfuscate, and optimize your app]
|
||||
* OWASP Mobile Application Security Testing Guide - https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/[Android Anti-Reversing Defenses]
|
||||
|
||||
=== Standards
|
||||
* OWASP - https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[Top 10 2021 Category A5 - Security Misconfiguration]
|
||||
* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m7-insufficient-binary-protection.html[Mobile Top 10 2024 Category M7 - Insufficient Input/Output Validation]
|
||||
* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m8-security-misconfiguration.html[Mobile Top 10 2024 Category M8 - Security Misconfiguration]
|
2
rules/S7204/metadata.json
Normal file
2
rules/S7204/metadata.json
Normal file
@ -0,0 +1,2 @@
|
||||
{
|
||||
}
|
Loading…
x
Reference in New Issue
Block a user