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

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

Сей­час дос­туп к активнос­ти 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-файл с про­изволь­ным име­нем и при­мер­но сле­дующим содер­жимым:

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

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

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

Теги: CSS