【问题标题】:android - broadcast receiver - caller verificationandroid - 广播接收器 - 调用者验证
【发布时间】:2014-10-30 17:37:40
【问题描述】:

我正在编写一个 Android 应用程序,其中我需要接收系统发送的一些广播。我想确保广播确实是由系统发送的。我找到了这个 OWASP video

在视频中的 18:00 时间,演讲者建议验证广播来源的方法之一是使用(查看他的幻灯片):

 Binder.getCallingUid () == Process.SYSTEM_UID

我尝试在我的应用程序中对此进行测试,但这个 API 为我提供了我自己的应用程序的 uid。

我从 Dianne Hackborn 找到了这个 explanation

 Binder.getCallingUid() returns the UID of the caller when processing 
 an incoming Binder IPC.  The value that is returned will vary depending 
 on whether you are in the context of dispatching an incoming IPC or 
 something else.

 Also, code will often call Binder.clearCallingIdentity() to clear the 
 calling information after it has verified it so that further operations
 are considered to be coming from the current uid.

另外,来自docs

 Return the Linux uid assigned to the process that sent you the current 
 transaction that is being processed. This uid can be used with 
 higher-level system services to determine its identity and check permissions. 
 If the current thread is not currently executing an incoming transaction, 
 then its own uid is returned.

鉴于这两个解释,APIBinder.getCallingUid在Android组件的生命周期事件中是否有任何用途(我在BroadcastReceiver的onReceive,Service的onStartCommand中测试过)?

如果不是,为什么 OWASP 要求我们使用它?

【问题讨论】:

  • this 是否相关?我想知道为什么 BroadcastReceiverContentProvider 之间的 API 如此不同,但据我所知,没有 BroadcastReceiver.getCallingPackage() 或等效的。 :(
  • 您找到解决方案了吗?

标签: android android-intent android-broadcast android-binder


【解决方案1】:

this document 的第 5 节解释了为什么 Binder.getCallingUid() 在BroadcastReceiver 中没有用处。它只返回执行自己的应用程序的 UID。但如果您正在调用远程服务,它会返回一个有用的值,例如使用 AIDL 绑定服务时。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多