Android Applications Basics
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. Kwa hivyo, ni programu yenyewe tu, sehemu fulani za 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 habari, lakini ikiwa moja yao itashambuliwa, data za programu zote mbili zitakuwa hatarini. Hii ndiyo sababu tabia hii inashauriwa kuepukwa.
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 inakomesha 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 programu tu zilizotiwa saini na cheti sawa na ile inayosambaza kipengee zinaweza kupewa ruhusa. Hii ndiyo aina yenye nguvu zaidi ya ulinzi.
SignatureOrSystem: Ni programu tu zilizotiwa saini na cheti sawa na ile inayosambaza kipengee au programu zinazofanya kazi na ufikiaji wa kiwango cha mfumo zinaweza kupewa ruhusa.
Programu Zilizowekwa Kabla
Programu hizi kwa ujumla hupatikana katika /system/app au /system/priv-app directories na baadhi yao zime boreshwa (huenda usipate hata faili ya classes.dex). Programu hizi zina thamani ya kuangaliwa kwa sababu wakati mwingine zinakuwa 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 ujumla unahitaji kufanya exploit 1 au 2 vulnerabilities ambazo huwa maalum kwa kifaa na toleo.
Mara tu exploit inapofanya kazi, kwa kawaida su binary ya Linux inakopishwa kwenye eneo lililotajwa katika PATH env variable ya mtumiaji kama /system/xbin.
Mara tu binary ya su inapokuwa imewekwa, programu nyingine ya Android inatumika kuwasiliana na binary ya su na kusindika maombi ya ufikiaji wa root kama Superuser na SuperSU (inapatikana kwenye Google Play store).
Kumbuka kwamba mchakato wa rooting ni hatari sana na unaweza kuharibu kifaa vibaya
ROMs
Inawezekana kuchukua nafasi ya OS kwa kusakinisha firmware maalum. Kufanya hivi inawezekana kuongeza matumizi ya kifaa cha zamani, kupita vizuizi vya programu au kupata ufikiaji wa msimbo wa hivi karibuni 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. Wakati mwingine watengenezaji wanaruhusu kufungua bootloaders zao kwa njia iliyoandikwa vizuri na salama.
Matokeo
Mara kifaa kinapokuwa kime-rooted, programu yoyote inaweza kuomba ufikiaji kama root. Ikiwa programu mbaya inapata hiyo, inaweza kuwa 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 kinapatikana!
classes.dex
Inashikilia bytecode ya Dalvik, inawakilisha 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 ARMarmeabi-v7a: msimbo wa processors za ARMv7 na za juux86: msimbo wa processors za X86mips: msimbo wa processors za MIPS pekeeassets/
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 mkusanyiko kwa kutafsiri msimbo wa chanzo kuwa maagizo ya bytecode. Smali na baksmali zinarejelea zana za mkusanyiko na uondoshaji katika muktadha huu.
Intents
Intents ni 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 GET/POST requests zinavyotumika katika mawasiliano ya HTTP.
Hivyo, Intent kimsingi ni ujumbe unaopita kati ya vipengele. Intents zinaweza kuelekezwa kwa vipengele au programu maalum, 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 callbacks kushughulikia matukio
Ikiwa ni hatari, Intents zinaweza kutumika kufanya aina mbalimbali za mashambulizi.
Intent-Filter
Mifumo ya Intent inaelezea jinsi shughuli, huduma, au Mpokeaji wa Matangazo yanaweza kuingiliana na aina tofauti za Intents. Kimsingi, zinaelezea uwezo wa vipengele hivi, kama vile ni hatua zipi wanaweza kuchukua au aina gani za matangazo wanaweza kushughulikia. Mahali kuu pa kutangaza mifumo hii ni ndani ya faili ya AndroidManifest.xml, ingawa kwa Mpokeaji wa Matangazo, kuandika hizo pia ni chaguo.
Mifumo ya Intent inajumuisha makundi, hatua, na vichujio vya data, huku ikiwa na uwezekano wa kujumuisha metadata ya ziada. Mpangilio huu unaruhusu vipengele kushughulikia Intents maalum zinazolingana na vigezo vilivyotangazwa.
Sehemu muhimu ya vipengele vya Android (shughuli/huduma/watoa maudhui/mpokeaji wa matangazo) ni uonekano 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 mfumo wa Intent umetangazwa 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 tu zenye ruhusa iliyotengwa zinaweza kufikia kipengele, kuongeza safu ya ziada ya usalama na udhibiti juu ya nani anaweza kuingiliana nayo.
Implicit Intents
Intents huundwa kimaandishi kwa kutumia mjenzi wa Intent:
The Action of the previously declared intent is ACTION_SEND and the Extra is a mailto Uri (the Extra if the extra information the intent is expecting).
Hii intent inapaswa kutangazwa ndani ya manifest kama katika mfano ufuatao:
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:
Katika programu nyingine ili kufikia nia iliyotangazwa hapo awali unaweza kutumia:
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 inaweza 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
Tofauti 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.setPackage.
Vinginevyo, pia inawezekana kueleza ruhusa wakati wa kutuma broadcast. Programu ya mpokeaji itahitaji kuwa na ruhusa hiyo.
Kuna aina mbili za Broadcasts: Kawaida (asynchronous) na Iliyopangwa (synchronous). Mpangilio unategemea kipaumbele kilichowekwa ndani ya mpokeaji kipengele. Kila programu inaweza kushughulikia, kupeleka au kuacha Broadcast.
Inawezekana kutuma broadcast kwa kutumia kazi sendBroadcast(intent, receiverPermission) kutoka kwa darasa la Context.
Unaweza pia kutumia kazi sendBroadcast kutoka kwa LocalBroadCastManager inahakikisha ujumbe hauondoki kwenye programu. Kwa kutumia hii hutahitaji hata kusafirisha kipengele cha mpokeaji.
Sticky Broadcasts
Aina hii ya Broadcasts inaweza kufikiwa muda mrefu baada ya kutumwa. Hizi ziliondolewa 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 kuondoa hizo.
Deep links / URL schemes
Katika programu za Android, deep links zinatumika kuanzisha hatua (Intent) moja kwa moja kupitia URL. Hii inafanywa kwa kutangaza URL scheme maalum ndani ya shughuli. Wakati kifaa cha Android kinapojaribu kufikia URL yenye scheme hii, shughuli iliyotangazwa ndani ya programu inazinduliwa.
Scheme lazima itangazwe katika AndroidManifest.xml faili:
Mpango kutoka kwa mfano wa awali ni exampleapp:// (zingatia pia category BROWSABLE)
Kisha, katika uwanja wa data, unaweza kubainisha host na path:
Ili kuweza kufikia kutoka kwenye wavuti, inawezekana kuweka kiungo kama:
Ili kupata msimbo utakaotekelezwa 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 ya 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
onBindkatika darasa la huduma ni muhimu kwa kuanzisha mwingiliano, ikifanya kuwa eneo muhimu kwa 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 kuanza ni lango kuu la programu, inayozinduliwa unapobofya ikoni ya programu. Imefafanuliwa katika faili ya manifest ya programu kwa nia maalum za MAIN na LAUNCHER:
Sio programu zote zinahitaji shughuli ya kuzindua, 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:
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 ya programu kuanza.
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, ambapo Intents ndiyo njia kuu ya kuzizindua 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 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:
Broadcast Receivers
Broadcast receivers hufanya kazi kama wasikilizaji katika mfumo wa ujumbe, ikiruhusu 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 yanapotumwa, 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 tangazo.
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:
Na mfano wa kufafanua folda zinazoshirikiwa katika filepaths.xml:
For further information check:
WebViews
WebViews ni kama vivinjari vidogo vya wavuti ndani ya programu za Android, vinavyovuta maudhui ama kutoka kwenye wavuti au kutoka kwenye faili za ndani. Vinakabiliwa na hatari sawa na vivinjari vya kawaida, lakini kuna njia za kupunguza hatari hizi kupitia mipangilio maalum.
Android inatoa aina mbili kuu za WebView:
WebViewClient ni nzuri kwa HTML ya msingi lakini haisaidii kazi ya arifa ya JavaScript, ikihusisha jinsi mashambulizi ya XSS yanavyoweza kupimwa.
WebChromeClient inafanya kazi zaidi kama uzoefu kamili wa kivinjari cha Chrome.
Jambo muhimu ni kwamba vivinjari vya WebView havishiriki vidakuzi na kivinjari kikuu cha kifaa.
Kwa ajili ya 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.
JavaScript "Bridge" 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.
Other App Components and Mobile Device Management
Digital Signing of Applications
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 usafirishaji wake kwa kifaa.
App Verification for Enhanced Security
Kuanzia Android 4.2, kipengele kinachoitwa Verify Apps kinawaruhusu watumiaji kuangalia programu kwa usalama kabla ya usakinishaji. Mchakato huu wa uthibitishaji unaweza kuwatahadharisha watumiaji dhidi ya programu zenye hatari, au hata kuzuia usakinishaji wa zile zenye uharibifu mkubwa, kuimarisha usalama wa mtumiaji.
Mobile Device Management (MDM)
MDM solutions zinatoa uangalizi na usalama kwa vifaa vya simu kupitia Device Administration API. Zinahitaji usakinishaji wa programu ya Android ili kudhibiti 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.
Last updated
