Android Java项目Fortify扫描报不安全反序列化问题求助

Hey there, this false positive is super common when running Fortify scans on Android launch activities—let's walk through why it might be happening and how to fix it.

First: Understand the Likely False Positive Trigger #

Your LaunchScreen is just a standard launcher activity with no explicit Java serialization code, right? Fortify's static analysis rules often get confused between Android's Parcelable (used for Intent/Bundle data) and Java's native Serializable (the target of the Unsafe Deserialization rule).

Android's component lifecycle relies on Parcelable for passing data between components, which is a safe, platform-specific serialization mechanism—totally different from the risky Java deserialization Fortify flags. The scanner might be incorrectly associating your activity's intent handling with Java deserialization logic.

Step 1: Rule Out Hidden Serialization Usage #

Before writing this off as a false positive, double-check for any indirect serialization calls in your code or dependencies:

• Check your LaunchScreen code: Look for calls like getIntent().getSerializableExtra(...)—even if you're just retrieving a serializable object, Fortify might flag this.
• Third-party SDKs: Some analytics, crash reporting, or configuration libraries might run deserialization logic during app launch (in your launcher activity's lifecycle). Review the dependencies you're using and their initialization code.
• Serializable members: Does your LaunchScreen class (or any parent class you've extended) implement Serializable, or hold references to classes that do? Fortify's rules might trigger on this association even if you don't use the serialization directly.

Step 2: Fixes & Workarounds #

If it's a confirmed false positive

• Mark as False Positive in Fortify: Go into your Fortify report, select this issue, and mark it as a false positive with a clear explanation: "Android launcher activity; uses only platform-safe Parcelable for intent data, no Java deserialization logic implemented."
• Customize Fortify Scan Rules: Add an exclusion rule to skip Unsafe Deserialization checks for classes with the LAUNCHER intent filter. This prevents the same false positive from popping up in future scans.

If you do have hidden Serializable usage

• Switch to Parcelable: Android recommends Parcelable over Serializable for performance and safety. Refactor any serializable data classes to implement Parcelable instead, and use getParcelableExtra(...) to retrieve them from intents.
• Add Class Whitelisting: If you must use Serializable, follow Fortify's core recommendations to validate deserialized objects:

  Object receivedObj = getIntent().getSerializableExtra("my_key");
  // Validate the object type against a strict whitelist
  if (receivedObj instanceof MyTrustedSerializableClass) {
      MyTrustedSerializableClass safeObj = (MyTrustedSerializableClass) receivedObj;
      // Proceed with safe handling
  } else {
      // Reject unexpected types to prevent misuse
      throw new IllegalArgumentException("Invalid serializable type received");
  }
  

  This aligns with Fortify's advice to use whitelists for allowed deserialization types, ensuring only trusted classes are processed.

Quick Recap of Fortify's Guidance (Adapted for Android) #

Fortify's core warnings about unsafe deserialization are valid for Java applications, but Android's ecosystem uses different serialization mechanisms:

• Avoid untrusted Java deserialization entirely where possible (stick to Parcelable for component communication).
• If you must use Serializable, always validate the incoming object's type against a known safe whitelist.
• For third-party libraries, ensure their deserialization logic is secured (e.g., not exposed to untrusted inputs, uses encryption/integrity checks if data is transmitted over networks).

内容的提问来源于stack exchange，提问作者felix