我在Context类中经历了checkCallingOrSelfPermission()并想知道它是如何被利用的;即,如果某个应用程序触发了被调用方/您的应用程序的方法,该方法又调用checkCallingOrSelfPermission(),最后将该权限授予其他应用程序,或者发布否则需要该权限的敏感信息。
这是我在浏览Java Doc后所理解的:
此方法只能由处于被调用者应用程序的同一进程中的任何调用应用程序利用。要进入相同的流程,除了同样的证书签名之外,两个应用程序还需要在清单文件中具有相同的shareuserid和进程。
因此调用应用程序需要执行以下操作。
必须知道callee应用程序正在运行的进程和共享用户标识。 (我不确定这有多可行?)
必须使用与被调用者申请签署的相同证书进行签名(不太可能认为证书是安全的)。
这是checkCallingOrSelfPermission()文档警告的利用方法,还是其他(更现实的)方法可以被利用。
我也查了this post,但答案并不理想。
答案 0 :(得分:2)
在正常情况下Binder.callingPid() == Process.myPid()
成立。这在处理IPC请求时发生变化,系统修改Binder
存储的调用PID 值,它将其分配给调用者应用程序的PID。但是,此更改仅影响执行远程调用方法的线程,在其他线程中,等式仍然存在。因此,如果在这样一个未受影响的线程中调用checkCallingOrSelfPermission()
,它将返回PERMISSION_GRANTED
(假设服务应用程序持有该权限)并且可能发生泄漏(或其他圣经后果)。
或者,如果在clearCallingIdentity()
之前调用checkCallingOrSelfPermission()
,则会出现同样的问题,但我认为不太可能发生。
在Nexus 6P,Android 6.0.1(MHC19I)上测试。
答案 1 :(得分:0)
一切都在代码中。
checkCallingOrSelfPermission()在IPC通话中是安全的。查看checkCallingOrSelfPermission()
和checkCallingPermission()
here的实施情况。它们都检查IPC客户端/呼叫者的权限。 当来电者来自外面时,他们完全一样!
如果调用者来自内部(相同的进程),那么,如果有人可以在您的进程内执行代码,那么它已经被利用了。无需再次利用checkCallingOrSelfPermission()
。