Msingi wa Programu za Android

Reading time: 18 minutes

Mfano wa Usalama wa Android

Kuna tabaka mbili:

• OS, ambayo inashikilia programu zilizowekwa mbali na kila mmoja.
• programu yenyewe, ambayo inaruhusu waendelezaji kufichua kazi fulani na kuunda uwezo wa programu.

Kutenganisha UID

Kila programu inapewa Kitambulisho Maalum cha Mtumiaji. Hii inafanywa wakati wa usakinishaji wa programu ili programu iweze kuingiliana tu na faili zinazomilikiwa na Kitambulisho chake cha Mtumiaji au faili zilizoshirikiwa. Hivyo, ni programu yenyewe tu, vipengele fulani vya OS na mtumiaji wa root wanaweza kufikia data za programu.

Kushiriki UID

Programu mbili zinaweza kuwekewa mipangilio kutumia UID sawa. Hii inaweza kuwa na manufaa kushiriki taarifa, lakini ikiwa moja yao itashambuliwa, data za programu zote mbili zitakuwa hatarini. Hii ndiyo sababu tabia hii inachukuliwa kama si nzuri.
Ili kushiriki UID sawa, programu lazima zifanye maelezo sawa ya android:sharedUserId katika hati zao.

Sandboxing

Android Application Sandbox inaruhusu kuendesha kila programu kama mchakato tofauti chini ya Kitambulisho tofauti cha Mtumiaji. Kila mchakato una mashine yake ya virtual, hivyo msimbo wa programu unafanya kazi kwa kujitenga na programu nyingine.
Kuanzia Android 5.0(L) SELinux inatekelezwa. Kimsingi, SELinux ilikataa mwingiliano wote wa mchakato na kisha kuunda sera za kuruhusu tu mwingiliano unaotarajiwa kati yao.

Ruhusa

Wakati unaposakinisha programu na inahitaji ruhusa, programu inahitaji ruhusa zilizowekwa katika uses-permission vipengele katika AndroidManifest.xml faili. Kipengele cha uses-permission kinaonyesha jina la ruhusa inayohitajika ndani ya attribute name. Pia ina maxSdkVersion attribute ambayo inazuia kuomba ruhusa kwenye toleo lililo juu ya lile lililotajwa.
Kumbuka kwamba programu za android hazihitaji kuomba ruhusa zote mwanzoni, zinaweza pia kuomba ruhusa kwa njia ya kidinamik lakini ruhusa zote lazima zitangazwe katika manifest.

Wakati programu inafichua kazi inaweza kupunguza ufikiaji kwa programu tu ambazo zina ruhusa maalum.
Kipengele cha ruhusa kina attributes tatu:

• jina la ruhusa
• permission-group attribute, ambayo inaruhusu kuunganisha ruhusa zinazohusiana.
• protection-level ambayo inaonyesha jinsi ruhusa zinavyotolewa. Kuna aina nne:
• Normal: Inatumika wakati hakuna hatari zinazojulikana kwa programu. Mtumiaji huhitajika kuidhinisha.
• Dangerous: Inaonyesha ruhusa inatoa programu inayohitaji ufikiaji wa juu. Watumiaji wanahitajika kuidhinisha.
• Signature: Ni tu programu zilizotiwa saini na cheti sawa na ile inayosambaza kipengele zinaweza kupewa ruhusa. Hii ndiyo aina yenye nguvu zaidi ya ulinzi.
• SignatureOrSystem: Ni tu programu zilizotiwa saini na cheti sawa na ile inayosambaza kipengele au programu zinazofanya kazi na ufikiaji wa kiwango cha mfumo zinaweza kupewa ruhusa.

Programu Zilizowekwa Kabla

Programu hizi kwa kawaida hupatikana katika /system/app au /system/priv-app directories na baadhi yao zime boreshwa (huenda usipate hata faili ya classes.dex). Programu hizi zinastahili kuangaliwa kwa sababu wakati mwingine zinaweza kuwa zinakimbia na ruhusa nyingi sana (kama root).

• Zile zinazokuja na AOSP (Android OpenSource Project) ROM
• Zilizoongezwa na mtengenezaji wa kifaa
• Zilizoongezwa na mtoa huduma wa simu (ikiwa imenunuliwa kutoka kwao)

Rooting

Ili kupata ufikiaji wa root kwenye kifaa halisi cha android kwa kawaida unahitaji kuchokoza 1 au 2 vulnerabilities ambazo huwa maalum kwa kifaa na toleo.
Mara baada ya kuchokoza kufanya kazi, kwa kawaida faili ya su ya Linux inakopishwa kwenye eneo lililotajwa katika PATH env variable ya mtumiaji kama /system/xbin.

Mara baada ya faili ya su kuwekwa, programu nyingine ya Android inatumika kuungana na faili ya su na kusindika maombi ya ufikiaji wa root kama Superuser na SuperSU (inapatikana kwenye Google Play store).

ROMs

Inawezekana kurekebisha OS kwa kusakinisha firmware maalum. Kufanya hivi kunawezesha kuongeza matumizi ya kifaa cha zamani, kupita vizuizi vya programu au kupata ufikiaji wa msimbo wa hivi punde wa Android.
OmniROM na LineageOS ni mbili ya firmware maarufu zaidi za kutumia.

Kumbuka kwamba sio kila wakati ni lazima ku-root kifaa ili kusakinisha firmware maalum. Wazalishaji wengine wanaruhusu kufungua bootloaders zao kwa njia iliyoandikwa vizuri na salama.

Madhara

Mara kifaa kinapokuwa kime-rooted, programu yoyote inaweza kuomba ufikiaji kama root. Ikiwa programu mbaya itapata ufikiaji huo, itakuwa na ufikiaji wa karibu kila kitu na itakuwa na uwezo wa kuharibu simu.

Msingi wa Programu za Android

• Muundo wa programu za Android unarejelewa kama APK file format. Kimsingi ni ZIP file (kwa kubadilisha kiendelezi cha faili kuwa .zip, maudhui yanaweza kutolewa na kuangaliwa).
• Maudhui ya APK (Siyo ya kina)
• AndroidManifest.xml
• resources.arsc/strings.xml
• resources.arsc: ina rasilimali zilizotayarishwa mapema, kama XML ya binary.
• res/xml/files_paths.xml
• META-INF/
• Hapa ndipo Cheti lilipo!
• classes.dex
• Inashikilia bytecode ya Dalvik, inayoakisi msimbo wa Java (au Kotlin) uliotayarishwa ambao programu inatekeleza kwa default.
• lib/
• Inashikilia maktaba asilia, iliyogawanywa kwa usanifu wa CPU katika subdirectories.
• armeabi: msimbo wa processors za msingi wa ARM
• armeabi-v7a: msimbo wa processors za ARMv7 na za juu
• x86: msimbo wa processors za X86
• mips: msimbo wa processors za MIPS pekee
• assets/
• Inahifadhi faili mbalimbali zinazohitajika na programu, huenda ikajumuisha maktaba za asilia au faili za DEX, wakati mwingine hutumiwa na waandishi wa malware kuficha msimbo wa ziada.
• res/
• Inashikilia rasilimali ambazo hazijakusanywa katika resources.arsc

Dalvik & Smali

Katika maendeleo ya Android, Java au Kotlin inatumika kwa kuunda programu. Badala ya kutumia JVM kama katika programu za desktop, Android inakusanya msimbo huu kuwa Dalvik Executable (DEX) bytecode. Awali, mashine ya virtual ya Dalvik ilishughulikia bytecode hii, lakini sasa, Android Runtime (ART) inachukua jukumu katika toleo jipya la Android.

Kwa ajili ya uhandisi wa nyuma, Smali inakuwa muhimu. Ni toleo linaloweza kusomeka na binadamu la bytecode ya DEX, likifanya kazi kama lugha ya assembly kwa kutafsiri msimbo wa chanzo kuwa maagizo ya bytecode. Smali na baksmali zinarejelea zana za mkusanyiko na uondoshaji katika muktadha huu.

Intents

Intents ndiyo njia kuu ambayo programu za Android zinawasiliana kati ya vipengele vyake au na programu nyingine. Hizi ni vitu vya ujumbe vinaweza pia kubeba data kati ya programu au vipengele, sawa na jinsi maombi ya GET/POST yanavyotumika katika mawasiliano ya HTTP.

Hivyo, Intent kimsingi ni ujumbe unaopita kati ya vipengele. Intents zinaweza kuelekezwa kwa vipengele maalum au programu, au zinaweza kutumwa bila mpokeaji maalum.
Ili kuwa rahisi, Intent inaweza kutumika:

• Kuanzisha Activity, kwa kawaida kufungua kiolesura cha mtumiaji kwa programu
• Kama matangazo ya kuarifu mfumo na programu kuhusu mabadiliko
• Kuanzisha, kusitisha, na kuwasiliana na huduma ya nyuma
• Kupata data kupitia ContentProviders
• Kama kurudi nyuma kushughulikia matukio

Ikiwa ni hatari, Intents zinaweza kutumika kufanya mashambulizi mbalimbali.

Kichujio cha Intent

Kichujio cha Intents kinaelezea jinsi shughuli, huduma, au Mpokeaji wa Matangazo unaweza kuingiliana na aina tofauti za Intents. Kimsingi, zinaelezea uwezo wa vipengele hivi, kama vile ni vitendo gani wanaweza kufanya au aina gani za matangazo wanaweza kushughulikia. Mahali kuu pa kutangaza vichujio hivi ni ndani ya faili ya AndroidManifest.xml, ingawa kwa Mpokeaji wa Matangazo, kuandika ni chaguo pia.

Vichujio vya Intents vinajumuisha makundi, vitendo, na vichujio vya data, huku kukiwa na uwezekano wa kujumuisha metadata ya ziada. Mpango huu unaruhusu vipengele kushughulikia Intents maalum zinazolingana na vigezo vilivyotangazwa.

Nafasi muhimu ya vipengele vya Android (shughuli/huduma/watoa maudhui/mpokeaji wa matangazo) ni mwonekano wao au hadhi ya umma. Kipengele kinachukuliwa kuwa cha umma na kinaweza kuingiliana na programu nyingine ikiwa kime exported na thamani ya true au ikiwa kichujio cha Intent kimewekwa kwa ajili yake katika hati. Hata hivyo, kuna njia kwa waendelezaji kuweka vipengele hivi kuwa binafsi, kuhakikisha havihusiani na programu nyingine bila kukusudia. Hii inafanywa kwa kuweka exported attribute kuwa false katika maelezo yao ya hati.

Zaidi ya hayo, waendelezaji wana chaguo la kuimarisha ufikiaji wa vipengele hivi zaidi kwa kuhitaji ruhusa maalum. permission attribute inaweza kuwekwa ili kuhakikisha kwamba ni programu pekee zenye ruhusa iliyotolewa zinaweza kufikia kipengele, kuongeza safu ya ziada ya usalama na udhibiti juu ya nani anaweza kuingiliana nayo.

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

Implicit Intents

Intents huundwa kimaandishi kwa kutumia mjenzi wa Intent:

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

Hatua ya nia iliyotangazwa hapo awali ni ACTION_SEND na Ziada ni mailto Uri (Ziada ikiwa ni taarifa ya ziada ambayo nia inatarajia).

Nia hii inapaswa kutangazwa ndani ya hati kama ilivyo katika mfano ufuatao:

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

An intent-filter inahitaji kuendana na action, data na category ili kupokea ujumbe.

Mchakato wa "Intent resolution" unamua ni programu ipi inapaswa kupokea kila ujumbe. Mchakato huu unazingatia priority attribute, ambayo inaweza kuwekwa katika intent-filter declaration, na ile yenye kipaumbele cha juu itachaguliwa. Kipaumbele hiki kinaweza kuwekwa kati ya -1000 na 1000 na programu zinaweza kutumia thamani ya SYSTEM_HIGH_PRIORITY. Ikiwa conflict itatokea, dirisha la "choser" linaonekana ili mtumiaji aweze kuamua.

Explicit Intents

Explicit intent inabainisha jina la darasa ambalo linawalenga:

Intent downloadIntent = new (this, DownloadService.class):

Katika programu nyingine ili kufikia nia iliyotangazwa awali unaweza kutumia:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

Pending Intents

Hizi zinawaruhusu programu nyingine kuchukua hatua kwa niaba ya programu yako, wakitumia utambulisho na ruhusa za programu yako. Kujenga Pending Intent inapaswa kuelezwa intent na hatua ya kutekeleza. Ikiwa intent iliyotangazwa si ya Moja kwa Moja (haijatangaza ni intent ipi inayoweza kuitwa) programu mbaya inaweza kutekeleza hatua iliyotangazwa kwa niaba ya programu ya mwathirika. Zaidi ya hayo, ikiwa hatua haijatangazwa, programu mbaya itakuwa na uwezo wa kufanya hatua yoyote kwa niaba ya mwathirika.

Broadcast Intents

Kinyume na intents za awali, ambazo zinapokelewa na programu moja tu, broadcast intents zinaweza kupokelewa na programu nyingi. Hata hivyo, kuanzia toleo la API 14, ni mpossible kuweka programu ambayo inapaswa kupokea ujumbe kwa kutumia Intent.set Package.

Vinginevyo, pia inawezekana kueleza ruhusa wakati wa kutuma matangazo. Programu inayopokea itahitaji kuwa na ruhusa hiyo.

Kuna aina mbili za Matangazo: Ya Kawaida (asynchronous) na Iliyopangwa (synchronous). Agizo linategemea kipaumbele kilichowekwa ndani ya kipengele cha mpokeaji. Kila programu inaweza kushughulikia, kupeleka au kuacha Matangazo.

Inawezekana kutuma matangazo kwa kutumia kazi sendBroadcast(intent, receiverPermission) kutoka darasa la Context.
Unaweza pia kutumia kazi sendBroadcast kutoka LocalBroadCastManager inahakikisha ujumbe hauondoki kwenye programu. Kwa kutumia hii hutahitaji hata kusafirisha kipengele cha mpokeaji.

Sticky Broadcasts

Aina hii ya Matangazo inaweza kufikiwa muda mrefu baada ya kutumwa.
Hizi zilikataliwa katika kiwango cha API 21 na inashauriwa usizitumie.
Zinawaruhusu programu yoyote kunusa data, lakini pia kuibadilisha.

Ikiwa unapata kazi zinazojumuisha neno "sticky" kama sendStickyBroadcast au sendStickyBroadcastAsUser, angalia athari na jaribu kuziondoa.

Deep links / URL schemes

Katika programu za Android, deep links zinatumika kuanzisha hatua (Intent) moja kwa moja kupitia URL. Hii inafanywa kwa kutangaza mpango maalum wa URL ndani ya shughuli. Wakati kifaa cha Android kinapojaribu kufikia URL yenye mpango huu, shughuli iliyotangazwa ndani ya programu inazinduliwa.

Mpango lazima utangazwe katika AndroidManifest.xml faili:

[...]
<activity android:name=".MyActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="examplescheme" />
</intent-filter>
[...]

Mpango kutoka kwa mfano wa awali ni examplescheme:// (zingatia pia category BROWSABLE)

Kisha, katika uwanja wa data, unaweza kubainisha host na path:

<data android:scheme="examplescheme"
android:host="example"
/>

Ili kuipata kutoka kwenye wavuti, inawezekana kuweka kiungo kama:

<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>

Ili kupata code itakayotekelezwa katika App, nenda kwenye shughuli inayoitwa na deeplink na tafuta kazi onNewIntent.

Jifunze jinsi ya kuita deep links bila kutumia kurasa za HTML.

AIDL - Android Interface Definition Language

Android Interface Definition Language (AIDL) imeundwa ili kuwezesha mawasiliano kati ya mteja na huduma katika programu za Android kupitia mawasiliano kati ya michakato (IPC). Kwa kuwa upatikanaji wa kumbukumbu za mchakato mwingine moja kwa moja haukubaliki kwenye Android, AIDL inarahisisha mchakato kwa kuhamasisha vitu katika muundo unaoeleweka na mfumo wa uendeshaji, hivyo kurahisisha mawasiliano kati ya michakato tofauti.

Mifano Muhimu

• Huduma Zilizofungwa: Huduma hizi hutumia AIDL kwa IPC, zikiwezesha shughuli au vipengele kuungana na huduma, kufanya maombi, na kupokea majibu. Njia ya onBind katika darasa la huduma ni muhimu kwa kuanzisha mwingiliano, ikionyesha kama eneo muhimu la ukaguzi wa usalama kutafuta udhaifu.

• Messenger: Ikifanya kazi kama huduma iliyo fungwa, Messenger inarahisisha IPC kwa kuzingatia usindikaji wa data kupitia njia ya onBind. Ni muhimu kukagua njia hii kwa karibu kwa usimamizi usio salama wa data au utekelezaji wa kazi nyeti.

• Binder: Ingawa matumizi ya moja kwa moja ya darasa la Binder si ya kawaida sana kutokana na ufafanuzi wa AIDL, ni muhimu kuelewa kwamba Binder inafanya kazi kama dereva wa kiwango cha kernel unawezesha uhamasishaji wa data kati ya maeneo ya kumbukumbu ya michakato tofauti. Kwa ufahamu zaidi, rasilimali inapatikana kwenye https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Vipengele

Hizi ni pamoja na: Shughuli, Huduma, Vastika za Matangazo na Watoa Huduma.

Shughuli ya Kuanza na shughuli nyingine

Katika programu za Android, shughuli ni kama skrini, zikionyesha sehemu tofauti za kiolesura cha mtumiaji wa programu. Programu inaweza kuwa na shughuli nyingi, kila moja ikionyesha skrini ya kipekee kwa mtumiaji.

Shughuli ya kuanzisha ni lango kuu la programu, inayozinduliwa unapobofya ikoni ya programu. Imefafanuliwa katika faili ya manifest ya programu kwa nia maalum za MAIN na LAUNCHER:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

Sio programu zote zinahitaji shughuli ya kuanzisha, hasa zile zisizo na kiolesura cha mtumiaji, kama huduma za nyuma.

Shughuli zinaweza kupatikana kwa programu nyingine au michakato kwa kuashiria kama "exported" katika hati. Mpangilio huu unaruhusu programu nyingine kuanzisha shughuli hii:

<service android:name=".ExampleExportedService" android:exported="true"/>

Hata hivyo, kufikia shughuli kutoka programu nyingine si hatari ya usalama kila wakati. Wasiwasi unatokea ikiwa data nyeti inashirikiwa vibaya, ambayo inaweza kusababisha uvujaji wa taarifa.

Mzunguko wa maisha wa shughuli uanza na njia ya onCreate, kuandaa UI na kuandaa shughuli kwa mwingiliano na mtumiaji.

Aina ya Programu

Katika maendeleo ya Android, programu ina chaguo la kuunda aina ya Application darasa, ingawa si lazima. Wakati aina kama hiyo imefafanuliwa, inakuwa darasa la kwanza kuanzishwa ndani ya programu. Njia ya attachBaseContext, ikiwa imeanzishwa katika aina hii, inatekelezwa kabla ya njia ya onCreate. Mpangilio huu unaruhusu kuanzishwa mapema kabla ya sehemu nyingine za programu kuanza.

public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}

Services

Services ni operatives za nyuma zinazoweza kutekeleza kazi bila kiolesura cha mtumiaji. Kazi hizi zinaweza kuendelea kukimbia hata watumiaji wanapobadilisha programu, na kufanya huduma kuwa muhimu kwa operesheni za muda mrefu.

Huduma ni za kubadilika; zinaweza kuanzishwa kwa njia mbalimbali, huku Intents ikiwa njia kuu ya kuzindua huduma kama kiingilio cha programu. Mara huduma inapozinduliwa kwa kutumia njia ya startService, njia yake ya onStart inaanza kufanya kazi na inaendelea kukimbia hadi njia ya stopService itakapoitwa wazi. Vinginevyo, ikiwa jukumu la huduma linategemea muunganisho wa mteja ulio hai, njia ya bindService inatumika kuunganisha mteja na huduma, ikihusisha njia ya onBind kwa ajili ya kupitisha data.

Matumizi ya kuvutia ya huduma ni pamoja na upigaji muziki wa nyuma au upataji wa data ya mtandao bila kuingilia mwingiliano wa mtumiaji na programu. Aidha, huduma zinaweza kufanywa kupatikana kwa michakato mingine kwenye kifaa hicho hicho kupitia exporting. Hii si tabia ya kawaida na inahitaji usanidi wazi katika faili ya Android Manifest:

<service android:name=".ExampleExportedService" android:exported="true"/>

Broadcast Receivers

Broadcast receivers hufanya kazi kama wasikilizaji katika mfumo wa ujumbe, kuruhusu programu nyingi kujibu ujumbe sawa kutoka kwa mfumo. Programu inaweza kujiandikisha mpokeaji kwa njia mbili kuu: kupitia Manifest ya programu au kwa njia ya kidinamik ndani ya msimbo wa programu kupitia registerReceiver API. Katika Manifest, matangazo yanachujwa kwa ruhusa, wakati wapokeaji waliojiandikisha kwa njia ya kidinamik wanaweza pia kubainisha ruhusa wakati wa kujiandikisha.

Intent filters ni muhimu katika mbinu zote za kujiandikisha, zikiamua ni matangazo gani yanayochochea mpokeaji. Mara matangazo yanayolingana yatumwa, njia ya onReceive ya mpokeaji inaitwa, ikiruhusu programu kujibu ipasavyo, kama kubadilisha tabia kwa kujibu onyo la betri ya chini.

Matangazo yanaweza kuwa asynchronous, yakifika kwa wapokeaji wote bila mpangilio, au synchronous, ambapo wapokeaji wanapata matangazo kulingana na vipaumbele vilivyowekwa. Hata hivyo, ni muhimu kutambua hatari ya usalama, kwani programu yoyote inaweza kujipa kipaumbele ili kukamata matangazo.

Ili kuelewa kazi ya mpokeaji, angalia njia ya onReceive ndani ya darasa lake. Msimbo wa njia hii unaweza kubadilisha Intent iliyopokelewa, ikionyesha umuhimu wa uthibitishaji wa data na wapokeaji, hasa katika Ordered Broadcasts, ambazo zinaweza kubadilisha au kuacha Intent.

Content Provider

Content Providers ni muhimu kwa kushiriki data iliyopangwa kati ya programu, ikisisitiza umuhimu wa kutekeleza ruhusa ili kuhakikisha usalama wa data. Wanaruhusu programu kufikia data kutoka vyanzo mbalimbali, ikiwa ni pamoja na hifadhidata, mifumo ya faili, au mtandao. Ruhusa maalum, kama readPermission na writePermission, ni muhimu kwa kudhibiti ufikiaji. Zaidi ya hayo, ufikiaji wa muda unaweza kutolewa kupitia mipangilio ya grantUriPermission katika manifest ya programu, ikitumia sifa kama path, pathPrefix, na pathPattern kwa udhibiti wa ufikiaji wa kina.

Uthibitishaji wa ingizo ni muhimu ili kuzuia udhaifu, kama vile SQL injection. Content Providers zinasaidia operesheni za msingi: insert(), update(), delete(), na query(), zikifanikisha usimamizi wa data na kushiriki kati ya programu.

FileProvider, Content Provider maalum, inazingatia kushiriki faili kwa usalama. Inafafanuliwa katika manifest ya programu kwa sifa maalum za kudhibiti ufikiaji wa folda, zinazoonyeshwa na android:exported na android:resource zikielekeza kwenye mipangilio ya folda. Tahadhari inashauriwa wakati wa kushiriki saraka ili kuepuka kufichua data nyeti bila kukusudia.

Mfano wa tangazo la manifest kwa FileProvider:

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

Na mfano wa kufafanua folda zinazoshirikiwa katika filepaths.xml:

<paths>
<files-path path="images/" name="myimages" />
</paths>

Kwa maelezo zaidi angalia:

• Android Developers: Content Providers
• Android Developers: FileProvider

WebViews

WebViews ni kama vibrowser vidogo ndani ya programu za Android, vinavyovuta maudhui ama kutoka mtandaoni au kutoka kwa faili za ndani. Vinakabiliwa na hatari sawa na vibrowser vya kawaida, lakini kuna njia za kupunguza hatari hizi kupitia mipangilio maalum.

Android inatoa aina mbili kuu za WebView:

• WebViewClient ni mzuri kwa HTML ya msingi lakini haisaidii kazi ya arifa ya JavaScript, ikihusisha jinsi mashambulizi ya XSS yanavyoweza kupimwa.
• WebChromeClient inafanya kazi kama uzoefu kamili wa kivinjari cha Chrome.

Jambo muhimu ni kwamba vibrowser vya WebView havishiriki vidakuzi na kivinjari kikuu cha kifaa.

Kwa kupakia maudhui, mbinu kama loadUrl, loadData, na loadDataWithBaseURL zinapatikana. Ni muhimu kuhakikisha URLs hizi au faili ni salama kutumia. Mipangilio ya usalama inaweza kudhibitiwa kupitia darasa la WebSettings. Kwa mfano, kuzima JavaScript kwa setJavaScriptEnabled(false) kunaweza kuzuia mashambulizi ya XSS.

"Bridge" ya JavaScript inaruhusu vitu vya Java kuingiliana na JavaScript, ikihitaji mbinu kuwekewa alama na @JavascriptInterface kwa usalama kuanzia Android 4.2.

Kuruhusu ufikiaji wa maudhui (setAllowContentAccess(true)) kunaruhusu WebViews kufikia Watoa Maudhui, ambayo inaweza kuwa hatari isipokuwa URLs za maudhui zihakikishwe kuwa salama.

Ili kudhibiti ufikiaji wa faili:

• Kuzima ufikiaji wa faili (setAllowFileAccess(false)) kunapunguza ufikiaji wa mfumo wa faili, huku kukiwa na visamaha kwa mali fulani, kuhakikisha zinatumika tu kwa maudhui yasiyo nyeti.

Vipengele Vingine vya Programu na Usimamizi wa Kifaa cha Simu

Saini ya Kidijitali ya Programu

• Saini ya kidijitali ni lazima kwa programu za Android, kuhakikisha zimeandikwa kwa njia halisi kabla ya usakinishaji. Mchakato huu unatumia cheti kwa ajili ya utambulisho wa programu na lazima uhakikishwe na meneja wa pakiti wa kifaa wakati wa usakinishaji. Programu zinaweza kuwa zimejitia saini au kuthibitishwa na CA ya nje, kulinda dhidi ya ufikiaji usioidhinishwa na kuhakikisha programu inabaki bila kubadilishwa wakati wa kuwasilishwa kwa kifaa.

Uhakikisho wa Programu kwa Usalama Bora

• Kuanzia Android 4.2, kipengele kinachoitwa Verify Apps kinawaruhusu watumiaji kuangalia programu kwa usalama kabla ya usakinishaji. Mchakato huu wa uhakikisho unaweza kuwatahadharisha watumiaji dhidi ya programu zenye hatari, au hata kuzuia usakinishaji wa zile zenye uharibifu mkubwa, kuboresha usalama wa mtumiaji.

Usimamizi wa Kifaa cha Simu (MDM)

• MDM solutions zinatoa uangalizi na usalama kwa vifaa vya simu kupitia Device Administration API. Zinahitaji usakinishaji wa programu ya Android ili kusimamia na kulinda vifaa vya simu kwa ufanisi. Kazi kuu ni pamoja na kulazimisha sera za nywila, kulazimisha usimbaji wa hifadhi, na kuruhusu kufuta data kwa mbali, kuhakikisha udhibiti na usalama wa kina juu ya vifaa vya simu.

// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}