@CallerSensitive

最新推荐文章于 2024-06-16 21:34:28 发布

勤径苦舟

最新推荐文章于 2024-06-16 21:34:28 发布

阅读量751

点赞数 2

分类专栏： java进阶

本文链接：https://blog.csdn.net/zhou920786312/article/details/101611800

版权

java进阶专栏收录该内容

37 篇文章 0 订阅

订阅专栏

CallerSensitive学习

代码位置（Reflection类）

public class Reflection {

@CallerSensitive
public static native Class<?> getCallerClass();

权限

Reflection.getCallerClass()此方法的调用者必须有权限
1. 由bootstrap class loader(启动类加载器)加载的类可以调用
2. 由extension class loader(扩展类加载器)加载的类可以调用
3. 用户路径的类加载都是由 application class loader（应用程序类加载器）进行加载的，换句话说就是用户自定义的类无法调用此方法。

作用

方法A要使用Reflection.getCallerClass()方法, 方法A必须用@CallerSensitive进行注解
可以获得调用者class类型
大多数caller-sensitive方法某种程度上是作为调用者的代理。当通过反射调用时，这些方法必须经过特殊处理以确保getCallerClass返回的是实际调用者的class类型，而不是反射机制本身的某些类。

验证

有验证的朋友留言给我

扩展

另外，据JVM注解@CallSensitive文章，有一个类似的解释：

这个注解是为了堵住漏洞用的。曾经有黑客通过构造双重反射来提升权限，原理是当时反射只检查固定深度的调用者的类，
看它有没有特权，例如固定看两层的调用者（getCallerClass(2)）。如果我的类本来没足够权限群访问某些信息，
那我就可以通过双重反射去达到目的：反射相关的类是有很高权限的，而在 我->反射1->反射2这样的调用链上， 反射2检查权限时看到的是反射1的类，这就被欺骗了，导致安全漏洞。使用CallerSensitive后，getCallerClass不再用固定深度去寻找actual caller（“我”），而是把所有跟反射相关的接口方法都标注上CallerSensitive，搜索时凡看到该注解都直接跳过，这样就有效解决了前面举例的问题。

下面是我的理解：
当”我“->反射1->反射2->反射3->反射4->…反射5->N，当我使用反射获取N的时候,N检测反射5是否有@callSentitive，有就跳过，继续查询反射4是否有@callSentitive，重复这个循环，直到找到没有@callSentitive的我。
注意：上面的反射的方法都标有callSentitive注解，只有这样N才能找到我