Се­год­ня в выпус­ке: раз­бор типич­ных оши­бок работы с раз­решени­ями Android, биб­лиоте­ка Security-App-Authenticator для про­вер­ки под­линнос­ти при­ложе­ний, статья об опти­миза­ции заг­рузки при­ложе­ния, а так­же фун­кции‑рас­ширения, value-клас­сы и фун­кции груп­пиров­ки дан­ных в Kotlin. И конеч­но же, оче­ред­ная под­борка биб­лиотек.
 

Почитать

 

Ошибки работы с разрешениями

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>7d5ac0f764d5ae47a051777bb5fc9a96f30b6b4d3bbb95cddb1c32932fb28b10</cert-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) {
// ...не стоит доверять этому приложению
}

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии