Категория > Новости > Android: ошибки работы с разрешениями и библиотека Security-App-Authenticator - «Новости»

Android: ошибки работы с разрешениями и библиотека Security-App-Authenticator - «Новости»


5-09-2021, 00:00. Автор: Сильвия
Common mistakes when using permissions in Android — статья об ошиб­ках, которые допус­кают раз­работ­чики при дек­ларации собс­твен­ных раз­решений.

Пре­амбу­ла: в Android есть сис­тема раз­решений (permissions). Раз­решения могут быть уров­ня normal (они пре­дос­тавля­ются без воп­росов), dangerous (при­ложе­ние обя­зано зап­росить раз­решение у поль­зовате­ля), signature (при­ложе­ние дол­жно быть под­писано тем же клю­чом, что и ком­понент, пре­дос­тавля­емый по раз­решению) и нес­коль­ких дру­гих сис­темных типов, исполь­зуемых толь­ко при­ложе­ниями из ком­плек­та про­шив­ки.


Кро­ме того, при­ложе­ния могут дек­лариро­вать свои собс­твен­ные раз­решения, которые дол­жны исполь­зовать дру­гие при­ложе­ния для дос­тупа к воз­можнос­тям это­го при­ложе­ния (запус­кать активнос­ти, получать дан­ные из content provider’ов и так далее). Дек­ларация таких раз­решений в манифес­те выг­лядит при­мер­но так:


<permission android:name="com.mycoolcam.USE_COOL_CAMERA" android:protectionLevel="dangerous" />
<activity android:name=".CoolCamActivity" android:exported="true" android:permission="com.mycoolcam.USE_COOL_CAMERA">
<intent-filter>
<action android:name="com.mycoolcam.LAUNCH_COOL_CAM" />
<category android:name="android.intent.category.DEFAULT" />
intent-filter>
activity>

Сей­час дос­туп к активнос­ти CoolCamActivity защищен с помощью раз­решения com.mycoolcam.USE_COOL_CAMERA.


А теперь ошиб­ки, которые совер­шают раз­работ­чики, ког­да дек­лариру­ют свои раз­решения и защища­ют ими ком­понен­ты:



  1. Уро­вень раз­решения не ука­зан. Если в пре­дыду­щем при­мере не ука­зать уро­вень раз­решения (android:protectionLevel="dangerous"), он ста­нет normal и в ито­ге дос­туп к защищен­ной активнос­ти смо­жет получить какое угод­но при­ложе­ние (дос­таточ­но ука­зать в манифес­те, что оно исполь­зует это раз­решение).



  2. Уро­вень раз­решения signature не опре­делен во всех при­ложе­ниях. Допус­тим, у тебя есть два при­ложе­ния, которые дол­жны обме­нивать­ся дан­ными. Что­бы защитить их от несан­кци­они­рован­ного дос­тупа, ты добав­ляешь в при­ложе­ние 1 опре­деле­ние раз­решения:


    <permission android:name="com.mycoolcam.USE_COOL_CAMERA" android:protectionLevel="signature" />

    При этом в при­ложе­нии 1 такого опре­деле­ния нет, так как оно толь­ко исполь­зует это раз­решение. В ито­ге если на устрой­ство уста­новить толь­ко вто­рое при­ложе­ние, то Android, ничего не зна­ющий о раз­решении com.mycoolcam.USE_COOL_CAMERA, авто­мати­чес­ки наз­начит ему уро­вень normal вмес­то опре­делен­ного в при­ложе­нии 1 уров­ня signature.


    До­бав­ляй опре­деле­ние раз­решения во все при­ложе­ния.



  3. От­сутс­твие каких‑либо раз­решений. Допус­тим, есть при­ложе­ние, которое исполь­зует сис­темное раз­решение android.permission.READ_CONTACTS. У это­го при­ложе­ния есть content provider, который пре­дос­тавля­ет дос­туп к базе дан­ных при­ложе­ния, вклю­чая кон­такты поль­зовате­лей. И этот content provider не защищен никаким раз­решени­ем. В ито­ге сто­рон­ние при­ложе­ния могут получить дос­туп к кон­тактам поль­зовате­ля опос­редован­но, через это при­ложе­ние.



 

Разработчику


 

Библиотека Security-App-Authenticator


Hands on with Jetpack’s Security App Authenticator library — неболь­шая замет­ка о но­вой биб­лиоте­ке в ком­плек­те Android Jetpack.


Биб­лиоте­ка нуж­на для про­вер­ки под­линнос­ти сер­тифика­тов при­ложе­ний, с которы­ми будет кон­такти­ровать твое при­ложе­ние. Дела­ется это с помощью свер­ки кон­троль­ной сум­мы сер­тифика­та при­ложе­ния и его срав­нения с уже сох­ранен­ным спис­ком кон­троль­ных сумм. Эта­кий SSL Pinning для при­ложе­ний.


Пе­ред тем как исполь­зовать биб­лиоте­ку, в каталог под­катало­ге xml ресур­сов при­ложе­ния необ­ходимо помес­тить XML-файл с про­изволь­ным име­нем и при­мер­но сле­дующим содер­жимым:


<?xml version="1.0" encoding="utf-8"?>
<app-authenticator>
<expected-identity>
<package name="com.example.app">
<cert-digest>7d5ac0f764d5ae47a051777bb5fc9a96f30b6b4d3bbb95cddb1c32932fb28b10cert-digest>
package>
expected-identity>
app-authenticator>

Этот файл говорит, что при­ложе­ние с име­нем пакета com.example.app дол­жно иметь сер­тификат с ука­зан­ной кон­троль­ной сум­мой SHA-256.


Да­лее мож­но начать исполь­зовать биб­лиоте­ку:


// Создаем экземпляр аутентификатора из описанного выше XML-файла
val authenticator = AppAuthenticator.createFromResource(context, R.xml.expected_app_identities)
// Первый способ проверки сертификата
val result = when (authenticator.checkAppIdentity("com.example.app")) {
AppAuthenticator.SIGNATURE_MATCH -> "Signature matches"
AppAuthenticator.SIGNATURE_NO_MATCH -> "Signature does not match"
else -> return
}
// Второй способ проверки с выбросом исключения
try {
authenticator.enforceAppIdentity("com.example.app)
// ...работаем с приложением
} catch (e: SecurityException) {
// ...не стоит доверять этому приложению
}

Как вид­но, есть нес­коль­ко спо­собов про­вер­ки. Пер­вый удоб­но исполь­зовать для прос­тых про­верок. Вто­рой удо­бен для исполь­зования в фун­кци­ях работы с про­веря­емым при­ложе­нием. Прос­то добав­ляем в их начало про­вер­ку, и все осталь­ное сде­лает сис­тема обра­бот­ки исклю­чений.


Перейти обратно к новости