Android Applications Basics
Kundi la Usalama wa Jaribio la Bidhaa
Mfano wa Usalama wa Android
Kuna tabaka mbili:
OS, ambayo inashikilia maombi yaliyowekwa mbali na kila mmoja.
maombi yenyewe, ambayo inaruhusu waendelezaji kuweka wazi kazi fulani na kuunda uwezo wa maombi.
Kutenganisha UID
Kila ombi linapewa Kitambulisho Maalum cha Mtumiaji. Hii inafanywa wakati wa usakinishaji wa ombi ili ombile linaweza kuingiliana tu na faili zinazomilikiwa na Kitambulisho chake cha Mtumiaji au faili zilizoshirikiwa. Hivyo, ni ombi lenyewe tu, vipengele fulani vya OS na mtumiaji wa root wanaweza kufikia data za maombi.
Kushiriki UID
Maombi mawili yanaweza kuwekewa mipangilio kutumia UID sawa. Hii inaweza kuwa na manufaa kushiriki habari, lakini ikiwa moja yao itashambuliwa, data za maombi yote mawili zitakuwa hatarini. Hii ndiyo sababu tabia hii inashauriwa kuepukwa.
Ili kushiriki UID sawa, maombi lazima yainishe thamani sawa ya android:sharedUserId katika hati zao.
Sandboxing
Android Application Sandbox inaruhusu kuendesha kila ombi kama mchakato tofauti chini ya Kitambulisho cha Mtumiaji tofauti. Kila mchakato una mashine yake ya virtual, hivyo msimbo wa ombi unakimbia kwa kujitenga na maombi mengine. 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 ombile na linaomba ruhusa, ombi linaomba ruhusa zilizowekwa katika vipengele vya uses-permission katika faili ya AndroidManifest.xml. Kipengele cha uses-permission kinaonyesha jina la ruhusa inayohitajika ndani ya attribute ya jina. Pia ina maxSdkVersion attribute ambayo inakomesha kuomba ruhusa kwenye toleo lililo juu ya lile lililotajwa.
Kumbuka kwamba maombi ya android hayahitaji kuomba ruhusa zote mwanzoni, yanaweza pia kuomba ruhusa kwa njia ya kidijitali lakini ruhusa zote lazima zitangazwe katika manifest.
Wakati ombi linapoweka wazi kazi, linaweza kupunguza ufikiaji kwa maombi tu ambayo yana ruhusa maalum. Kipengele cha ruhusa kina attributes tatu:
jina la ruhusa
attribute ya kundi la ruhusa, ambayo inaruhusu kuunganisha ruhusa zinazohusiana.
kiwango cha ulinzi ambacho kinaonyesha jinsi ruhusa zinavyotolewa. Kuna aina nne:
Kawaida: Inatumika wakati hakuna hatari zinazojulikana kwa ombi. Mtumiaji huhitajika kuidhinisha.
Hatari: Inaonyesha ruhusa inatoa ombi linalohitaji ufikiaji wa juu. Watumiaji wanahitajika kuidhinisha.
Sahihi: Ni maombi tu yaliyosainiwa na cheti sawa na kile kinachosafirisha kipengele yanaweza kupewa ruhusa. Hii ndiyo aina yenye nguvu zaidi ya ulinzi.
SahihiAuMfumo: Ni maombi tu yaliyosainiwa na cheti sawa na kile kinachosafirisha kipengele au maombi yanayoendesha kwa ufikiaji wa kiwango cha mfumo yanaweza kupewa ruhusa.
Maombi Yaliyosakinishwa Kabla
Maombi haya kwa ujumla hupatikana katika /system/app au /system/priv-app directories na baadhi yao yame boreshwa (huenda usipate hata faili ya classes.dex). Maombi haya yanastahili kuangaliwa kwa sababu wakati mwingine yanaweza kuwa yanakimbia na ruhusa nyingi sana (kama root).
Yaliyotolewa na AOSP (Mradi wa Msource wa Android) ROM
Yaliyoongezwa na mtengenezaji wa kifaa
Yaliyoongezwa na mtoa huduma wa simu (ikiwa imenunuliwa kutoka kwao)
Rooting
Ili kupata ufikiaji wa root kwenye kifaa halisi cha android kwa ujumla unahitaji kufanya matumizi ya udhaifu 1 au 2 ambayo huwa maalum kwa kifaa na toleo.
Mara tu udhaifu umefanikiwa, kwa kawaida faili ya su ya Linux inakopishwa kwenye eneo lililotajwa katika mabadiliko ya mazingira ya mtumiaji kama /system/xbin.
Mara tu faili ya su inapoanzishwa, ombi lingine la Android linatumika kuungana na faili ya su na kusindika maombi ya ufikiaji wa root kama Superuser na SuperSU (inapatikana kwenye duka la Google Play).
Kumbuka kwamba mchakato wa rooting ni hatari sana na unaweza kuharibu kifaa vibaya
ROMs
Inawezekana kurekebisha 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 wengine wa watengenezaji wanaruhusu kufungua bootloaders zao kwa njia iliyoandikwa vizuri na salama.
Matokeo
Mara kifaa kinapokuwa kime-rooted, ombi lolote linaweza kuomba ufikiaji kama root. Ikiwa ombi la uhalifu litapata ufikiaji huo, linaweza kuwa na ufikiaji wa karibu kila kitu na linaweza kuharibu simu.
Msingi wa Maombi ya Android
Muundo wa maombi ya Android unajulikana kama muundo wa faili ya APK. Kimsingi ni faili ya ZIP (kwa kubadilisha kiambishi cha faili kuwa .zip, yaliyomo yanaweza kutolewa na kuangaliwa).
Yaliyomo 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 ombi linaendesha kwa default.
lib/
Inashikilia maktaba za asili, zilizogawanywa kwa usanifu wa CPU katika saraka ndogo.
armeabi: msimbo wa processors za msingi wa ARMarmeabi-v7a: msimbo wa processors za ARMv7 na juux86: msimbo wa processors za X86mips: msimbo wa processors za MIPS pekeeassets/
Inahifadhi faili mbalimbali zinazohitajika na ombi, huenda ikijumuisha maktaba za asili za ziada 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 maombi. Badala ya kutumia JVM kama katika maombi ya 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 hilo katika matoleo mapya ya 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 maombi ya Android yanawasiliana kati ya vipengele vyake au na maombi mengine. Hizi ni vitu vya ujumbe vinaweza pia kubeba data kati ya maombi 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 au maombi maalum, au zinaweza kutumwa bila mpokeaji maalum. Ili kuwa rahisi, Intent inaweza kutumika:
Kuanzisha Activity, kwa kawaida kufungua kiolesura cha mtumiaji kwa ombi
Kama matangazo ya kuarifu mfumo na maombi kuhusu mabadiliko
Kuanzisha, kusitisha, na kuwasiliana na huduma ya nyuma
Kupata data kupitia ContentProviders
Kama kurudi nyuma kushughulikia matukio
Ikiwa kuna udhaifu, 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.
Sehemu 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 maombi mengine 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 maombi mengine bila kukusudia. Hii inafanywa kwa kuweka exported attribute kuwa false katika ufafanuzi wao wa 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 maombi tu yenye ruhusa iliyotolewa yanaweza 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 kueleza 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
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 matangazo. Programu ya mpokeaji itahitaji kuwa na ruhusa hiyo.
Kuna aina mbili za Matangazo: 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 ziliondolewa katika kiwango cha API 21 na inashauriwa usizitumie. Zinawaruhusu programu yoyote kunusa data, lakini pia kuibadilisha.
Ikiwa unapata kazi zenye 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 faili ya AndroidManifest.xml:
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 haukubaliwi 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.
Subclass ya Programu
Katika maendeleo ya Android, programu ina chaguo la kuunda subclass ya Application darasa, ingawa si lazima. Wakati subclass kama hiyo imefafanuliwa, inakuwa darasa la kwanza kuanzishwa ndani ya programu. Njia ya attachBaseContext, ikiwa imeanzishwa katika subclass 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 uthibitisho 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.
Uthibitisho 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 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
Sahihi 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 zinazoweza kuwa 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.
Try Hard Security Group
Last updated
