精华内容
下载资源
问答
  • 自定义权限
    2021-05-27 01:52:25

    最近在研究关于android自定义权限的问题,关于自定义权限一般是保证APP的安全性,那么什么事自定义权限?今天我们来补充一下自己的知识

    1、如何声明自定义权限

    在Manifest文件中使用Permission标签定义自己的权限:

    <?xml  version="1.0" encoding="utf-8"?>        ...

    解释下各个属性:

    name,该标签就是权限的名字。

    description,该标签就是权限的介绍。

    permissionGroup,指定该权限的组。

    protectionLevel,指定保护级别。

    Android将权限分为若干个保护级别,normal, dangerous, signature等。normal就是正常权限,该权限并不会给用户或者设备的隐私带来风险;dangerous就是危险权限,该级别的权限通常会给用户的数据或设备的隐私带来风险;signature指的是,只有相同签名的应用才能使用该权限。更多的介绍可以参考protectionLevel。

    2、使用场景

    自定义权限一般用于暴露出去的组件,提高安全性。Android允许一个应用(客户端)调用另一个应用(服务端)的组件。那么作为服务端的应用就得暴露相应的组件,客户端应用才能访问。当然,在暴露的时候,权限是非必须的,如果暴露的组件没有权限的话,那么任何的其他应用都可以来调用该组件;如果该组件申请了权限,那么只有拥有该权限的应用才能调用该组件。

    exported属性就是代表是否暴露。该例子并没有要求调用者需要申请权限,也就是说,任何的应用就可以调用才组件。如果每个应用都可以调用我们的组件的话,显然是不安全的,我们希望只有使用了我们的权限的应用,才能调用我们暴露的组件,我们可以在activity中加入permission属性。

    Intent intent = new Intent();intent.setClassName("com.bright.permission", "com.bright.permission.TestA_Activity");startActivity(intent);

    除了上面的方式,还可以通过intent-filter隐式启动:

    Intent intent = new Intent();intent.setAction("com.bright.permission.action.TEST");startActivity(intent);

    3、自定义权限注意点

    3.1、两个应用声明了相同的权限

    Android不允许两个不同的应用定义一个相同名字的权限(除非这两个应用拥有相同的签名),所以在命名的时候,需要特别注意。

    拥有相同自定义权限的软件必须使用同样的签名,否则后一个程序无法安装。

    3.2、和应用安装顺序的关系。

    场景:App A中声明了权限PermissionA,App B中使用了权限PermissionA。

    情况一:PermissionA的保护级别是normal或者dangerous

    App B先安装,App A后安装,此时App B无法获取PermissionA的权限,从App B打开App A会报权限错误。

    App A先安装,App B后安装,从App B打开App A一切正常。

    情况二:PermissionA的保护级别是signature或者signatureOrSystem

    App B先安装,App A后安装,如果App A和App B是相同的签名,那么App B可以获取到PermissionA的权限。如果App A和App B的签名不同,则App B获取不到PermissionA权限。

    即,对于相同签名的app来说,不论安装先后,只要是声明了权限,请求该权限的app就会获得该权限。

    这也说明了对于具有相同签名的系统app来说,安装过程不会考虑权限依赖的情况。安装系统app时,按照某个顺序(例如名字排序,目录位置排序等)安装即可,等所有app安装完了,所有使用权限的app都会获得权限。

    3.3、权限的获取以及版本兼容

    Android6.0引入了动态权限,这个大家都知道了。前面说到的自定义的权限的安全级别android:protectionLevel会影响权限在Android6.0+系统的使用

    android:protectionLevel="normal",不需要动态申请

    android:protectionLevel="dangerous",需要动态申请

    阅读我的更多文章

    欢迎关注我微信公众号:终端研发部,一起交流和学习

    更多相关内容
  • 本文记录使用django自带的认证系统实现自定义权限管理系统,包含组权限、用户权限等实现。 0x01. django认证系统 django自带的认证系统能够很好的实现如登录、登出、创建用户、创建超级用户、修改密码等复杂操作,...
  • 主要介绍了Android权限控制之自定义权限,本文使用两个APP作为范例,讲解如何自定义权限,需要的朋友可以参考下
  • 主要介绍了详解Android自定义权限使用总结,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • django自带的认证系统能够很好的实现如登录、登出、创建用户、创建超级用户、修改密码等复杂操作,并且实现了用户组、组权限、...我的问题是,如果我要为用户模型添加自定义权限,该怎么办?像foo.can_view.我可以用下
  • android自定义权限

    2014-11-01 18:05:40
    该资源包含了一个android自定义权限,包含两个工程security和securitytest,其中,security声明自定义权限,在securitytest中利用这些自定义权限,包含了自定义的activity,service,contentprovider,发送和...
  • 此项目包含需要特殊权限才能访问的Activity 博文链接:https://byandby.iteye.com/blog/1028034
  • Android自定义权限

    千次阅读 2021-11-01 14:38:37
    自定义权限的步骤如下: 一、在AndroidManifest文件中,添加一个permission标签: <permission android:description="string resource" android:icon="drawable resource" android:label="string ...

            Android应用程序可以自定义属于自己的权限或者属于开发者使用的同一个签名的权限。自定义权限的步骤如下:

    一、在AndroidManifest文件中,添加一个permission标签:

    <permission 
        android:description="string resource"  
        android:icon="drawable resource"  
        android:label="string resource"  
        android:name="string"  
        android:permissionGroup="string"  
        android:protectionLevel=["normal" | "dangerous" |   "signature" | "signatureOrSystem"] /> 

    android:name :权限的唯一标识,一般使用包名+权限名;
    android:permissionGroup: 权限所属权限组的名称;
    android:protectionLevel: 权限的等级:
            normal 是最低的等级,声明此权限的app,系统会默认授予此权限,不会提示用户;
            dangerous  权限对应的操作有安全风险,系统在安装声明此类权限的app时会提示用户;
            signature  权限表明的操作只针对使用同一个证书签名的app开放;
            signatureOrSystem  与signature类似,只是增加了rom中自带的app的声明。

    android:name 属性是必须的,其他的可选,未写的系统会指定默认值。

    二、具体使用范例:

    1. 创建一个工程CustomPermission,新建两个活动,主活动对应的布局文件如下

    <?xml version="1.0" encoding="utf-8"?>
    <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        xmlns:tools="http://schemas.android.com/tools"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        tools:context=".MainActivity">
    
        <TextView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="OneProject"
            android:textSize="12pt"
            android:gravity="center"
            android:layout_centerInParent="true" />
    
        <Button
            android:id="@+id/intent_button"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Intent"
            android:textSize="10pt"
            android:layout_alignParentRight="true"
            android:layout_alignParentBottom="true"/>
    </RelativeLayout>

    2. 第二个活动对应的布局文件如下:

    <?xml version="1.0" encoding="utf-8"?>
    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
        android:orientation="horizontal"
        android:layout_width="match_parent"
        android:layout_height="match_parent">
    
        <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="添加权限才能看到我!!!"
            android:layout_gravity="center_vertical"
            android:gravity="center"
            android:textSize="12pt"/>
    
    </LinearLayout>

    3. 在配置文件中自定义权限,并对第二个活动添加权限:

    <?xml version="1.0" encoding="utf-8"?>
    <manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.example.custompermission">
    
        <permission
            android:name="com.example.custompermission.get2view"
            android:protectionLevel="signature"/>
    
        <application
            android:allowBackup="true"
            android:icon="@mipmap/ic_launcher"
            android:label="@string/app_name"
            android:roundIcon="@mipmap/ic_launcher_round"
            android:supportsRtl="true"
            android:theme="@style/Theme.CustomPermission">
            <activity
                android:name=".MainActivity2"
                android:permission="com.example.custompermission.get2view"
                android:exported="true">
                <intent-filter>
                    <action android:name="com.example.custompermission.get2view" />
                    <category android:name="android.intent.category.DEFAULT" />
                </intent-filter>
            </activity>
            <activity
                android:name=".MainActivity"
                android:exported="true">
                <intent-filter>
                    <action android:name="android.intent.action.MAIN" />
                    <category android:name="android.intent.category.LAUNCHER" />
                </intent-filter>
            </activity>
        </application>
    
    </manifest>

    4. 主活动代码如下:

    package com.example.custompermission;
    
    import androidx.appcompat.app.AppCompatActivity;
    
    import android.content.Intent;
    import android.os.Bundle;
    import android.view.View;
    import android.widget.Button;
    
    public class MainActivity extends AppCompatActivity {
    
        private Button button;
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            button = (Button) findViewById(R.id.intent_button);
            button.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View view) {
                    Intent intent = new Intent();
                    intent.setAction("com.example.custompermission.get2view");
                    startActivity(intent);
                }
            });
        }
    }

    运行工程CustomPermission:在主活动点击INTENT按钮,跳转第二个活动可以正常跳转。

          

     结论:对于同一个工程,活动之间进行跳转,即便不添加权限申请也可以。

    5. 创建另一个工程UsePermission,主活动里放置一个按钮,用于跳转CustomPermission工程的第二个活动,对应布局文件如下:

    <?xml version="1.0" encoding="utf-8"?>
    <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        xmlns:tools="http://schemas.android.com/tools"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        tools:context=".MainActivity">
    
        <TextView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="TwoProject"
            android:textSize="12pt"
            android:gravity="center"
            android:layout_centerInParent="true"/>
    
        <Button
            android:id="@+id/intent_button"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Intent"
            android:textSize="10pt"
            android:layout_alignParentRight="true"/>
    
    </RelativeLayout>

     6. 主活动代码如下:

    package com.example.usepermission;
    
    import androidx.appcompat.app.AppCompatActivity;
    
    import android.content.Intent;
    import android.os.Bundle;
    import android.view.View;
    import android.widget.Button;
    
    public class MainActivity extends AppCompatActivity {
    
        private Button button;
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            button = (Button) findViewById(R.id.intent_button);
            button.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View view) {
                    Intent intent = new Intent();
                    intent.setAction("com.example.custompermission.get2view");
                    startActivity(intent);
                }
            });
        }
    }

     (1)不在配置文件里申请访问CustomPermission工程的第二个活动的权限,点击跳转按钮Logcat窗口报错:

    java.lang.SecurityException: Permission Denial: starting Intent

    (2)在配置文件里申请访问权限:

    <?xml version="1.0" encoding="utf-8"?>
    <manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.example.usepermission">
    
        <uses-permission android:name="com.example.custompermission.get2view"/>
        <application
            android:allowBackup="true"
            android:icon="@mipmap/ic_launcher"
            android:label="@string/app_name"
            android:roundIcon="@mipmap/ic_launcher_round"
            android:supportsRtl="true"
            android:theme="@style/Theme.UsePermission">
            <activity
                android:name=".MainActivity"
                android:exported="true">
                <intent-filter>
                    <action android:name="android.intent.action.MAIN" />
                    <category android:name="android.intent.category.LAUNCHER" />
                </intent-filter>
            </activity>
        </application>
    
    </manifest>

    运行程序,点击跳转按钮的效果如下:

       

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 一、自定义权限与使用在用户app中,自定义权限往往设定在 四大组件上Activity,Service,BroadcastReceiver,ContentProvider,作为app的一部分,如果不允许组件被其他调用,设置权限也是一种保护方式。在这里我们以...

    一、自定义权限与使用

    在用户app中,自定义权限往往设定在 四大组件上Activity,Service,BroadcastReceiver,ContentProvider,作为app的一部分,如果不允许组件被其他调用,设置权限也是一种保护方式。

    在这里我们以BroadcastReceiver为例,假定其属于appA:

    package test.common.home;

    public class StickyBroadcastReceiver extends BroadcastReceiver

    {

    public static final String Action = "com.sample.test.sticky.broadcast.receiver";

    public static final String PERMISSION = "com.sample.test.permission.sticky.receiver";

    @Override

    public void onReceive(Context context, Intent intent)

    {

    int checkCallingOrSelfPermission = context.checkCallingOrSelfPermission(PERMISSION);

    //权限的检测(实际上,这种检测系统会自动检测,如果通过的话才会调用onReceive方法,我们这里特意指出,就是为了明白系统检测方式是怎样的)

    //如果要检测出2种效果,只能使用该BroadcastReceiver自身应用来实现,因为自身应用没权限也可访问该广播

    if(PackageManager.PERMISSION_GRANTED == checkCallingOrSelfPermission)

    {

    Toast.makeText(context, "授权成功", Toast.LENGTH_SHORT).show();

    }else{

    Toast.makeText(context, "授权失败", Toast.LENGTH_SHORT).show();

    }

    if(intent!=null&&Action.equals(intent.getAction()))

    {

    Toast.makeText(context, intent.getStringExtra("info"), Toast.LENGTH_SHORT).show();

    }

    }

    }

    在到Manifest.xml文件中注册

    首先自已权限并使用自定义权限

    然后注册广播

    android:exported="true"

    android:permission="com.sample.test.permission.sticky.receiver" >

    属性说明

    android:exported="true" --->是否外部允许访问,低版本中默认是true,高版本默认是false,请注意

    android:permission="com.sample.test.permission.sticky.receiver" --->外部访问是需要检测的权限

    然后我们创建appB,在appB中创建一个Activity用来发送广播:

    Intent intent = new Intent(StickyBroadcastReceiver.Action);

    intent.putExtra("info", "hello world");

    sendBroadcast(intent);

    二、自定义权限测试

    测试一:将appA中的StickyBroadcastReceiver设置为android:exported设置为false,不设置权限android:permission

    测试结果,发送广播失败:

    Permission Denial: Accessing service ComponentInfo

    java.lang.SecurityException: Not allowed to bind to service Intent

    测试二:将appA中的StickyBroadcastReceiver设置为android:exported=true,不设置权限android:permission

    测试结果:

    广播接收正常

    测试三:将appA中的StickyBroadcastReceiver设置为android:exported设置为true,设置权限android:permission="com.sample.test.permission.sticky.receiver"

    在appB中不设置

    测试结果

    Permission Denial

    测试四:在测试三的基础上在AppB设置

    测试结果:广播接收正常

    379c0b6b5415934813f1d17fe178bb6a.png    

    d39804da6a549fe0e31c11b11a815488.png

    由上可知,权限运行正常,所以你可以试试了。

    附加:

    android:protectionLevel --->保护级别,看这里http://www.xuebuyuan.com/1873075.html

    try doing it!

    展开全文
  • 易语言动态自定义权限设置源码,动态自定义权限设置,登陆检测,初始菜单,系统初始化,版本,加密程序,本机硬盘特征字,检测,提示信息框,记录操作事件,限制,自定义菜单,自定窗口程序,拆分整数,执行窗口程序,置窗口特征,取...
  • 本文源于对山东大学网络空间安全学院李蕊博士的 IEEE 论文:Android 自定义权限揭秘:从权限提升到设计缺陷 的分析,旨在学习 Android 自定义权限机制的安全风险和攻击模式。

    前言

    本文源于对山东大学网络空间安全学院李蕊博士的 IEEE 论文:Android 自定义权限揭秘:从权限提升到设计缺陷 的分析,旨在学习 Android 自定义权限机制的安全风险和攻击模式。

    由 InForSec 主办的“移动互联网安全”论坛上,作者对该研究进行了分享,InForSec 已上传会议视频至 Bilibili :山东大学李蕊博士:Android自定义权限机制安全性分析
    在这里插入图片描述

    【InForSec 的会议纪要】 李蕊博士介绍了安卓中的两种权限:一种是系统权限,由系统 app 声明,保护系统资源;另一种是自定义权限,由第三方 app 声明,保护 app 资源。
    以往工作对自定义权限的研究十分欠缺,李博士根据发现的自定义权限的威胁模型,将研究目标总结为:分析安卓系统中自定义权限机制的设计与实现,自动化检测其安全漏洞和设计缺陷。

    李博士团队设计了自动化黑盒模糊测试工具 CuPerFuzzer ,对爬取的 17 万多个 APK 进行 Fuzz 并发现了多个 Android 系统高危的 CVE 漏洞,会议中重点分享了 CVE-2020-0148 和 CVE-2021-0317 漏洞原理与攻击效果演示。

    自定义权限早期漏洞

    正式开始介绍 Android 自定义权限的漏洞之前,先来简单下 Android 的权限机制。北京理工大学:Android自定义权限及其设计缺陷-陆永鑫.pdf 这篇文章里作者详细分析(感谢分享)了李蕊博士的研究论文的前世今生,本文很多材料借鉴该文,特此说明。

    1.1 Android权限机制

    关于 Android 的权限机制,百度搜一下一堆文章……此处不想赘述,直接引用上面提到的北理工公开材料。
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    1.2 自定义权限升级漏洞

    陆永鑫硕士总结了 Android 自定义权限的历史安全研究:
    在这里插入图片描述

    在这里插入图片描述
    Tuncay 的论文获取:Resolving the Predicament of Android Custom Permissions,此处附上一篇论文解读:CustomPermission

    下面介绍下他提到的第一类漏洞—— Android 自定义权限升级(custom permission upgrade)。该漏洞使得攻击者可在未经过用户交互的情况下,直接获取 dangerous 级别的系统权限。

    下图总结了该漏洞的攻击场景:
    在这里插入图片描述
    在这里插入图片描述
    攻击步骤

    1. 首先攻击者创建一个 app,声明一个自定义权限,级别为 normal 或 signature,并且将自定义权限设置为系统权限组的一部分(如存储,或照相机);
    2. 攻击者更新此自定义权限的定义,将保护级别更改为 dangerous,并继续在相应的应用市场上推送其应用的更新,此时攻击者 app 将自动获取授权,同时自动获取同组其他危险权限,而不会告知用户。

    漏洞原理

    1. Android 处理自定义权限的方式与系统权限相同,对于 normal 和 signature 级别的权限在安装时授予,而对于传统应用程序(SDK<23),dangerous 权限也在安装时授予,但对于新应用程序(SDK>23),则在运行时被授予;
    2. 当 System 系统权限从安装时授予变成运行时授予,意味着 这个 app 升级到了 SDK 23 以上,当 Custom 自定义权限升级,暗示着这个 app 有可能升级了,也有可能权限级别从 normal、signature 变成了dangerous ,但是系统并不具备区分这两种情况的能力
    3. 当恶意应用 app-test 更新修改了自定义权限声明,使保护级别从正常或签名变为危险时,系统错误地将这种情况视为系统应用程序的升级,并尝试升级现有的权限到运行时权限,则攻击者可在未经过用户交互的情况下,直接获取 dangerous 级别的系统权限。

    官方补丁

    系统可以以检查其源包是否是系统应用程序的方式判断一个权限是否是系统权限。若是自定义权限,则当权限保护级别从正常或签名变为危险时,系统将保持原有的保护级别

    1.3 confused deputy attack

    Tuncay 发现的第二类漏洞:confused deputy attack(混淆代理攻击)。

    该漏洞可以使操作系统向攻击应用授予被攻击应用的签名级自定义权限(俩应用为不同证书签名),以此获取对被攻击应用组件的未经授权的访问。Google 承认这是高危漏洞,因为它绕过了隔离应用程序数据与其他应用程序的操作系统保护。

    下图总结了该漏洞的攻击场景:
    在这里插入图片描述
    攻击步骤

    1. 攻击者创建两个 app,definer app A 自定义一个名称为 N 的权限,但将保护级别设置为 dangerous,attack app 仅在清单中请求该权限 N;
    2. Definer app 需要先由用户安装,然后安装 attack app,在运行时将 definer app 的欺骗权限授予 attack app 后,definer app 可由用户卸载或由应用程序开发人员更新,以便事后安装被攻击应用;
    3. 安装被攻击 app 后,attack app 能够向受害者发起攻击,以便自由访问被攻击 app 的受到签名保护的组件,即使它未使用与被攻击 app 相同的应用程序证书进行签名。

    漏洞原理

    1. 在更新或卸载 app 时,系统并不立即更新原有的自定义权限,而是在重新声明具有相同名称的新权限时撤销;
    2. 由于 Android 在权限执行期间仅使用权限名称,因此无法区分具有相同声明名称的两个不同权限。因此,持有“暂时休眠”危险权限的应用程序会以未授权的方式访问受同名 signature 权限保护的组件。

    官方补丁

    授予签名权限之前加入检查过程,这一检查确保请求签名权限的应用程序与定义此权限的应用程序由相同的证书签名。

    自定义权限近期漏洞

    山东大学李蕊博士及其团队认为 Tuncay 发现的 Android 系统自定义权限漏洞即为可能属于冰山一角,需要一个自动分析工具来对 Android 系统的自定义权限机制进一步进行深入探测。最终目标应该是识别存在于权限框架中的设计缺陷,而不仅仅是已成功发现的个别攻击案例。

    2.1 黑盒Fuzz工具原理

    受 Tuncay 所发现的动机案例的启发,李蕊等人将分析过程抽象为特定 APP、特定操作的执行顺序(序列),目的是寻找能触发权限升级漏洞的序列,而权限机制的内部操作可以被视作一个黑盒,设计了自动化黑盒模糊测试工具 CuPerFuzzer

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    解释下测试用例构建

    应用安装,应用卸载,应用升级,系统升级,这四种操作都可能触发系统更新赋权状态:

    • 安装应用可能会导致加入新的自定义权限;
    • 卸载应用可能会导致已有的自定义权限被删除;
    • 升级应用可能使自定义权限更新或删除;
    • 系统升级中可能会加入或删除已有系统的权限;

    应用升级操作的基本原理是多次安装不同版本。使用 adb 和 fastboot 控制和系统升级,使用控制多台测试实现设备并行测试。

    CuPerFuzzer最终的实验成果

    李蕊团队使用 4 部 Pixel 2 手机,40195 个测试案例,耗时 319.3 小时(约13.3天),平均一个测试用例执行了 114.4s。

    最终,CuPerFuzzer 发现了 2,384 个测试用例触发了特权提升,包括 30 条关键路径。
    在这里插入图片描述
    最终将发现的漏洞概括为以下几类:
    在这里插入图片描述
    下面会介绍下已分配 CVE 编号的前四个漏洞的漏洞信息与原理。

    2.2 悬空的自定义权限

    该漏洞编号为 CVE-2021-0307,漏洞原理:

    1. 当一个 APP 卸载或更新, PackageManager(PMS)会刷新所有权限的注册和授予状态;
    2. 如果一个危险级别的自定义权限定义被删除,系统也会从APP中撤销它的授权;
    3. 但是,如果被移除的自定义权限是安装时权限(普通/ 签名),则会保留相应的应用权限授予状态,导致权限悬空。

    导致权限悬空的流程图如下所示:
    在这里插入图片描述
    漏洞攻击步骤:
    在这里插入图片描述
    在这里插入图片描述

    步骤简单解析:

    1. app-ds1-d 应用声明 com.test.cp 为普通权限并列入 PHONE 权限组,另外应用 app-ds1-r 请求这个权限;
    2. 之后 app-ds1-d 应用将自己的权限升级由于为危险等级,安装应用后 PMS 进行了重新授权,由于 CALL_PHONE 和 com.test.cp 都是 PHONE 组,app-ds1-r 就可以在用户不能在电话的情况下获得 CALL_PHONE 权限。

    漏洞修复

    当系统删除自定义权限时,它对所有 APP 的授权应该被撤销。

    2.3 不一致的权限组映射

    该漏洞的漏洞编号为 CVE-2020-0418,该漏洞可以导致应用未经用户授权的情况下,获得所有系统危险权限。

    漏洞成因

    Android 所有 dangerous 权限都是基于组进行管理,如果应用已经获得了某一组里的某个权限,当它请求该组里的其它权限时会被自动授权。然而,李瑞团队发现系统权限和自定义权限的权限组信息是根据不同的机制来获取的,这导致 dangerous 系统权限的《权限-权限组》映射关系存在不一致。

    1. 系统权限是依据 platfrom_permission 资源文件(比如位于 /system/etc/permissions 路径下的 platform.xml)来定义其《权限-权限组》 映射关系的;
    2. 自定义权限则是由 PackageManagerService(即PMS服务)通过系统 app 里面的 AndroidMainfest.xml 文件来获取其 《权限-权限组》的映射关系;
    3. 李蕊发现系统核心 app 所定义的 dangerous 权限都是都放在一个特殊的权限组中,命名为 android.permission- group.UNDEFINED

    利用该不一致和放入 UNDEFINED 组中的 dangerous 级别的自定义权限,应用能够未经许可得到所有 dangerous 级别的系统权限。
    在这里插入图片描述
    具体的攻击场景可用下图表示:
    在这里插入图片描述
    在这里插入图片描述

    攻击步骤解析:

    1. 给手机安装一个应用 test,赋予它一个系统 dangerous 级别的权限 WRITE_EXTERNAL_STORAGE(外部存储空间的写权限);
    2. 安装 test_update app 来对 test app 进行升级,升级包中定义了一个危险权限 com.test.cp 且权限组定义为 UNDEFINED,同时在 AndroidManifest.xml 文件中 <uses-permission> 写入所有系统危险权限;
    3. 在 test app 中请求 com.test.cp 权限,结果竟是无弹窗给用户确认,然而却可以发现 test app 已经获得系统所有危险权限。

    以上操作会将所有的系统危险权限也都映射到了 UNDEFINED 权限组中,而由于 test app 已经获得WRITE_EXTERNAL_STORAGE权限,那么其他系统危险权限自然也就都能获得。

    官方补丁

    官方补丁信息:CVE-2020-0418,删除了未定义权限组:android.permission-group.UNDEFINED

    2.4 自定义权限提升漏洞

    该漏洞编号为:CVE-2021-0306,它可以使得恶意 app 可以在进行 Android 系统版本升级过程中无需用户同意,直接获得高版本操作系统新增的危险权限的能力。

    漏洞成因

    相比于 Tuncay 在 2018 年发现的自定义权限升级漏洞(本文1.2章节),李蕊发现 Android 官方虽然修复了在应用升级过程中权限定义不一致导致的权限提升问题,但是 Android OS 升级过程中也存在自定义权限定义不一致导致权限提升的漏洞!!
    在这里插入图片描述

    1. 在 Android 操作系统初始化期间,PMS 将被构建,用于 APP 安装卸载操作;
    2. PMS 读取 packages.xml 和 runtime-permissions.xml 以获得存储的权限声明信息和授予状态;
    3. PMS 扫描位于系统文件夹中的 APKs,然后将解析的权限添加到内部结构中;

    需要注意的是,如果权限的当前所有者不是系统,则该权限将被覆盖

    漏洞利用
    在这里插入图片描述

    1. 在 Android 9 的手机上安装 app-ds3,它定义并申请了 Android 10 针对需要检测用户步数或对用户的身体活动(例如步行、骑车或坐车)进行分类的应用引入了 android.permission.ACTIVITY_RECOGNITION 运行时权限(Dangerous 级别),不同的是 app-ds3 将其定义为 normal 级别;
    2. 将该手机升级至 Android 10,系统检查到当前 app-ds3 所拥有的 ACTIVITY_RECOGNITION 权限的所有者并不是系统,故自动将其覆盖,app-ds3 就此悄无声息地获得 Android 10 上的危险权限 ACTIVITY_RECOGNITION 的能力。

    漏洞修复

    在 Android OS 更新时,如果权限的当前所有者不是系统,对应权限的授权应该被撤销。

    2.5 不一致的权限定义漏洞

    该漏洞的编号为 CVE-2021-0317,该漏洞会导致恶意 app 在可以通过安装包升级修改自定义权限后(将 normal 提升为 dangerous 并加入 phone 权限组),当用户重启设备后即可在用户无感知的情况下获得 phone 权限组的能力。

    漏洞原理

    同样相比于 Tuncay 在 2018 年发现的自定义权限升级漏洞(本文1.2章节),李蕊发现 Android 官方虽然修复了在应用升级过程中权限定义不一致导致的权限提升问题,但是 Android OS 升级过程或设备重启过程中也存在自定义权限定义不一致导致权限提升的漏洞!!

    同时不同于 2.4 章节所提到的漏洞的是,CVE-2021-0317 漏洞是用户完全自定义的新权限,而不是 Android OS 升级后高版本的操作系统会存在的权限。
    在这里插入图片描述
    在这里插入图片描述

    • 一个 APP 安装操作也可以更新它自己定义的现有自定义权限,在此过程中,当保护级别从正常或签名变为危险时,系统将保持原有的保护级别,这样的设计是为了阻止 1.2 章节所提到的权限升级攻击;
    • 但是这会导致出现以下情况:系统持有的权限定义与所有者 APP 提供的权限定义不同,即权限定义不一致;
    • 如果系统中存在基于源包刷新权限授予状态的逻辑,如 OS 升级、设备重启等过程,就可能会出现权限升级问题。

    攻击步骤
    在这里插入图片描述

    1. 在手机安装 test 应用,它定义并申请了一个 normal 级别的权限 com.test.cp(安装时会自动赋予该权限);
    2. 使用升级包升级 test 应用,将 com.test.cp 重新定义为一个危险级别的权限并列入 PHONE 权限组,同时在 AndroidManifest.xml 文件中 <uses-permission> 申请使用 com.test.cp 权限与 CALL_PHONE 权限(需要动态授权,安装后不会被自动授予);
    3. 此时 Android 会阻止 com.test.cp 权限的变更所带来的权限提升操作,将其保持原有的 normal 保护级别,但是 reboot 重启设备后却发现 test 应用已成功获得 PHONE 权限组的权限能力!!

    漏洞修复

    当权限定义更新,APP 对应权限的授权应该被撤销。

    总结

    针对发现的缺陷,李博士团队提出了3种通用的安全设计准则:

    1. 准则1:权限定义的任何一个部分都应该始终存在;
    2. 准则2:系统中权限的定义应与权限所有者的声明保持一致;
    3. 准则3:如果权限的定义发生改变,则应该撤销已授予 app 中的该权限。

    在这里插入图片描述
    该论文和研究带来的个人启示:

    1. Android 系统服务(如 PMS 服务)的缺陷漏洞也时有发生,对于漏洞挖掘者来说不要总觉得它“神圣不可侵犯”……
    2. 对于庞大而复杂的研究对象,一个有效的黑盒 Fuzz 测试工具至关重要,需要学会从 Fuzz 出来的异常信息、有效反馈信息来提炼出有价值的漏洞;
    3. 当你漏洞挖掘思路如同“北大荒”一样荒芜的时候,何不跟李蕊博士一样也去学习下他人的论文、他人的历史研究成果,从中提取出思路和方向,并琢磨如何玩出不同的花样……

    本文参考文章与相关材料:

    1. B站:山东大学李蕊博士:Android自定义权限机制安全性分析
    2. 议题涉及的完整漏洞Demo程序演示视频材料
    3. Android 自定义权限漏洞 Fuzz 测试工具 CuPerFuzzer
    4. GOSSIP团队对该议题论文的简单翻译
    5. 北理工详细分析-Android自定义权限及其设计缺陷
    6. PDF论文下载地址:https://www.semanticscholar.org/paper
    7. 推荐一个安全大会论文pdf下载网站:https://typeset.io/papers
    展开全文
  • Shiro自定义权限验证

    2021-11-17 13:18:45
    文章目录 背景 解决方案 PermissionCheckModel.java MyPermissionResolver.java ShiroConfig.java CustomerRealm.java [参考]( (1条消息) Shiro 学习笔记(5)—— 自定义权限解析器和角色解析器_李威威的博客-CSDN...
  • 自定义权限

    千次阅读 2017-02-04 10:39:45
    一、权限 权限有两个作用: 其一:防止其它程序随便调用。 其二:能够在安装程序时,显式的给用户看,当前要安装的这个程序要用到哪个功能。这个是最重要的,试想,如果你装一个斗地主游戏,却看到要用到打电话、发...
  • INSERT INTO `tb_resource` VALUES (5, '登录权限', 'all:login'); INSERT INTO `tb_resource` VALUES (6, '登出权限', 'all:logout'); INSERT INTO `tb_resource` VALUES (7, '错误逻辑显示权限', 'all:error'); ...
  • 动态自定义权限设置.rar 动态自定义权限设置.rar 动态自定义权限设置.rar 动态自定义权限设置.rar 动态自定义权限设置.rar 动态自定义权限设置.rar
  • SAP创建自定义权限对象

    千次阅读 2021-01-23 15:33:48
    一、创建权限对象域:SE11 1.创建域:通过域来控制...四、自定义程序:SE38,并生成事务代码:SE93 1.在程序中调用权限对象 2.程序配置事务代码:se93 五、权限对象分配事务代码:SU24 1.输入事务代码,直接执行 2
  • 在使用Shiro进行权限判断的时候,某一个访问路径,可能只需要两种权限中的其中一个,就可以访问。但是Shiro中,提供的权限...因此自定义权限过滤器是非常有必要的,在日后的开发中,自定义权限过滤器是很频繁的操作。
  • 一个Android自定义权限permission的实例,帮助初学者了解如何自定义访问权限。
  • 1、自定义权限认证的实现思路 自定义一个实体类LoginUser用来保存SygUser用户信息以及权限信息Set<String> permissions 让这个LoginUser实体类实现Userdetails接口 自定义的MyUserDetailsServiceImpl类...
  • Vue 自定义权限指令

    2020-10-21 13:05:17
    这里由于我的项目做了动态权限,页面的按钮也需要根据不同的权限来渲染,那么这里就需要我们这个权限指令了 // 文件名称:permission.js import Vue from 'vue' import store from '@/store' // 是否有权限 const ...
  • PermissionX重磅更新,支持自定义权限提醒对话框

    万次阅读 多人点赞 2020-07-21 07:14:34
    截至目前为止,PermissionX已经迭代更新了三个版本,而最新的1.3.0版本更是加入了非常重要的自定义权限提醒对话框的功能。如果你觉得之前PermissionX自带的权限提醒对话框太丑,从而无法投入正式的生产环境,那么...
  • Django自定义权限控制

    千次阅读 2018-09-03 09:46:10
    最近一直在做自动化发布,通过开发或者测试发起工单到我这边收到工单并一键发布,最终终于完成了这个功能,虽然功能完成了但是目前还不能使用,因为遇到了个问题就是权限问题。如果我把一键发布页面公开的话岂不是...
  • Spring中自定义权限注解 实现功能: ​ 在方法上加上注解@PreAuth(“xxx”), 根据xxx不同内容,可以判断当前请求是否有访问该接口的权限,如果有则放行,反之则返回无权限. ​ 其中@PreAuth(“xxx”)中 “xxx” 可以...
  • 权限管理,就是给不同的用户分配不同的权限。当用户登录或者操作时候进行判断,来阻止用户进行权限以外的操作。本次讲的是当用户登录一刻,只显示权限开启的内容。 一、建立数据库。 1、权限表funcla。来存储录入...
  • 易语言源码易语言动态自定义权限设置源码.rar

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 458,743
精华内容 183,497
关键字:

自定义权限