對某地鐵app的一次靜態掃描報告分析

本次分析從華爲應用中心(app-store)下載的某地鐵app
分析工具使用了源傘科技Pinpoint

掃描結果

共計找到122個致命問題， 148個嚴重問題 375箇中等問題以及 11537個建議改進問題。其中包括444個可能引發崩潰或異常的錯誤，277個安全隱私類問題以及897個執行效率低下問題。

現舉例以下：

安全隱私高危漏洞：

漏洞	路徑注入--該漏洞可使得惡意攻擊者覆蓋任意文件
位置	yedemo/zw.java，yedemo.zw.b函數 (應該是名稱混淆後的結果)

漏洞觸發大概邏輯以下：

void b(String var1) throws IOException {
      …
        // 1這裏打開了一個壓縮文件
      ZipFile var4 = new ZipFile(var1);
        // 2 這裏讀取壓縮文件的內容
      Enumeration var5 = var4.entries();
      …
      while(true) {
         ZipEntry var15;
         boolean var16;
         // 3 do-while循環找到一個不是文件夾的普通文件，並存儲到var15裏
         do {
            boolean var11 = var5.hasMoreElements();
            if (!var11) {
               var4.close();
               var3.delete();
               return;
            }
            var15 = var5.nextElement();
            var16 = var15.isDirectory();
         } while(var16);
         …
         String var9 = this.c;
         String var19 = var15.getName();
         // 4 這裏拼接了 var9 + var15.name, 做爲路徑打開文件，這裏this.c猜想是某地鐵的數據存儲路徑
         // 漏洞：若是zip文件中的文件名中特殊字符，好比」../../../system/system_config」就會覆蓋系統文件，有可能攻擊整個系統
         File var8 = new File(var9, var19);
         …
      }

這裏 ZipEntry.isDirectory函數定義以下：

這個沒法防護相似」../../../system/system_config」的而已輸入
File的構造函數以下：

這個也沒法防護傳給child的相似」../../../system/system_config」的惡意參數，說明中也有提示：

本漏洞屬於去年爆出的ZipSlip漏洞，這是一種任意覆蓋文件的漏洞，也就是說可以覆蓋現有文件。它是由目錄遍歷攻擊觸發的，攻擊者從歸檔文件（archive）解壓縮文件的同時，還能夠訪問受限制的目錄。顧名思義，這個安全漏洞不只與著名的ZIP格式等歸檔格式有關，還與其餘一些格式有關，包括tar、jar、war、cpio、apk、rar和7z。這個漏洞可能會致使這種情形：攻擊者能夠解壓縮日常解壓縮路徑以外的文件，覆蓋敏感文件，好比關鍵的操做系統庫或服務器配置文件。

漏洞	Null Pointer Exception：該漏洞可能致使程序閃退，拋空指針異常
位置	該漏洞跨越3個文件yedemo/aqv.java，yedemo/aqs.java yedemo/arc.java，跨越yedemo.aqv.a, yedemo.aqs.a, yedemo.arc.a3個函數 (應該是名稱混淆後的結果)

漏洞觸發大概邏輯以下：

yedemo.arc.a(var1) {
      …
      try {
         PackageManager var6 = var0.getPackageManager();
         byte var4 = 64;
         var7 = var6.getPackageInfo(var1, var4);
      } catch (NameNotFoundException var20) {
         return null;
      }
      …
If (var7.signature.length == 0) {
   return null;
}
}
這裏在發生異常或者signature長度爲0的時候能夠返回空指針

yedemo.aqs.a(var1) {
if (var1 != null) {
      …
          var14 = arc.a(var1, var1.getPackageName());
          xxx = aqv.a(var14);
          …
    }
}

   yedemo.aqs.a(var14) {
         …
         byte[] var3 = var14.getBytes();
         …
}

這裏arc.a的返回值var14直接傳給了aqv.a, 而後aqv.a直接使用了這個空指針，致使空指針異常

漏洞	代碼風格問題：使用string類型判等的時候要使用String.equals(), 直接使用等號或不等號斷定會致使和語義不一致的結果。
位置	com/indoor/navigation/navi/Navigation.java，com.indoor.navigation.navi.Navigation.a函數 (應該是名稱混淆後的結果)

正常來講，咱們期待String a =new String(」123」), 對於a==」123」應該要返回true。然而代碼使用== 或！=運算符比較的是java.lang.String對象的引用相等性而不是值得相等型，好比String a =new String(」123」), 對於a==」123」的斷定會返回false而不是按照字符串的值返回true。屬於很是危險的調用，應該使用String.equals()方法能夠肯定按照字符串實際的值來比較
例如：這段代碼的輸出是

'=' : False
'equals' : True

public class HelloWorld {
    public static void main(String[] args) {
        String a = new String("123");
        if(a == "123") {
            System.out.println("'=' : True");
        } else {
            System.out.println("'=' : False");
        }
        
        if(a.equals("123")) {
            System.out.println("'equals' : True");
        } else {
            System.out.println("'equals' : False");
        }
    }
}

一個觸發實例位置：com/indoor/navigation/navi/Navigation.java，com.indoor.navigation.navi.Navigation.a函數 (應該是名稱混淆後的結果)

爲國產靜態代碼分析工具源傘科技Pinpoint打Call!爲國產靜態檢測工具源傘科技Pinpoint打Call!