Android Applications Basics
Kikundi cha Usalama cha Kujaribu Kwa Bidii
Mfano wa Usalama wa Android
Kuna safu mbili:
OS, ambayo inaweka maombi yaliyosanikishwa kwa mbali kutoka kwa mwingine.
Maombi yenyewe, ambayo inaruhusu watengenezaji ku funua baadhi ya utendaji na kusanidi uwezo wa maombi.
Utofautishaji wa UID
Kila maombi hupewa Kitambulisho cha Mtumiaji maalum. Hii hufanywa wakati wa usanidi wa programu ili programu iweze kuingiliana tu na faili zilizomilikiwa na Kitambulisho chake cha Mtumiaji au faili zilizoshirikiwa. Kwa hivyo, ni programu yenyewe, sehemu fulani za OS na mtumiaji wa msingi tu wanaweza kupata data za programu.
Kushiriki UID
Maombi mawili yanaweza kusanidiwa kutumia UID sawa. Hii inaweza kuwa na manufaa kushiriki habari, lakini ikiwa moja yao itashambuliwa data ya maombi yote itashambuliwa. Ndio maana tabia hii ina kukataliwa.
Ili kushiriki UID sawa, maombi lazima yatamke thamani sawa ya android:sharedUserId katika mizizi yao.
Sandboxing
Sanbox ya Maombi ya Android inaruhusu kufanya kazi kila maombi kama mchakato tofauti chini ya Kitambulisho cha Mtumiaji tofauti. Kila mchakato una mashine yake ya kisasa, hivyo msimbo wa programu unafanya kazi kivyake kutoka kwa programu nyingine. Kuanzia Android 5.0(L) SELinux inatekelezwa. Kimsingi, SELinux ilikataa mwingiliano wa mchakato wote na kisha iliunda sera za kuruhusu mwingiliano uliotarajiwa kati yao tu.
Ruhusa
Unapoweka programu na inauliza ruhusa, programu inauliza ruhusa zilizosanidiwa katika vipengele vya uses-permission katika faili ya AndroidManifest.xml. Kipengele cha uses-permission kinaonyesha jina la ruhusa inayohitajika ndani ya sifa ya jina. Pia ina sifa ya maxSdkVersion ambayo inazuia kuuliza ruhusa kwenye toleo zaidi ya lile lililoelezwa.
Tambua kwamba maombi ya android hayahitaji kuuliza ruhusa zote mwanzoni, wanaweza pia kuuliza ruhusa kwa kudhibiti lakini ruhusa zote lazima zitangazwe katika mizizi.
Wakati programu inafunua utendaji inaweza kikomo upatikanaji kwa maombi tu yenye ruhusa iliyotajwa. Kipengele cha ruhusa kina sifa tatu:
Jina la ruhusa
Sifa ya kikundi cha ruhusa, ambayo inaruhusu kikundi cha ruhusa kinachohusiana.
Kiwanja cha ulinzi ambacho kinaonyesha jinsi ruhusa zinavyotolewa. Kuna aina nne:
Kawaida: Hutumiwa wakati hakuna tishio lililojulikana kwa programu. Mtumiaji hahitajiki kuidhinisha.
Hatari: Inaonyesha ruhusa inayompa maombi yanayotaka upatikanaji ulioinuliwa. Watumiaji wanahitajika kuidhinisha.
Sahihi: Maombi yaliyosainiwa na cheti kile kile kinachotumia kipengee kinaweza kupewa ruhusa. Hii ni aina yenye nguvu zaidi ya ulinzi.
SahihiAuMfumo: Maombi yaliyosainiwa na cheti kile kile kinachotumia kipengee au maombi yanayotumia upatikanaji wa kiwango cha mfumo yanaweza kupewa ruhusa
Maombi Yaliyosanikishwa Kabla
Maombi haya kwa kawaida hupatikana katika /system/app au /system/priv-app na baadhi yao ni yaliyoboreshwa (unaweza hata usipate faili ya classes.dex). Maombi haya ni muhimu kuchunguza kwa sababu mara nyingi yanakuwa yakifanya kazi na ruhusa nyingi sana (kama mtumiaji wa msingi).
Yaliyotumwa na AOSP (Mradi wa Chanzo Wazi wa Android) ROM
Yaliyotolewa na mtengenezaji wa kifaa
Yaliyotolewa na mtoa huduma wa simu (ikiwa imeununuliwa kutoka kwao)
Kuroot
Ili kupata ufikiaji wa msingi kwenye kifaa cha android unahitaji kwa ujumla kutumia 1 au 2 udhaifu ambao kawaida huwa maalum kwa kifaa na toleo.
Baada ya udhaifu kufanya kazi, kawaida su ya Linux inakopiwa kwenye eneo lililoelezwa katika PATH env variable ya mtumiaji kama vile /system/xbin.
Baada ya su binary kuwekwa, programu nyingine ya Android hutumiwa kuingiliana na su binary na kutuma maombi ya ufikiaji wa msingi kama Superuser na SuperSU (inapatikana kwenye duka la Google Play).
Tambua kwamba mchakato wa kuroot ni hatari sana na unaweza kuharibu vibaya kifaa
ROMs
Inawezekana kubadilisha OS kwa kusanikisha firmware ya desturi. Kufanya hivi inawezekana kuongeza matumizi ya kifaa cha zamani, kuepuka vizuizi vya programu au kupata ufikiaji wa msimbo wa Android wa hivi karibuni. OmniROM na LineageOS ni moja ya firmware maarufu zaidi kutumia.
Tambua kwamba sio lazima kila wakati kuroot kifaa kusanikisha firmware ya desturi. Baadhi ya watengenezaji huruhusu kufungua bootloader zao kwa njia iliyodokezwa vizuri na salama.
Matokeo
Marakwet kifaa kimeroot, programu yoyote inaweza kuomba ufikiaji kama msingi. Ikiwa programu mbaya inapata, inaweza kupata ufikiaji wa karibu kila kitu na itaweza kuharibu simu.
Misingi ya Maombi ya Android
Muundo wa maombi ya Android unaitwa muundo wa faili wa APK. Kimsingi ni faili ya ZIP (kwa kubadilisha jina la kielelezo cha faili kuwa .zip, maudhui yanaweza kuchimbuliwa na kuonekana).
Yaliyomo ya APK (Hayakamilishi)
AndroidManifest.xml
resources.arsc/strings.xml
resources.arsc: ina rasilimali zilizopangwa mapema, kama XML ya binary.
res/xml/files_paths.xml
META-INF/
Hapa ndipo Cheti lilipo!
classes.dex
Ina bytecode ya Dalvik, ikionyesha msimbo uliokompiliwa wa Java (au Kotlin) ambao programu inatekeleza kwa chaguo-msingi.
lib/
Ina maktaba za asili, zilizogawanywa kulingana na muundo wa CPU katika saraka za sekondari.
armeabi: msimbo kwa processors za msingi wa ARMarmeabi-v7a: msimbo kwa processors za ARMv7 na zaidix86: msimbo kwa processors za X86mips: msimbo kwa processors za MIPS pekeeassets/
Inahifadhi faili mbalimbali zinazohitajika na programu, pamoja na maktaba za asili au faili za DEX zaidi, mara nyingi hutumiwa na waandishi wa programu hasidi kuficha msimbo zaidi.
res/
Ina rasilimali ambazo hazijakusanywa katika resources.arsc
Dalvik & Smali
Katika maendeleo ya Android, Java au Kotlin hutumiwa kuunda programu. Badala ya kutumia JVM kama katika programu za desktop, Android inakusanya nambari hii kuwa Dalvik Executable (DEX) bytecode. Zamani, mashine ya kawaida ya Dalvik ilishughulikia bytecode huu, lakini sasa, Android Runtime (ART) inachukua jukumu hili katika toleo jipya la Android.
Kwa uhandisi wa nyuma, Smali inakuwa muhimu. Ni toleo linaloweza kusomwa na binadamu la DEX bytecode, likifanya kazi kama lugha ya mkutano kwa kutafsiri nambari ya chanzo kuwa maagizo ya bytecode. Smali na baksmali hurejelea zana za mkutano na kuvunja tena katika muktadha huu.
Intents
Intents ni njia kuu ambayo programu za Android zinawasiliana kati ya vipengele vyao au na programu nyingine. Vitu hivi vya ujumbe pia vinaweza kubeba data kati ya programu au kipengele, kama jinsi maombi ya GET/POST yanavyotumiwa katika mawasiliano ya HTTP.
Kwa hivyo, Intent ni ujumbe unaopitishwa kati ya vipengele. Intents zinaweza kuwa zimeelekezwa kwa vipengele au programu maalum, au zinaweza kutumwa bila mpokeaji maalum. Ili kuwa rahisi, Intent inaweza kutumika:
Kuanza Shughuli, kwa kawaida kufungua kiolesura cha mtumiaji kwa programu
Kama matangazo ya kuarifu mfumo na programu za mabadiliko
Kuanza, kusimamisha, na kuwasiliana na huduma ya nyuma
Kupata data kupitia Watoaji wa Yaliyomo
Kama maagizo ya kushughulikia matukio
Ikiwa ina kasoro, Intents zinaweza kutumika kufanya aina mbalimbali za mashambulizi.
Intent-Filter
Intent Filters hufafanua jinsi shughuli, huduma, au Mpokeaji wa Matangazo wanavyoweza kuingiliana na aina tofauti za Intents. Kimsingi, hufafanua uwezo wa vipengele hivi, kama vile vitendo wanavyoweza kutekeleza au aina za matangazo wanazoweza kusindika. Mahali kuu pa kutangaza vichungi hivi ni ndani ya faili ya AndroidManifest.xml, ingawa kwa Mpokeaji wa Matangazo, kuandika ni chaguo pia.
Intent Filters zimeundwa na vikundi, vitendo, na vichungi vya data, na uwezekano wa kuingiza metadata ziada. Hii inaruhusu vipengele kushughulikia Intents maalum ambazo zinalingana na vigezo vilivyotangazwa.
Jambo muhimu la vipengele vya Android (shughuli/huduma/watoaji wa yaliyomo/mpokeaji wa matangazo) ni uonekano wao au hali ya umma. Kipengele kinachukuliwa kuwa cha umma na kinaweza kuingiliana na programu nyingine ikiwa kina exported na thamani ya true au ikiwa Intent Filter imetangazwa kwa hiyo katika maelezo ya kimaandishi. Walakini, kuna njia kwa watengenezaji kudumisha vipengele hivi kuwa binafsi, kuhakikisha kuwa havichangiliani na programu nyingine kwa bahati mbaya. Hii inafanikiwa kwa kuweka sifa ya exported kuwa false katika ufafanuzi wao wa maelezo.
Zaidi ya hayo, watengenezaji wana chaguo la kufikia upatikanaji wa vipengele hivi zaidi kwa kuhitaji ruhusa maalum. Sifa ya permission inaweza kuwekwa ili kuhakikisha kuwa ni programu zenye ruhusa iliyopewa tu ndizo zinaweza kupata kipengele, kuongeza safu ya ziada ya usalama na udhibiti juu ya ni nani anaweza kuingiliana nacho.
Nia Zisizo Dhahiri
Nia hutengenezwa kwa kutumia kujenga kwa programu kwa kutumia kujenga kwa Nia:
Hatua ya nia iliyotangazwa awali ni ACTION_SEND na Zaidi ni mailto Uri (Zaidi ni habari ya ziada ambayo nia inatarajia).
Nia hii inapaswa kutangazwa ndani ya mwonekano kama ilivyo katika mfano ufuatao:
Intent-filter inahitaji kufanana na action, data na category ili kupokea ujumbe.
Mchakato wa "Uamuzi wa Intent" unahusisha kujua ni app gani itapokea kila ujumbe. Mchakato huu unazingatia sifa ya kipaumbele, ambayo inaweza kuwekwa katika tamko la intent-filter, na ile yenye kipaumbele kikubwa zaidi itachaguliwa. Kipaumbele hiki kinaweza kuwekwa kati ya -1000 na 1000 na programu zinaweza kutumia thamani ya SYSTEM_HIGH_PRIORITY. Ikiwa mgogoro unatokea, Dirisha la "choser" linaonekana ili mtumiaji aweze kuchagua.
Intents Dhahiri
Intent dhahiri inabainisha jina la darasa inayolengwa:
Katika programu nyingine ili kupata kusudio lililotangazwa hapo awali unaweza kutumia:
Pending Intents
Hizi huruhusu programu zingine kuchukua hatua kwa niaba ya programu yako, zikitumia kitambulisho na ruhusa za programu yako. Kujenga Pending Intent inapaswa kufafanua nia na hatua ya kutekeleza. Ikiwa nia iliyotangazwa sio Wazi (haifafanui ni nia gani inaweza kuita), programu hasidi inaweza kutekeleza hatua iliyotangazwa kwa niaba ya programu ya mwathiriwa. Zaidi ya hayo, ikiwa hatua haijatajwa, programu hasidi itaweza kufanya hatua yoyote kwa niaba ya mwathiriwa.
Broadcast Intents
Tofauti na nia za awali, ambazo hupokelewa na programu moja tu, nia za matangazo zinaweza kupokelewa na programu nyingi. Walakini, kuanzia toleo la API 14, ni rahisi kufafanua programu inayopaswa kupokea ujumbe kwa kutumia Intent.set Package.
Kwa kuongezea, ni rahisi pia kufafanua ruhusa wakati wa kutuma matangazo. Programu ya kupokea itahitaji kuwa na ruhusa hiyo.
Kuna aina mbili za Matangazo: Kawaida (asynchronous) na Yaliyopangwa (synchronous). Mpangilio unategemea kipaumbele kilichowekwa ndani ya kipokeaji. Kila programu inaweza kusindika, kusambaza, au kudondosha Matangazo.
Inawezekana kutuma tangazo kwa kutumia kazi sendBroadcast(intent, receiverPermission) kutoka darasa la Context. Unaweza pia kutumia kazi sendBroadcast kutoka kwa LocalBroadCastManager kuhakikisha ujumbe hauondoki kamwe kwenye programu. Kwa kutumia hii, hata hautahitaji kuuza kipokeaji.
Matangazo ya Sticky
Aina hii ya Matangazo inaweza kupatikana muda mrefu baada ya kutumwa. Hizi zilipitwa na wakati katika kiwango cha API 21 na inapendekezwa kutokuzitumia. Zinaruhusu programu yoyote kunusa data, lakini pia kuihariri.
Ikiwa unapata kazi zinazoleta neno "sticky" kama sendStickyBroadcast au sendStickyBroadcastAsUser, angalia athari na jaribu kuziondoa.
Viungo vya Kina / Mbinu za URL
Katika programu za Android, viungo vya kina hutumiwa kuanzisha hatua (Nia) moja kwa moja kupitia URL. Hii hufanywa kwa kutangaza mpango maalum wa URL ndani ya shughuli. Wakati kifaa cha Android kinajaribu kupata URL na mpango huu, shughuli iliyotajwa ndani ya programu inazinduliwa.
Mpango huo lazima utangazwe katika faili ya AndroidManifest.xml:
Schemu kutoka kwa mfano uliopita ni exampleapp:// (pia kumbuka jamii BROWSABLE)
Kisha, katika uga wa data, unaweza kufafanua host na path:
Kuipata kutoka kwenye wavuti ni rahisi kuweka kiungo kama:
Ili kupata msimbo utakaotekelezwa kwenye Programu, nenda kwenye shughuli iliyoitwa na kiungo kirefu na tafuta kazi ya onNewIntent.
Jifunze jinsi ya kuita viungo vya kina bila kutumia kurasa za HTML.
AIDL - Lugha ya Ufafanuzi wa Interface ya Android
Lugha ya Ufafanuzi wa Interface ya Android (AIDL) imeundwa kwa kusaidia mawasiliano kati ya mteja na huduma katika programu za Android kupitia mawasiliano kati ya michakato (IPC). Kwa kuwa kupata kumbukumbu ya michakato nyingine moja kwa moja hairuhusiwi kwenye Android, AIDL inasimplisha mchakato kwa kubadilisha vitu kuwa muundo unaoeleweka na mfumo wa uendeshaji, hivyo kurahisisha mawasiliano kati ya michakato tofauti.
Dhana Kuu
Huduma Zilizounganishwa: Huduma hizi hutumia AIDL kwa IPC, kuruhusu shughuli au sehemu kubana kwenye huduma, kutuma maombi, na kupokea majibu. Mbinu ya
onBindkatika darasa la huduma ni muhimu kwa kuanzisha mwingiliano, ikiiweka kama eneo muhimu sana la ukaguzi wa usalama kutafuta mapungufu.Mtume (Messenger): Kufanya kazi kama huduma iliyobana, Mtume inarahisisha IPC kwa kuzingatia usindikaji wa data kupitia mbinu ya
onBind. Ni muhimu kukagua mbinu hii kwa karibu kwa kushughulikia data zisizo salama au utekelezaji wa kazi nyeti.Kifungu (Binder): Ingawa matumizi moja kwa moja ya darasa la Binder ni nadra kutokana na ujumuishaji wa AIDL, ni faida kuelewa kuwa Binder hufanya kazi kama dereva wa kiwango cha kernel kurahisisha uhamishaji wa data kati ya nafasi za kumbukumbu za michakato tofauti. Kwa uelewa zaidi, rasilimali inapatikana kwenye https://www.youtube.com/watch?v=O-UHvFjxwZ8.
Vipengele
Hivi ni pamoja na: Shughuli (Activities), Huduma (Services), Wapokeaji wa Matangazo (Broadcast Receivers) na Watoaji (Providers).
Shughuli ya Kuzindua na shughuli nyingine
Katika programu za Android, shughuli (activities) ni kama skrini, zikionyesha sehemu tofauti za interface ya mtumiaji wa programu. Programu inaweza kuwa na shughuli nyingi, kila moja ikiwasilisha skrini ya kipekee kwa mtumiaji.
Shughuli ya kuzindua (launcher activity) ni lango kuu kwenye programu, inayoanzishwa unapobonyeza picha ya programu. Imedefiniwa kwenye faili ya maelezo ya programu na nia maalum za MAIN na LAUNCHER:
Haitaji shughuli ya kuzindua, hasa zile bila kiolesura cha mtumiaji, kama huduma za nyuma.
Shughuli zinaweza kuwa zinapatikana kwa programu nyingine au michakato kwa kuziweka kama "zilizopatikana" kwenye hati ya maandishi. Kuweka hili huruhusu programu nyingine kuanza shughuli hii:
Hata hivyo, kufikia shughuli kutoka kwa programu nyingine sio hatari ya usalama kila wakati. Wasiwasi unatokea ikiwa data nyeti inashirikishwa kwa njia isiyofaa, ambayo inaweza kusababisha uvujaji wa habari.
Mzunguko wa maisha wa shughuli huanza na njia ya onCreate, kuweka UI na kujiandaa kwa shughuli kuingiliana na mtumiaji.
Darasa la Maombi
Katika maendeleo ya Android, programu ina chaguo la kuunda darasa la mshale la Maombi, ingawa sio lazima. Wakati darasa la mshale linapofafanuliwa, linakuwa darasa la kwanza kuanzishwa ndani ya programu. Njia ya attachBaseContext, ikiwa imeanzishwa katika darasa hili, inatekelezwa kabla ya njia ya onCreate. Hii inaruhusu kwa kuanzisha mapema kabla ya sehemu nyingine ya maombi kuanza.
Huduma
Huduma ni wafanyikazi wa nyuma wenye uwezo wa kutekeleza kazi bila kiolesura cha mtumiaji. Kazi hizi zinaweza kuendelea hata wakati watumiaji wanabadilisha programu tofauti, hivyo huduma ni muhimu kwa shughuli ndefu.
Huduma ni za kubadilika; zinaweza kuanzishwa kwa njia mbalimbali, na Intents ikiwa njia kuu ya kuziendesha kama sehemu ya kuingia ya programu. Mara tu huduma inapoanzishwa kwa kutumia mbinu ya startService, mbinu yake ya onStart huanza kufanya kazi na kuendelea hadi mbinu ya stopService itakapoitwa kwa uwazi. Vinginevyo, ikiwa jukumu la huduma linategemea uhusiano wa mteja ulio hai, mbinu ya bindService hutumiwa kuunganisha mteja na huduma, ikishirikisha mbinu ya onBind kwa kupitisha data.
Matumizi ya kuvutia ya huduma ni pamoja na kucheza muziki wa nyuma au kupata data ya mtandao bila kuzuia mwingiliano wa mtumiaji na programu. Zaidi ya hayo, huduma zinaweza kuwa kupatikana kwa michakato mingine kwenye kifaa kimoja kupitia kupeleka. Hii sio tabia ya msingi na inahitaji usanidi wa wazi kwenye faili ya Android Manifest:
Wapokeaji wa Matangazo
Wapokeaji wa matangazo 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 Mwongozo wa programu au kwa njia ya kudhibiti ndani ya msimbo wa programu kupitia API ya registerReceiver. Katika Mwongozo, matangazo hufafanuliwa kwa idhini, wakati wapokeaji waliojiandikisha kwa njia ya kudhibiti wanaweza pia kufafanua idhini wakati wa usajili.
Vichujio vya nia ni muhimu katika njia zote za usajili, kufafanua ni matangazo gani yanasababisha mpokeaji kufanya kazi. Mara tu tangazo linalolingana linapotumwa, njia ya onReceive ya mpokeaji huitwa, ikiruhusu programu kureagiria ipasavyo, kama vile kurekebisha tabia kujibu onyo la betri ya chini.
Matangazo yanaweza kuwa ya kiasinkroni, yakifikia wapokeaji wote bila mpangilio, au ya kusinkroni, ambapo wapokeaji wanapata tangazo kulingana na vipaumbele vilivyowekwa. Walakini, ni muhimu kutambua hatari ya usalama, kwani programu yoyote inaweza kujipa kipaumbele ili kuvuruga tangazo.
Ili kuelewa utendaji wa mpokeaji, tafuta njia ya onReceive ndani ya darasa lake. Msimbo wa njia hii unaweza kubadilisha Nia iliyopokelewa, ikisisitiza umuhimu wa ukaguzi wa data na wapokeaji, hasa katika Matangazo Yaliyoagizwa, ambayo yanaweza kurekebisha au kudondosha Nia.
Mtoaji wa Yaliyomo
Watoaji wa Yaliyomo ni muhimu kwa kushiriki data iliyopangiliwa kati ya programu, ikisisitiza umuhimu wa kutekeleza idhini kuhakikisha usalama wa data. Wao huruhusu programu kupata data kutoka vyanzo mbalimbali, ikiwa ni pamoja na mabadiliko, mfumo wa faili, au wavuti. Idhini maalum, kama readPermission na writePermission, ni muhimu kwa kudhibiti upatikanaji. Aidha, upatikanaji wa muda unaweza kuruhusiwa kupitia mipangilio ya grantUriPermission katika mwongozo wa programu, ikichangamana na sifa kama vile path, pathPrefix, na pathPattern kwa kudhibiti upatikanaji kwa undani.
Uthibitishaji wa kuingiza ni muhimu kuzuia udhaifu, kama vile kuingiza SQL. Watoaji wa Yaliyomo hutoa operesheni za msingi: insert(), update(), delete(), na query(), kurahisisha upangilizi wa data na kushiriki kati ya programu.
FileProvider, Mtoaji wa Yaliyomo maalum, unazingatia kushiriki faili kwa usalama. Imetajwa katika mwongozo wa programu na sifa maalum za kudhibiti upatikanaji wa folda, zikionyeshwa na android:exported na android:resource inayoelekeza kwa mipangilio ya folda. Tahadhari inashauriwa wakati wa kushiriki saraka ili kuepuka kufunua data nyeti kwa bahati mbaya.
Mfano wa tangazo la mwongozo kwa FileProvider:
Na mfano wa kueleza folda zilizoshirikiwa katika filepaths.xml:
Kwa maelezo zaidi angalia:
WebViews
WebViews ni kama vivinjari vidogo vya wavuti ndani ya programu za Android, vinavyovuta yaliyomo kutoka kwenye wavuti au kutoka kwenye faili za ndani. Wanakabili hatari kama vivinjari vya kawaida, lakini kuna njia za kupunguza hatari hizi kupitia vipimo maalum.
Android inatoa aina mbili kuu za WebView:
WebViewClient ni nzuri kwa HTML ya msingi lakini haishikilii kazi ya onyo ya JavaScript, ikiaathiri jinsi mashambulizi ya XSS yanavyoweza kujaribiwa.
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 kupakia yaliyomo, njia kama loadUrl, loadData, na loadDataWithBaseURL zinapatikana. Ni muhimu kuhakikisha kuwa URL au faili hizi ni salama kutumia. Vipimo vya usalama vinaweza kusimamiwa kupitia darasa la WebSettings. Kwa mfano, kulemaza JavaScript na setJavaScriptEnabled(false) kunaweza kuzuia mashambulizi ya XSS.
"Bridge" ya JavaScript inaruhusu vitu vya Java kuingiliana na JavaScript, ikihitaji njia zitambuliwe na @JavascriptInterface kwa usalama kutoka Android 4.2 kuendelea.
Kuruhusu ufikiaji wa yaliyomo (setAllowContentAccess(true)) inaruhusu WebViews kufikia Watoa Huduma wa Yaliyomo, ambayo inaweza kuwa hatari isipokuwa URL za yaliyomo zimehakikiwa kuwa salama.
Kudhibiti ufikiaji wa faili:
Kulemaza ufikiaji wa faili (
setAllowFileAccess(false)) kunapunguza ufikiaji wa mfumo wa faili, na matakwa kwa mali fulani, kuhakikisha zinatumika tu kwa yaliyomo yasiyo ya siri.
Sehemu Nyingine za Programu na Usimamizi wa Kifaa cha Simu
Kusainiwa Kidijitali kwa Programu
Kusainiwa kidijitali ni lazima kwa programu za Android, ikihakikisha zimeandikwa kwa uhalisia kabla ya usakinishaji. Mchakato huu hutumia cheti kwa utambulisho wa programu na lazima ithibitishwe na msimamizi wa pakiti ya kifaa wakati wa usakinishaji. Programu zinaweza kuwa zilizojisaini au kuthibitishwa na CA ya nje, zikilinda dhidi ya ufikiaji usioidhinishwa na kuhakikisha programu inabaki bila kuguswa wakati wa kufikishwa kwenye kifaa.
Uhakiki wa Programu kwa Usalama Ulioboreshwa
Kuanzia Android 4.2, kipengele kinachoitwa Thibitisha Programu kuruhusu watumiaji kupata programu zilizochunguzwa kwa usalama kabla ya usakinishaji. Mchakato huu wa uhakiki unaweza kuonya watumiaji dhidi ya programu zenye hatari, au hata kuzuia usakinishaji wa zile zenye nia hasidi, ikiboresha usalama wa mtumiaji.
Usimamizi wa Kifaa cha Simu (MDM)
Suluhisho za MDM hutoa usimamizi na usalama kwa vifaa vya simu kupitia API ya Usimamizi wa Kifaa. Wanahitaji usakinishaji wa programu ya Android kusimamia na kuhakikisha usalama wa vifaa vya simu kwa ufanisi. Majukumu muhimu ni pamoja na kuweka sera za nywila, kuamuru kifaa cha kuhifadhi data, na kuruhusu kufuta data kwa mbali, ikihakikisha udhibiti na usalama kamili juu ya vifaa vya simu.
Kikundi cha Usalama cha Try Hard
Last updated
