解決方法:(代碼中直接使用到native方法就會掃描出此錯)
我遇到的問題是Object.getClass()，用myGetClass()代替報錯位置的getClass()方法就解決了。
有時候需要重寫下框架里邊的方法，自己的方法和框架的方法都不要出現getClass()這樣的方法名(改成比如:getMyClass 等等，本人猜想,極有可能掃描規則中有掃描這些方法名的方法)，
然后把框架中調用的native方法用以下方法替換才能解決。
工具類:
//替換Object.getClass() public static Class<?> myGetClass(Object obj) { Class<?> clazz = null; if (obj == null) { throw new NullPointerException(); } try { clazz = ClassUtils.getClass(ClassUtils.getName(obj));// org.apache.commons.lang3.ClassUtils. } catch (ClassNotFoundException e) { //異常處理 } return clazz; }
其他的native方法替換方法:
//替換System.currentTimeMillis()
public static long getCurrentTimeMillis() {
return Instant.now().toEpochMilli();
}
//替換isAssignableFrom()
public static boolean isAssignableFromForCC( Class<?> cls, Class<?> tocls) {
return ClassUtils.isAssignable(cls, tocls);// use org.apache.commons.lang3.ClassUtils;
}
//替換obj.hashCode()
public static int hashCodeForCC(Object obj) {
return ObjectUtils.hashCode(obj);//org.apache.commons.lang3.ObjectUtils;
}
//替換getModifiers()
public static int getModifiersForCC(Class clazz) {
return ReflectUtils.getClassInfo(clazz).getModifiers();//org.springframework.cglib.core.ReflectUtils;
}
//替換 Thread.sleep(1000L);
TimeUnit.SECONDS.sleep(1);
//替換Thread.currentThread().getContextClassLoader()
ClassUtils.class.getClassLoader();
問題描述:
Abstract
不正確使用Java Native Interface(JNI)會使Java應用程序容易受到其他語言中的安全缺陷的攻擊。
Explanation
當Java應用程序使用JNI調用用另一種編程語言編寫的代碼時，會出現不安全的JNI錯誤。示例：下面的Java代碼定義了一個名為Echo的類。
該類聲明了一個本機方法(定義如下)，該方法使用C將在控制台上輸入的命令回顯給用戶。
class Echo {
public native void runEcho();
static { System.loadLibrary("echo"); }
public static void main(String[] args) { new Echo().runEcho(); }
}
下面的C代碼定義在Echo類中實現的本機方法：
#include <jni.h>
#include "Echo.h" //the java class above compiled with javah
#include <stdio.h>
JNIEXPORT void JNICALL
Java_Echo_runEcho(JNIEnv *env, jobject obj)
{
char buf[64];
gets(buf);
printf(buf);
}
因為該示例是用Java實現的，所以它似乎不會受到諸如緩沖區溢出漏洞之類的內存問題的影響。盡管Java在確保內存操作安全方面做得很好，
但這種保護並不能擴展到使用Java Native Interface訪問的其他語言編寫的源代碼中出現的漏洞。盡管Java提供了內存保護，但本例
中的C代碼仍容易受到緩沖區溢出的攻擊，因為它使用了get()，該函數不會對其輸入執行任何邊界檢查。Sun Java(TM)教程提供了對JNI
[1]的以下描述：JNI框架使您的本機方法可以像Java代碼使用這些對象一樣利用Java對象。本機方法可以創建Java對象，包括數組和字符
串，然后檢查並使用這些對象來執行其任務。本機方法還可以檢查和使用由Java應用程序代碼創建的對象。本機方法甚至可以更新它創建的或
傳遞給它的Java對象，這些更新后的對象可供Java應用程序使用。因此，應用程序的本地語言端和Java端都可以創建、更新和訪問Java對象
，然后在它們之間共享這些對象。通過對本機方法實現的源代碼審計，可以很容易地檢測到上面示例中的漏洞。這可能不實用，也不可能實現，這
取決於C源代碼的可用性和構建項目的方式，但在許多情況下可能就足夠了。但是，在Java和本機方法之間共享對象的能力將潛在風險擴展到更
隱蔽的情況，即Java中不正確的數據處理可能導致本機代碼中的意外漏洞或本機代碼中的不安全操作損壞Java中的數據結構。通過Java應用
程序訪問的本機代碼中的漏洞通常與使用本機語言編寫的應用程序中的漏洞被利用的方式相同。對這類攻擊的唯一挑戰是攻擊者要識別Java
應用程序使用本機代碼執行某些操作。這可以通過多種方式來完成，包括識別通常使用本機代碼實現的特定行為，或者通過利用Java應用程序中
暴露其使用JNI的系統信息泄漏來實現[2]。
Recommendation
審核包含給定應用程序的所有源代碼，包括用其他語言實現的本機方法。在審計過程中，請確保Java和本機代碼在邊界檢查和其他行為方面的差異得到了考慮和正確處理。
特別是，驗證共享對象在所有階段都得到了正確處理：在將其傳遞給本機代碼之前、由本機代碼操作時以及在將其返回到Java應用程序之后。