Безопасность приложений Android с помощью Drozer

dz> run app.broadcast.send --action com.exmpla.PICK --extra string url https://example.com

Бонус

С какими еще проблемами и уязвимостями можно столкнуться в приложениях? Их много, авторы книги Security Code Smells in Android ICC составили подробный список таких проблем. Они взяли 700 приложений с открытым исходным кодом из репозитория F-Droid и проанализировали их с помощью специального инструмента AndroidLintSecurityChecks.

Все проб­лемы ском­понова­ны в две­над­цать катего­рий:

• SM01: Persisted Dynamic Permission. В Android есть механизм, поз­воля­ющий пре­дос­тавить дру­гому при­ложе­нию вре­мен­ный дос­туп к какому‑либо URI сво­его ContentProvider’а. Это дела­ется с помощью метода Context.grantUriPermission(). Если при­ложе­ние вызыва­ет его, но не вызыва­ет Context.revokeUriPermission(), что­бы отоз­вать дос­туп, — есть проб­лемы.
• SM02: Custom Scheme Channel. Любое при­ложе­ние может зарегис­три­ровать собс­твен­ную URI-схе­му, такую как myapp://, вне зависи­мос­ти от того, исполь­зует ли такую схе­му дру­гое при­ложе­ние. Как следс­твие, пересы­лать важ­ные дан­ные, исполь­зуя кас­томные URI-схе­мы, край­не небезо­пас­но.
• SM03: Incorrect Protection Level. В Android любое при­ложе­ние может соз­дать свое собс­твен­ное раз­решение для дос­тупа к сво­им дан­ным. Но есть проб­лема: если ука­зать неп­равиль­ный уро­вень защиты раз­решения (protection level), оно может не сра­ботать. Если раз­работ­чик хочет, что­бы поль­зователь видел диалог зап­роса раз­решений, он дол­жен исполь­зовать уро­вень защиты dangerous или siganture, если дан­ное раз­решение дол­жно получать толь­ко при­ложе­ние с той же циф­ровой под­писью.
• SM04: Unauthorized Intent. Любое при­ложе­ние в Android может зарегис­три­ровать себя в качес­тве обра­бот­чика опре­делен­ных типов интентов (intent). По умол­чанию этот обра­бот­чик будет открыт все­му миру, но его мож­но защитить с помощью сис­темы раз­решений и стро­гой валида­ции вход­ных дан­ных.
• SM05: Sticky Broadcast. Любое при­ложе­ние может пос­лать дру­гому при­ложе­нию интент. Более того, оно может пос­лать широко­веща­тель­ный интент сра­зу всем при­ложе­ниям, и он будет обра­ботан пер­вым при­ложе­нием, спо­соб­ным его при­нять. Но есть так­же воз­можность пос­лать широко­веща­тель­ный sticky-intent, который пос­ле обра­бот­ки одним при­ложе­нием все рав­но будет дос­тавлен дру­гим при­ложе­ниям. Что­бы это­го не про­исхо­дило, не сто­ит исполь­зовать такие интенты, а широко­веща­тель­ные интенты луч­ше не исполь­зовать вооб­ще.
• SM06: Slack WebViewClient. Ком­понент WebView поз­воля­ет при­ложе­ниям показы­вать веб‑стра­ницы внут­ри сво­его интерфей­са. По умол­чанию он никак не филь­тру­ет откры­ваемые URL, чем мож­но вос­поль­зовать­ся, нап­ример, для фишин­га. Раз­работ­чикам сто­ит либо исполь­зовать белый спи­сок адре­сов, либо выпол­нять про­вер­ку с помощью SafetyNet API.
• SM07: Broken Service Permission. При­ложе­ния могут пре­дос­тавлять дос­туп к сво­ей фун­кци­ональ­нос­ти с помощью сер­висов. Зло­умыш­ленник может исполь­зовать эту воз­можность для запус­ка кода с повышен­ными пол­номочи­ями (пол­номочи­ями сер­виса). Что­бы это­го избе­жать, сер­вис дол­жен про­верять пол­номочия вызыва­юще­го при­ложе­ния с помощью метода Context.checkCallingPermission().
• SM08: Insecure Path Permission. Некото­рые при­ложе­ния пре­дос­тавля­ют дос­туп к сво­им дан­ным с помощью ContentProvider’а, который адре­сует дан­ные, исполь­зуя UNIX-подоб­ные пути: /a/b/c. Прог­раммист может открыть дос­туп к сво­ему ContentProvider’у, но отре­зать дос­туп к некото­рым путям (нап­ример, к /data/secret). Но есть проб­лема: раз­работ­чики час­то исполь­зуют класс UriMatcher для срав­нения путей, а он, в отли­чие от Android, срав­нива­ет их без уче­та двой­ных сле­шей. Отсю­да могут воз­никнуть ошиб­ки при раз­решении и зап­рете дос­тупа.
• SM09: Broken Path Permission Precedence. Сход­ная с пре­дыду­щей проб­лема. При опи­сании ContentProvider’а в манифес­те раз­работ­чик может ука­зать, какие раз­решения нуж­ны при­ложе­нию для дос­тупа к опре­делен­ным путям. Но в Android есть баг, из‑за чего он отда­ет пред­почте­ние более гло­баль­ным путям. Нап­ример, если при­ложе­ние дает дос­туп к /data всем под­ряд, но исполь­зует спе­циаль­ное раз­решение для дос­тупа к /data/secret, то в ито­ге дос­туп к /data/secret смо­гут получить все.
• SM10: Unprotected BroadcastReceiver. Фак­тичес­ки ана­лог проб­лемы SM04, но рас­простра­няющий­ся исклю­читель­но на BroadcastReceiver’ы (спе­циаль­ные обра­бот­чики интентов).
• SM11: Implicit PendingIntent. Кро­ме интентов, в Android есть сущ­ность под наз­вани­ем PendingIntent. Это сво­его рода отло­жен­ные интенты, которые могут быть отправ­лены поз­же и даже дру­гим при­ложе­нием от име­ни соз­давше­го интент при­ложе­ния. Если PendingIntent широко­веща­тель­ный, то любое при­ложе­ние смо­жет перех­ватить его и пос­лать интент от име­ни это­го при­ложе­ния.
• SM12: Common Task Affinity. Ана­лог проб­лемы StrandHogg.

Об­щая рас­простра­нен­ность оши­бок