Ligtas na App Pinakamahusay na Kasanayan Para sa Mas mahusay na Cyber Security
Sa edad ng nakataas at mataas na iba't ibang mga vectors para sa mga banta sa seguridad sa cyber, ang pagpapanatili ng mabuting kalinisan upang maprotektahan ang iyong mga gumagamit ng app ay kritikal para sa kaligtasan ng gumagamit ng app, mamimili, at app.
Habang ang diskarte at pamamaraan na pinili upang maprotektahan ang kaligtasan ng gumagamit ng app ay depende sa kung anong pag andar ang ibinibigay ng app sa mga gumagamit, ang mga sumusunod na kasanayan ay dapat na nasa harap ng isip para sa mga developer:
Pagpapatunay
Awtorisasyon
Pag iimbak ng data
Panlaban at pambabaliktad
Let's delve sa bawat isa sa apat na lugar.
Pagpapatunay
Patunayan ang pagkakakilanlan ng gumagamit at tiyakin ang lehitimong pag access. Kabilang sa mga halimbawa ang biometrics, personal identification numbers o multi factor authentication code generators.
Ipatupad ang isang bagay na alam mo ang pagpapatunay bilang isa sa mga kadahilanan ng MFA.
Ang Isang Bagay na Alam Mo ay kumakatawan sa isang pangunahing layer ng pag verify ng pagkakakilanlan na kinasasangkutan ng impormasyon na kilala lamang ng gumagamit, tulad ng isang PIN (Personal na Numero ng Pagkakakilanlan), password, pattern, atbp.
Ang pagpapatupad ng Isang Bagay na Alam Mo bilang isa sa mga kadahilanan ng MFA ay nagsisiguro ng isang pangunahing antas ng pag verify ng pagkakakilanlan sa pamamagitan ng paghiling sa mga gumagamit na magbigay ng natatanging impormasyon na nauugnay sa kanilang mga account.
Ipatupad ang isang bagay na mayroon kang pagpapatunay bilang isa sa mga kadahilanan ng MFA.
Ang Isang Bagay na Iyong Mayroon ay nangangailangan ng mga gumagamit na magpatunay gamit ang isang pisikal na aparato, app, o token na bumubuo ng mga kredensyal sa pagpapatunay, na maaaring kabilang ang mga One Time Password (OTPs) na nakabatay sa oras. Ang mga halimbawa ng naturang token ay kinabibilangan ng mga token ng software, mga token ng hardware, at SMS OTP.
Ang pagpapatupad ng Isang Bagay na Mayroon Ka bilang isa sa mga kadahilanan ng MFA ay nagdaragdag ng pagiging kumplikado sa proseso ng pagpapatunay sa pamamagitan ng paghiling ng pagkakaroon ng isang nasasalat na elemento, makabuluhang pagbabawas ng posibilidad ng hindi awtorisadong pag access.
Dapat gumamit ang mga developer ng OTP na nakabatay sa oras para sa mga token ng software, token ng hardware at SMS OTP. Ang mga sumusunod na patnubay ay dapat sundin:
Ang isang OTP ay dapat lamang na may bisa para sa hindi hihigit sa 30 segundo.
Ang isang maling input OTP pagkatapos ng tatlong pagtatangka ay dapat na invalidated, at ang session ng gumagamit ay dapat na bawiin o tanggihan.
Ipatupad ang Something-You-Are authentication bilang isa sa mga MFA factors.
Ang Isang Bagay na Ikaw ay nangangailangan ng mga gumagamit na magpatunay gamit ang mga biometric identifier tulad ng mga fingerprint, retina scan, o pagkilala sa mukha.
Ang pagpapatupad ng Something-You-Are bilang isa sa mga kadahilanan ng MFA ay nagdaragdag ng isang lubos na personalised at mahirap na replicate na kadahilanan ng pagpapatunay. Nagbibigay ito ng isang mas matibay na paraan ng pag verify ng pagkakakilanlan ng gumagamit kaysa sa isang bagay na alam mo at ang isang bagay na mayroon ka, na binabawasan ang panganib ng hindi awtorisadong pag access.
Dapat limitahan ng mga developer ang mga pag andar ng apps sa mga aparato na kulang sa hardware Trusted Executed Environment (TEE) o biometrics (hal. Ang mga aparatong Android na kulang sa TEE ay maaaring makita gamit ang "isInsideSecureHardware" Android API.) at dapat na magpawalang bisa ng biometric authentication kung ang mga pagbabago ay nangyayari sa mekanismo ng biometric, tulad ng pag enroll ng isang bagong fingerprint sa aparato. Sinusuportahan ng IOS at Android platform ang pagtatakda ng isang app crypto key upang mag expire bilang tugon sa naturang mga pagbabago.
Gumamit ng mga salik na nakabatay sa konteksto upang magpatunay.
Ang mga kadahilanan na nakabatay sa konteksto ay nagpapakilala ng mga dynamic na elemento tulad ng lokasyon ng gumagamit at mga katangian ng aparato. Habang ang MFA ay nagbibigay ng isang matatag na layer ng seguridad sa pamamagitan ng paghiling ng maraming mga kadahilanan ng pagpapatunay, ang pagsasama ng mga kadahilanan na nakabatay sa konteksto ay lumilikha ng isang mas komprehensibo at adaptive na proseso ng pagpapatunay na maaaring mag alok ng karagdagang mga benepisyo sa pagtugon sa mga umuunlad na panganib ng hindi awtorisadong pag access.
Ang pagpapatupad ng mga kadahilanan na nakabatay sa konteksto ay nagpapaliit sa pag asa sa mga static na kredensyal, na ginagawang mas hamon para sa mga masasamang aktor na magtangkang hindi awtorisadong pag access. Dapat isaalang alang ng mga developer ang mga sumusunod na kontekstwal na kadahilanan upang mapatunayan ang pagkakakilanlan ng isang gumagamit:
Geolocation: Payagan ang pag access batay sa lokasyon ng isang aparato sa totoong mundo gamit ang geolocation ng GPS, Wi Fi, o IP address.
Uri ng Device: Payagan ang pag access batay sa mga katangian ng isang aparato. Halimbawa, ang laki ng screen ay maaaring matukoy kung ang isang aparato ay isang smartphone o tablet.
Ipatupad ang secure na pagpapatunay ng session.
Ang ligtas na pagpapatunay ng session ay nagsisiguro ng matibay na pamamahala ng session para sa parehong stateful at stateless authentication. Ang mga hindi maayos na pinamamahalaang sesyon, anuman ang app ay sumusunod sa mga stateful o stateless na pamamaraan ng pagpapatunay, ay maaaring humantong sa mga banta sa seguridad tulad ng hindi awtorisadong pag access, pag hijack ng session, o paglabag sa data.
Ang pagpapatupad ng secure na pagpapatunay ng session para sa mga stateful session ay gumagamit ng mga secure na identifier ng session, naka encrypt na komunikasyon at tamang mga timeout upang maiwasan ang hindi awtorisadong pag access. Para sa stateless authentication, tinitiyak nito na ang mga token ay tamper resistant, pinapanatili ang integridad ng pagpapatunay nang hindi umaasa sa imbakan sa gilid ng server.
Ipatupad ang secure na stateful authentication.
Ang secure na stateful authentication ay nagsasangkot ng pagprotekta at pagpapanatili ng mga persistent session. Habang ang stateful authentication ay nagbibigay ng isang walang pinagtahian na karanasan ng gumagamit sa pamamagitan ng mga persistent user session, maaari itong maging mahina sa iba't ibang mga banta sa seguridad, tulad ng mga masasamang aktor na nagtatangkang magnakaw ng mga identifier ng session.
Ang secure na stateful authentication ay pinoprotektahan ang mga account ng gumagamit mula sa hindi awtorisadong pag access at mga potensyal na kahinaan na nauugnay sa pamamahala ng session nang hindi nakompromiso ang balanse sa pagitan ng kakayahang magamit at seguridad.
Dapat matukoy ng mga developer ang mga endpoint sa gilid ng server na naglalantad ng sensitibong impormasyon o mga kritikal na pag andar at pinagtibay ang mga sumusunod na stateful session authentication best practices:
Itakwil ang mga kahilingan na may nawawala o hindi wastong mga ID ng session o token.
Bumuo ng mga ID ng Session nang random sa gilid ng server nang hindi nilalapat ang mga ito sa mga URL.
Pagbutihin ang seguridad ng Session ID na may tamang haba at entropy, na ginagawang mahirap ang hula.
Exchange Session ID lamang sa mga secure na koneksyon sa HTTPS.
Iwasan ang pag iimbak ng mga session ID sa persistent storage.
Patunayan ang mga ID ng session para sa pag access ng gumagamit sa mga pribilehiyong elemento ng app.
Tapusin ang mga sesyon sa gilid ng server, tinatanggal ang impormasyon ng session sa timeout o pag-logout.
Ipatupad ang ligtas na pagpapatunay ng stateless.
Ang secure na pagpapatunay ng stateless ay nagsasangkot ng mga secure na token na kasanayan para sa mabisa at scalable
authentication. Habang ang pagpapatunay ng stateless ay nagbibigay ng mga benepisyo, maaari itong maging mas mahina sa mga banta sa seguridad tulad ng pagpapanggap ng gumagamit kung ang mga token ay hindi ligtas na nabuo, ipinadala at naka imbak.
Tinitiyak ng pagpapatunay ng stateless na ang bawat token ay ligtas na hawakan habang nag aani ng kahusayan at mga benepisyo sa scalability, na binabawasan ang panganib ng hindi awtorisadong pag access. Ang mga developer ay dapat magpatibay ng mga sumusunod na stateless session authentication pinakamahusay na kasanayan:
Bumuo ng mga token sa gilid ng server nang hindi nilalapat ang mga ito sa mga URL.
Pagbutihin ang seguridad ng token na may tamang haba at entropy, na ginagawang mahirap ang hula.
Exchange token lamang sa mga secure na koneksyon HTTPS.
Patunayan na walang sensitibong data, tulad ng PII, ay naka embed sa mga token.
Iwasan ang pag iimbak ng mga token sa persistent storage.
Patunayan ang mga token para sa pag access ng gumagamit sa mga pribilehiyong elemento ng app.
Wakasan ang mga token sa gilid ng server, tinatanggal ang impormasyon ng token sa timeout o logout.
Cryptographically, mag sign ng mga token gamit ang isang secure na algorithm, pag iwas sa paggamit ng mga algorithm ng null.
Ipatupad ang ligtas na pagtatapos ng session sa panahon ng logout, kawalan ng aktibidad, o pagsasara ng app.
Ang secure na pagwawakas ng session ay epektibong nagsasara ng mga sesyon ng gumagamit. Ang mga masasamang aktor ay maaaring samantalahin ang mga nananatiling access point kung ang mga sesyon ay hindi naaangkop na pinamamahalaan sa mga senaryo tulad ng logout, kawalan ng aktibidad, o pagsasara ng app.
Ang pagpapatupad ng ligtas na pagtatapos ng session sa panahon ng pag logout, kawalan ng aktibidad, o pagsasara ng app ay maaaring makabuluhang mabawasan ang panganib ng hindi awtorisadong pag access sa pamamagitan ng awtomatikong pagwawakas ng mga sesyon ng gumagamit at pag iingat sa impormasyon ng gumagamit mula sa pag access ng mga hindi awtorisadong partido. Ang mga developer ay dapat:
Muling patunayan ang mga gumagamit pagkatapos mag log out, kawalan ng aktibidad ng app, katamaran, backgrounding, ganap na mga timeout ng session, o biglaang / puwersa ng pagsasara.
Ang server ay bumubuo ng mga bagong identifier ng session upang maiwasan ang fixation ng session tuwing ang mga gumagamit ay umabot sa isang bagong antas ng pagpapatunay.
Tiyakin session pagwawakas ay kinabibilangan ng pag clear o deauthorising ang lahat ng mga lokal na naka imbak token o session identifiers.
Tukuyin ang idle timeout value batay sa panganib at kalikasan ng pag andar.
Ipatupad ang proteksyon ng brute force para sa pagpapatunay.
Ang mga pag atake ng brute force ay nagsasangkot ng mga awtomatikong at sistematikong pagtatangka upang hulaan ang mga kredensyal ng gumagamit, tulad ng sa pamamagitan ng pagsubok ng iba't ibang mga kumbinasyon ng mga username at password upang makakuha ng hindi awtorisadong pag access.
Ang proteksyon ng brute force ay nagbabawal sa bilang ng mga pagtatangka sa pag login sa loob ng isang tinukoy na panahon. Ang pagpapatupad ng proteksyon ng brute force para sa pagpapatunay ay maaaring makabuluhang mapagaan ang panganib ng hindi awtorisadong pag access, protektahan ang mga account ng gumagamit at mapanatili ang integridad ng proseso ng pagpapatunay. Ang mga developer ay dapat magpatupad ng mga mekanismo ng brute force sa pamamagitan ng mga sumusunod na pinakamahusay na kasanayan:
Ipatupad ang mga tseke laban sa automation.
Ilapat ang rate ng paglilimita para sa mga pagtatangka sa pag login.
Isama ang mga progresibong incremental time delays (hal. 30 segundo, 1 minuto, 2 minuto, 5 minuto) para sa mga pagtatangka sa pag login.
Tandaan na ang lahat ng mga mekanismo ng MFA ay mahina sa brute force, at mahalaga upang maihatid ang mga dahilan para sa pag lock ng account at magbigay ng naa access na paraan para sa mga gumagamit upang mapatunayan ang kanilang sarili at alisin ang lockout. Halimbawa nito ay ang pagtawag sa isang
helpline o paggamit ng biometric verification.
Ipatupad ang isang mekanismo ng pag verify ng integridad ng transaksyon.
Habang tinitiyak ng pagpapatunay ang pagkakakilanlan ng gumagamit, hindi nito inaalis ang posibilidad ng mga mapanlinlang na aktibidad sa panahon ng proseso ng transaksyon. Ang mga mekanismo ng pagpapatunay ng integridad ng transaksyon ay mga pantulong na function ng seguridad na nagbibigay ng oras at mga tool sa mga gumagamit upang tumugon sa mga potensyal na pandaraya. Ang pagpapatupad ng isang mekanismo ng pag verify ng integridad ng transaksyon ay nagsisiguro na ang bawat transaksyon ay dumadaan sa masusing pagsisiyasat upang kumpirmahin ang katumpakan at pagiging tunay nito.
Maaaring ipatupad ng mga developer ang mga sumusunod na iminungkahing pinakamahusay na kasanayan:
Simulan ang isang transaksyon na pagpapatunay / kumpirmasyon na tawag.
Magbigay ng real time na kasaysayan ng transaksyon.
Ipatupad ang isang cooldown na panahon ng 12 oras hanggang 24 na oras.
Huwag paganahin ang mga transaksyon sa ibang bansa bilang default; paganahin lamang sa pamamagitan ng MFA.
Awtorisasyon
Tukuyin at i validate ang mga karapatan sa pag access ng gumagamit sa mga kaugnay na mapagkukunan sa loob ng app.
Ipatupad ang pahintulot sa server side.
Ang pahintulot sa gilid ng server ay tumutukoy sa pagpapatunay at pagbibigay ng mga pahintulot sa pag access sa mga gumagamit o app ng isang server o isang authorisation server. Tinitiyak nito na ang mga desisyon at pahintulot sa pagkontrol ng access ay pinamamahalaan at ipinatutupad na panig ng server sa halip na client side / sa pamamagitan ng aparato. Sa pamamagitan ng pagpapatupad ng pahintulot sa gilid ng server, binabawasan ng mga developer ang mga pagkakataon para sa mga nakakahamak na attacker na mag tamper o bypass ng mga hakbang sa seguridad sa app upang makakuha ng hindi awtorisadong pag access sa sensitibong data (hal., PIIs at data ng Authentication).
Dapat ipatupad ng mga developer ang pahintulot sa gilid ng server pagkatapos ng matagumpay na pagpapatunay bago magbigay ng mga pahintulot sa pag access at tiyakin na ang mga gumagamit ay binigyan ng access batay sa mga sumusunod:
Nakatalagang papel na may mga pahintulot: Tiyakin ang mga gumagamit ay maaari lamang magsagawa ng mga gawain na may kaugnayan sa kanilang mga responsibilidad.
Mga kadahilanan sa konteksto: Mga dynamic na sitwasyon ng pag access tulad ng Oras ng Pag access at Pagsusuri sa Makinarya.
Ipatupad ang awtorisasyon sa panig ng kliyente sa pamamagitan ng pagbubuklod ng aparato.
Ang client side (ie sa device) na awtorisasyon ay namamahala ng mga pahintulot sa pag access sa loob ng isang mobile app. Ito ay mapanganib dahil ang pag asa sa pahintulot sa panig ng kliyente ay maaaring ilantad ang mga app sa mga kahinaan tulad ng hindi awtorisadong pag access at potensyal na pandaraya.
Kung ang mga function ng negosyo ng isang app (hal., instantiating software token) ay nangangailangan ng mga pahintulot sa panig ng kliyente, ang pagbubuklod ng aparato (isang kasanayan sa seguridad na nag uugnay sa mga awtorisasyon upang ma access ang mga pribilehiyo sa isang partikular na aparato) ay inirerekomenda. Sa pamamagitan ng pagpapatupad ng pagbubuklod ng aparato, maaaring i verify ng mga app ang pagkakakilanlan ng aparato at magtatag ng tiwala. Binabawasan nito ang mga panganib na nauugnay sa hindi awtorisadong pag access at nagpapanatili ng isang ligtas, pinagkakatiwalaang landas sa pagitan ng mga aparato, app, at server. Ang mga developer ay dapat magtatag ng pagbubuklod sa pagitan ng mga app at ang aparato kapag ang pagkakakilanlan ng isang gumagamit ay ginagamit sa unang pagkakataon sa isang hindi rehistradong mobile device at dapat ding i verify na ang mga app:
Suriin kung may mga pagbabago sa aparato mula noong huling runtime.
Suriin ang mga pagbabago sa mga marker ng pagkakakilanlan ng aparato.
Suriin kung ang aparato na nagpapatakbo ng app ay ligtas (hal. walang jailbreaking o rooting).
Ang mga nabanggit ay ilan lamang sa mga halimbawa ng mga pamamaraan ng pinakamahusay na pagsasanay na ginagamit ng industriya. Habang umuunlad ang ecosystem ng mga mobile device, ang mga pamamaraang ito ay maaaring maging lipas na. Bilang tulad, ang mga developer ay dapat panatilihin ang abreast ng pinakabagong industriya pinakamahusay na kasanayan upang i verify ang mga bindings ng aparato.
Upang i verify ang isang Android device, ang mga developer ay maaaring:
Kumuha ng mga natatanging identifier tulad ng IMEI o Android ID.
Kunin ang build information.
Leverage katutubong OS API tampok, tulad ng SafetyNet ng Google.
Upang i verify ang isang iOS device, ang mga developer ay maaaring:
Leverage katutubong mga serbisyo ng OS, tulad ng ID ng aparato ng Apple, sa pamamagitan ng UIDevice.
Inaabisuhan ng app ang mga gumagamit ng lahat ng kinakailangang pahintulot bago nila ito gamitin.
Ang mga kinakailangang pahintulot ay mga tiyak na karapatan at kakayahan ang mga kahilingan ng app mula sa mobile device. Ang mga pahintulot na ito ay tumutukoy kung anong mga mapagkukunan o pag andar ang maaaring ma access ng app sa mga aparato ng mga gumagamit. Kabilang sa ilang halimbawa, ngunit hindi limitado sa, camera, mikropono, at lokasyon.
Sa pamamagitan ng pagpapatupad ng tamang mga abiso na nagpapaalam sa mga gumagamit ng kung ano ang mga pahintulot na hiniling, ang mga developer ay maaaring pigilan ang mga gumagamit mula sa hindi sinasadyang pagbibigay ng labis na mga pahintulot, na maaaring payagan ang mga masasamang aktor na mapagsamantalahan ang mga kahinaan at magnakaw ng sensitibong data (hal., PIIs at Authentication Data). Ang ganitong mga abiso ay magpapahintulot din sa mga gumagamit na gumawa ng mga desisyong may kaalaman tungkol sa mga app na kanilang na install.
Ang mga developer ay dapat:
Gumamit ng mga alerto sa in app upang humiling ng pahintulot mula sa mga gumagamit na ma access.
Tiyakin na ang Mga Abiso / Alerto ay hindi nagpapakita ng sensitibong data.
Humiling lamang ng mahahalagang pahintulot para sa pag andar ng app.
Inaabisuhan ng app ang mga gumagamit ng lahat ng mga transaksyon na may mataas na panganib na pinahintulutan at nakumpleto.
Kung ang isang app ay may mga pag andar ng transaksyon na may mataas na panganib, ang mga gumagamit ay dapat na ipaalam kaagad kapag ang isang transaksyon ay pinahintulutan at nakumpleto. Sa pamamagitan ng pagpapatupad ng kontrol na ito, maaaring matiyak ng mga developer na ang mga gumagamit ay agad na nalalaman kapag ang mga transaksyon sa mataas na panganib ay pinahintulutan at nakumpleto upang maaari nilang makilala ang mga potensyal na mapanlinlang na transaksyon sa lalong madaling panahon.
Dapat magpatibay ang mga developer ng mga sumusunod na pamamaraan upang alertuhan ang isang gumagamit:
Mga alerto sa In-Application (In-App).
Mga abiso sa email.
Mga abiso sa Short Message Service (SMS).
Dapat ding tiyakin ng mga developer na ang Mga Abiso / Alerto ay hindi nagpapakita ng sensitibong data at humiling lamang ng mahahalagang pahintulot para sa pag andar ng app.
Ang nasa itaas ay ilan lamang sa mga halimbawa ng mga pamamaraan ng abiso sa pinakamahusay na kasanayan na ginagamit ng industriya. Habang umuunlad ang ecosystem ng mga mobile device, ang mga pamamaraang ito ay maaaring maging lipas na. Bilang gayon, ang mga developer ay dapat panatilihin ang mga pinakabagong pinakamahusay na kasanayan sa industriya upang ipaalam sa mga gumagamit ng mga awtorisadong at nakumpleto na mga transaksyon sa mataas na panganib.
Pag iimbak ng data
Pangalagaan ang integridad at pagiging kompidensyal ng sensitibong data sa aparato ng gumagamit at sa server ng app.
Ang app ay nag iimbak ng sensitibong data na kinakailangan lamang para sa mga transaksyon.
Ang sensitibong data ay tinukoy bilang data ng gumagamit (PIIs) at data ng pagpapatunay (hal., mga kredensyal, mga key ng pag encrypt). Ang mga developer ay dapat lamang mag imbak ng sensitibong data na kinakailangan para sa mga function ng negosyo ng app. Ang pag iipon ng hindi kinakailangang impormasyon ay nagdaragdag ng epekto ng mga potensyal na paglabag sa seguridad, na ginagawang isang kaakit akit na target ang isang app para sa mga nakakahamak na aktor.
Sa pamamagitan ng pagpapatupad ng kontrol sa seguridad na ito, maaaring matiyak ng mga developer na ang pagkakalantad ay limitado sa data na kinakailangan para sa mga tiyak na pag andar ng negosyo, na binabawasan ang epekto ng hindi awtorisadong pag access o paglabag sa data.
Dapat uriin ng mga developer ang data na ginagamit ng app batay sa mga antas ng sensitivity ng isang organisasyon at batay sa mga kinakailangan sa batas ng batas at magpatibay ng mga sumusunod na patnubay upang ma secure ang data na inuri bilang sensitibo:
Ipatupad ang isang ligtas na solusyon sa imbakan batay sa pagiging sensitibo nito sa panig ng client / server side.
Mag apply ng mga panukala sa proteksyon ng data (hal. tokenising, hashing na may asin, pag encrypt)
Tanggalin ang sensitibong data kapag hindi na kinakailangan.
Ang app ay nagpapatupad ng ligtas na imbakan ng sensitibong data.
Ang secure na imbakan para sa mga mobile app ay tumutukoy sa pagpapatupad ng mga pamamaraan at kasanayan upang maprotektahan ang sensitibong data na naka imbak sa mga mobile device at mga server ng app mula sa hindi awtorisadong pag access, pagnanakaw o pagmamargal. Ito ay nagsasangkot ng mga pinakamahusay na kasanayan tulad ng pag encrypt, hashing, tokenisation, at tamang mga kontrol sa pag access. Sa pamamagitan ng pagpapatupad ng ligtas na imbakan, ang mga developer ay maaaring gumaan laban sa hindi awtorisadong pag access, kompromiso ng aparato, mga potensyal na paglabag sa data at pagtagas.
Ang mga developer ay dapat magpatupad ng isang ligtas na solusyon sa imbakan na commensurate sa sensitivity ng data at dapat ding unahin ang sumusunod na order para sa isang ligtas na solusyon sa imbakan (mula sa pinaka sensitibong data hanggang sa hindi bababa sa sensitibong data):
Server-side (lahat ng sensitibong data ay dapat na naka-imbak server-side).
Client side sa loob ng Trusted Execution Environment (kung saan imposible ang server-side, itago ang lahat ng sensitibong data sa TEE sa client).
Ang app ay nag iimbak ng sensitibong data nang ligtas sa gilid ng server.
Ang pag iimbak ng sensitibong data server side ay tumutukoy sa pag iimbak ng data sa mga remote server ng app o database. Ang diskarte na ito ay lumilikha ng isang mas mahusay na kapaligiran upang maprotektahan ang data mula sa hindi awtorisadong pag access o paglabag, pagpapagana ng mas ligtas na kontrol sa pag access, mga pagpipilian upang ipatupad ang mas mahusay na mga hakbang sa seguridad tulad ng mas kumplikadong pag encrypt, at mga probisyon para sa mas mabilis na mga update sa seguridad.
Sa pamamagitan ng pagpapatupad ng server side storage ng sensitibong data, ang mga developer ay maaaring gumaan laban sa mga likas na panganib ng imbakan ng data sa panig ng kliyente, dahil ang imbakan ng client side ay likas na mas madaling kapitan ng mga pamamaraan ng pagsasamantala sa imbakan ng data na karaniwang ginagamit ng mga nakakahamak na aktor sa mga mobile scam.
Ang mga developer ay dapat mag aplay ng hindi bababa sa 1 ng mga sumusunod na hakbang sa proteksyon ng data:
Para sa mga password lamang, ang mga developer ay maaaring gumamit ng hashing na may asin (hashing na may asin ay ginagamit upang magdagdag ng isang dagdag na layer ng seguridad sa pamamagitan ng paggawa ng computationally intensive para sa mga attackers
Upang ma decipher ang orihinal na sensitibong data. Sa konteksto ng imbakan ng password o key derivation, dapat gamitin ng mga developer ang mga one way key derivation function o mabagal na hash algorithm, tulad ng PBKDF2, bcrypt, o script.). Sa halip na mag imbak ng aktwal na mga password, ang mga natatanging asin ay nabuo at pinagsama sa mga password, na lumilikha ng maalat na hashes.
Maaaring i-encrypt ng mga developer ang sensitibong data gamit ang mga pamantayan sa pag-encrypt tulad ng AES-128.
Ang mga developer ay maaaring magpatupad ng tokenisation sa self managed tokenisation o isang tokenisation service, na pinapalitan ang sensitibong data sa mga token kung saan maaari. Bilang karagdagan, dapat tiyakin ng mga developer na ang tokenisation ay may sapat na haba at pagiging kumplikado (na suportado ng secure na cryptography) batay sa sensitivity ng data at mga pangangailangan sa negosyo.
Ang nasa itaas ay ilan lamang sa mga halimbawa ng mga pinakamahusay na kasanayan sa industriya. Habang umuunlad ang ecosystem ng mga mobile device, ang mga pinakamahusay na kasanayan na ito ay maaaring maging lipas na. Tulad nito, ang mga developer ay dapat na abreast ng pinakabagong industriya pinakamahusay na kasanayan upang mag imbak ng sensitibong data nang ligtas sa server.
Ang app ay nag iimbak ng sensitibong data nang ligtas sa panig ng kliyente sa isang Trusted Execution Environment (TEE).
Ang Trusted Execution Environment (TEE) ay isang nakahiwalay na lugar sa loob ng hardware o arkitektura ng processor ng isang mobile device na nagbibigay ng isang mataas na ligtas na kapaligiran para sa pag iimbak ng sensitibong data at pagpapatupad ng sensitibo o kritikal na operasyon. Pinoprotektahan nito ang sensitibong data, cryptographic key, at mga kritikal na proseso mula sa hindi awtorisadong pag access o pag tamper. Kung ang mga function ng negosyo ng isang app ay nangangailangan ng sensitibong imbakan sa gilid ng kliyente, dapat itong maiimbak sa Tee ng aparato.
Ang mga developer ay maaaring pabatain ang mga banta mula sa loob ng isang nakompromisong aparato at panlabas na masasamang aktor sa pamamagitan ng tamang pag iimbak ng sensitibong data sa TEE sa tabi ng kliyente. Ang naturang imbakan ay maaari ring mabawasan ang hindi awtorisadong pag access sa sensitibong data ng isang gumagamit sa isang app at maiwasan ang anumang mga key ng pag encrypt mula sa ninakaw.
Ang mga developer ay dapat mag imbak ng sensitibong data nang ligtas na client side sa isang Trusted Execution Environment (TEE) tulad ng Android's ARM's TrustZone at Secure Enclave ng Apple. Ang mga developer ay dapat ding mag imbak ng minimally ang sumusunod na listahan ng sensitibong data sa isang TEE:
Mga identifier ng biometric.
Mga token ng pagpapatunay.
Cryptographic key sa isang secure na key management system tulad ng Android Keystore o iOS Keychain.
Ang mga halimbawa sa itaas ay sensitibong data developer ay dapat na mag imbak sa TEE. Habang umuunlad ang ecosystem ng mobile device, dapat na maiimbak ng mga developer ang anumang kinakailangang data sa TEE.
Maaaring isaalang alang ng mga developer ang paggamit ng virtualised TEEs para sa mga aparato na walang mga TEE ng hardware. Bilang kahalili, maaaring patayin ng mga developer ang app o ang mga function ng transaksyon nito na may mataas na panganib, dahil ang app ay itinuturing na hindi sigurado para sa mga transaksyon na may mataas na panganib.
Tinatanggal ng app ang sensitibong data kapag hindi na kinakailangan.
Ang pagtanggal ng sensitibong data ay nangangahulugan ng permanenteng pag alis o pagbura ng kumpidensyal, pribado, o sensitibong data mula sa mga aparatong imbakan, server, o database. Tinitiyak ng prosesong ito na ang sensitibong data ay hindi mababawi na tinanggal at hindi maaaring ma access, makuha, aksidenteng nakalantad, o muling itinayo ng mga hindi awtorisadong indibidwal o sa pamamagitan ng mga pamamaraan ng pagbawi ng data.
Sa pamamagitan ng pagpapatupad ng prosesong ito, ang mga developer ay maaaring maliitin ang window kung saan ang mga attacker ay maaaring samantalahin ang mga kahinaan upang magnakaw ng sensitibong data. Dapat gamitin ng mga developer ang mga sumusunod na persistent storage security technique:
I-clear ang mga naka-imbak na cookies sa pagwawakas ng app o gumamit ng in-memory cookie storage.
Alisin ang lahat ng sensitibong data sa pag uninstall ng app.
Kapag tumigil ang mga kaugnay na function ng negosyo, manu manong alisin ang lahat ng mga file ng database na naglalaman ng sensitibong data (hal., iOS WebView cache) mula sa file system.
Ang nasa itaas ay ilan lamang sa mga halimbawa ng mga pinakamahusay na kasanayan sa industriya. Habang umuunlad ang ecosystem ng mga mobile device, ang mga pamamaraang ito ay maaaring maging lipas na. Bilang tulad, ang mga developer ay dapat na abreast ng pinakabagong industriya pinakamahusay na kasanayan para sa pagtanggal ng sensitibong data kapag hindi na kinakailangan.
Panlaban at pambabaliktad
Ipatupad ang mga hakbang upang maiwasan ang app na ma tamper o makompromiso. Kabilang sa mga halimbawa ang mga kakayahan laban sa virus at proteksyon laban sa pagsubaybay at pag espiya ng keyboard.
Ang app ay code na nilagdaan ng mga sertipiko mula sa mga opisyal na tindahan ng app.
Ang mga app ay madalas na spoofed ng mga masasamang aktor at ipinamamahagi sa pamamagitan ng hindi gaanong mahigpit na mga channel na regulated. Ang pag sign ng isang app gamit ang mga sertipiko na ibinigay ng mga opisyal na tindahan ng app ay tinitiyak ang mobile OS at mga gumagamit na na verify ang mobile app.
Ang pagpapatupad ng code signing ay tumutulong sa mga operating system na matukoy kung papayagan ang software na tumakbo o mag install batay sa mga lagda o sertipiko na ginamit upang lagdaan ang code. Ito ay tumutulong sa maiwasan ang pag install at pagpapatupad ng mga potensyal na mapanganib na apps. Bilang karagdagan, ang pag sign ng code ay tumutulong din sa pag verify ng integridad, dahil ang mga lagda ay magbabago kung ang app ay natamper.
Dapat mag code sign ang mga developer ng kanilang mga app na may mga sertipiko. Ang bahaging ito ay nagbibigay ng mga halimbawa kung paano gawin ito sa pamamagitan ng dalawang pinakasikat na platform, iOS at Android. Maaari itong gawin para sa App Store ng Apple sa pamamagitan ng pag enroll sa Apple Developer Programme at paglikha ng isang
kahilingan sa pag sign ng sertipiko sa portal ng developer. Ang mga developer ay maaaring magrehistro para sa Apple Developer Programme at maaaring sumangguni sa sumusunod na gabay ng developer para sa pag sign ng code sa ilalim ng mga bagay na dapat tandaan. Para sa Android, mayroong iba't ibang mga tindahan ng App. Para sa Play Store ng Google, maaari itong gawin sa pamamagitan ng pag configure ng Play App Signing, na isang kinakailangan para sa pamamahagi sa pamamagitan ng Play Store ng Google.
Ang app ay nagpapatupad ng jailbreak o root detection.
Ang mga rooted at jailbroken device ay karaniwang itinuturing na hindi ligtas. Pinapayagan nila ang mga gumagamit na makakuha ng mga nakataas na pribilehiyo, na nagpapagana ng mas madaling pag iwas sa seguridad at mga limitasyon ng OS. Ang ganitong mga nakataas na pribilehiyo ay maaaring maging hindi ligtas para sa mga app dahil pinapayagan nila ang mga nakakahamak na aktor na potensyal na mapagsamantalahan ang mga kahinaan, magnakaw ng mga kredensyal, kumuha ng mga aparato ng gumagamit, at magsagawa ng mga mapanlinlang na transaksyon sa app.
Sa pamamagitan ng pagpapatupad ng jailbreak o root detection, maaaring pigilan ng mga developer ang mga nabanggit na pagsasamantala mula sa nangyayari, protektahan ang intelektwal na ari arian ng apps, matiyak ang katatagan ng app, at maiwasan ang bypass ng mga in app system.
Android jailbreak o pagtuklas ng ugat:
Check mo kung may superuser or SU binary.
Tuklasin ang mga pagbabago sa root file system.
Maghanap ng mga rooted na apps.
Suriin para sa pasadyang pagbawi.
Suriin para sa hindi ligtas na paggamit ng API.
iOS jailbreak o pagtuklas ng ugat:
Tuklasin ang paggamit ng mga pinaghihigpitang API.
Hanapin ang mga jailbreak tweak tulad ng mga mod.
Maghanap ng mga hindi opisyal na tindahan ng app, hal., suriin kung may lagda ng Cydia App Store.
Hanapin ang mga pagbabago sa kernel.
Suriin para sa integridad ng mga kritikal na file system.
Gumamit ng mga aklatan ng 3rd party na idinisenyo para makita ang pag-tamper ng device.
Ang mga nabanggit ay ilan lamang sa mga halimbawa ng mga tseke na pinakamahusay na kasanayan na ginagamit ng industriya. Habang umuunlad ang ecosystem ng mga mobile device, ang mga tseke na ito ay maaaring maging lipas na. Bilang tulad, ang mga developer ay dapat na abreast ng pinakabagong industriya pinakamahusay na kasanayan upang ipatupad ang jailbreak o ugat detection.
Ang app ay nagpapatupad ng pagtuklas ng emulator.
Ang mga emulator ay software na ginagamit upang subukan ang mga mobile app. Pinapayagan nila ang mga gumagamit na subukan ang isang mobile app sa iba't ibang mga ginagaya na mga mobile na bersyon at aparato. Kahit na kapaki pakinabang para sa pagsubok, ang mga app ay hindi dapat naka mount sa mga emulator sa labas ng kapaligiran ng pag unlad.
Sa pamamagitan ng pagpapatupad ng pagtuklas ng pagtulad, ang mga developer ay maaaring maiwasan ang mga nakakahamak na aktor mula sa pagpapatakbo ng dynamic na pagsusuri, rooting, pag debug, instrumentation, hooking, at pagsubok ng fuzz sa isang emulated device na maaari nilang kontrolin. Sa paggawa nito, maaaring maiwasan ng mga developer ang mga nakakahamak na aktor mula sa pagtuklas ng mga kahinaan sa loob ng app para sa pagsasamantala.
Dapat ipatupad ng mga developer ang sumusunod na diskarte sa pagtuklas upang matukoy ang mga tampok para sa karaniwang ginagamit na mga solusyon sa pagtulad. Ang ilang mga rekomendasyon ng mga bagay na dapat suriin ay:
Suriin ang paggamit ng baterya.
Suriin ang mga timestamp at orasan.
Suriin ang mga pag-uugali ng maraming tao.
Suriin ang pagtatasa ng memorya at pagganap.
Magsagawa ng mga pagsusuri sa network.
Suriin kung ito ay batay sa hardware.
Check mo kung ano ang base ng OS.
Suriin kung may mga fingerprint ng device.
Suriin ang mga configuration ng build.
Suriin ang mga serbisyo at app ng emulator.
Ang mga nabanggit ay ilan lamang sa mga halimbawa ng mga tseke na pinakamahusay na kasanayan na ginagamit ng industriya. Habang umuunlad ang ecosystem ng mga mobile device, ang mga tseke na ito ay maaaring maging lipas na. Tulad nito, ang mga developer ay dapat na abreast ng pinakabagong industriya pinakamahusay na kasanayan para sa pagpapatupad ng pagtuklas ng emulator.
Ang app ay nagpapatupad ng pagtuklas ng anti malware.
Ang mga nakakahamak na aktor ay lalong gumagamit ng mga app ng Malware bilang isang vector upang ikompromiso ang mga mobile device ng mga gumagamit. Ang mga app na ito ay nagbibigay sa mga gumagamit ng kaginhawaan na kinakailangan upang maisagawa ang pang araw araw na mga transaksyon. Ang mga malware app ay pangunahing gumagamit ng mga tampok ng sideloading upang makuha ang mga gumagamit na mag install ng malware sa kanilang mga aparato.
Sa pamamagitan ng pagpapatupad ng mga kakayahan sa pagtuklas ng anti malware sa isang app sa runtime, maaaring pigilan ng mga developer ang mga gumagamit mula sa pagsasamantala sa pamamagitan ng malware pagsasamantala sa mga kahinaan ng app at kahinaan ng OS, pagnanakaw ng mga kredensyal, pagkuha ng aparato, at pagpapatupad ng mga mapanlinlang na transaksyon. Dapat ipatupad ng mga developer ang mga kakayahan sa pagtuklas ng anti malware sa kanilang mga app. Ito ay maaaring gawin sa iba't ibang paraan, ngunit hindi limitado sa:
Isama ang Runtime-Application-Self-Protection (RASP) Software Development Kit (SDK) sa kanilang mga app.
Gamitin ang mga RASP SDK para suriin at tuklasin ang mga malware app sa runtime.
Suriin para sa at maiwasan ang mga overlay.
Pigilan ang clickjacking.
Pigilan ang pag hook ng memorya ng app.
Ang mga nabanggit ay ilan lamang sa mga halimbawa ng mga tseke na pinakamahusay na kasanayan na ginagamit ng industriya. Habang umuunlad ang ecosystem ng mga mobile device, ang mga tseke na ito ay maaaring maging lipas na. Bilang gayon, ang mga developer ay dapat na maging aup ng pinakabagong industriya pinakamahusay na kasanayan upang ipatupad ang pagtuklas ng anti malware.
Kung may nakitang malisya, dapat patayin ng mga developer ang app, bigyan ang user ng kinakailangang impormasyon kung bakit ito pinatay, at hikayatin ang user na i uninstall ang (mga) malisyosong app sa kanilang device. Bilang kahalili, dapat babalaan ng mga developer ang gumagamit at patayin ang mga function na may mataas na panganib sa app hanggang sa i remediates ng gumagamit ang nakakahamak na (mga) app.
Ang app ay nagpapatupad ng mga mekanismo ng anti hooking.
Ang hooking ay tumutukoy sa isang pamamaraan na ginagamit ng mga attacker upang mahagip o baguhin ang pag uugali ng isang mobile app sa runtime. Ito ay nagsasangkot ng pagpasok o pag hook sa daloy ng pagpapatupad ng isang app upang alinman sa subaybayan ang mga aktibidad nito, baguhin ang pag uugali nito, mag iniksyon ng malisyosong code o baguhin ang umiiral na mga function ng code upang mapagsamantalahan ang mga kahinaan.
Sa pamamagitan ng pagpapatupad ng mga mekanismo ng anti hooking sa mga app, maaaring pigilan ng mga developer ang mga pag atake sa itaas mula sa nangyayari at maiwasan ang hindi awtorisadong pag access, protektahan ang mga operasyon ng transaksyon na may mataas na panganib, matukoy at maiwasan ang mga pagtatangka sa pag tampering at pagbabago, mapanatili ang intelektwal na ari arian at mapanatili ang pagiging maaasahan ng app. Dapat ipatupad ng mga developer ang mga sumusunod na mekanismo ng halimbawa upang mapagaan laban sa mga pag atake ng hooking:
Ipatupad ang mga proteksyon upang harangan ang mga iniksyon ng code.
Ipatupad ang mga proteksyon upang maiwasan ang paraan ng pag hook sa pamamagitan ng pagpigil sa mga pagbabago sa source code ng app (parehong sa client at server).
Ipatupad ang mga proteksyon upang maiwasan ang pagpapatupad ng mga binagong code sa iyong app.
Ipatupad ang mga proteksyon upang maiwasan ang pag access sa memorya at pagmamanipula ng memorya ng iyong app.
Ipatupad ang mga algorithm na lumalaban sa tamper o mga SDK na anti tampering (karaniwang kilala bilang Runtime-Application-Self Protection SDKs).
Suriin para sa mga hindi ligtas na parameter tulad ng mga lipas na API at mga parameter.
Ang mga nabanggit ay ilan lamang sa mga halimbawa ng mga tseke na pinakamahusay na kasanayan na ginagamit ng industriya. Habang umuunlad ang ecosystem ng mga mobile device, ang mga tseke na ito ay maaaring maging lipas na. Bilang gayon, ang mga developer ay dapat na abreast ng pinakabagong industriya pinakamahusay na kasanayan upang ipatupad ang mga mekanismo ng anti hooking.
Ang app ay nagpapatupad ng overlay, remote viewing, at mga counter ng screenshot.
Ang sensitibong impormasyon ay maaaring makuha o maitala nang walang malinaw na pahintulot ng gumagamit kapag ang isang app ay may mga pag andar ng screen recording, screenshot o overlay. Halimbawa:
Ang mga pag atake ng overlay ay nanlilinlang sa mga gumagamit sa pamamagitan ng paglikha ng isang pekeng layer na ginagaya ang mga pinagkakatiwalaang app, na naglalayong magnakaw ng sensitibong data.
Ang mga pag atake ng remote viewing ay nagsasangkot ng hindi awtorisadong pag access sa screen ng isang aparato, na nagpapahintulot sa mga umaatake na mag ani ng sensitibong data nang malayo.
Ang mga pag atake ng screenshot ay nangyayari kapag ang mga nakakahamak na aktor ay nakuha ang screen ng isang aparato nang walang pahintulot ng gumagamit at kunin ang sensitibong data.
Ang pagpapatupad ng overlay, remote viewing, at mga countermeasures sa screenshot ay maaaring matiyak na ang sensitibong impormasyon ay nananatiling ligtas, ang privacy ng gumagamit ay itinataguyod, at ang sensitibong data ay protektado laban sa hindi sinasadyang pagkawala o maling paggamit.
Dapat ipatupad ng mga developer ang mga pagsusuri laban sa tampering at anti malware sa pamamagitan ng RASP SDKs upang maiwasan ang mga nakakahamak na app mula sa paggamit ng mga overlay at mga pagsasamantala sa malayong panonood.
Para sa mga screenshot, maaaring magamit ng mga developer ang FLAG_SECURE bandila para sa mga Android app at katulad na mga bandila para sa iOS upang harangan ang lahat ng mga kakayahan sa screenshot kapag gumagamit ng app. Gayunpaman, ipagpalagay na ang mga function ng negosyo ay nangangailangan ng mga kakayahan sa screenshot (hal. pagkuha ng screenshot ng isang nakumpletong transaksyon sa bangko). Sa kasong iyon, ang rekomendasyon ay upang patayin ang mga kakayahan sa screenshot para sa mga screen o pahina na kasama ang sensitibong data (PII at Data ng Pagpapatunay). Maaari ring isaalang alang ng mga developer ang masking input na may sensitibong data at sensor screen kapag ang app ay backgrounded.
Ang ilang mga halimbawa kung saan hindi paganahin ang mga kakayahan sa screenshot na ito ay kasama ngunit hindi limitado sa, Mga pahina ng Pag login, Mga pahina ng Multi-Factor Authentication, Security Credentials, at mga pahina na nagbabago sa PII.
Ang app ay nagpapatupad ng pagkuha ng anti keystroke o anti keylogger laban sa mga virtual keyboard ng third party sa mga Android device.
Ang pagkuha ng keystroke at keylogging ay mga pamamaraan na ginagamit ng mga masasamang aktor upang subaybayan, mag log, at i record ang mga key na pinindot sa isang keyboard nang walang kaalaman at pahintulot ng gumagamit. Pinapayagan nito ang pag log at pagkuha ng potensyal na sensitibong data (hal., PII at Authentication Data).
Sa pamamagitan ng pagpapatupad ng isang in app keyboard, maaaring kontrolin ng mga developer kung saan pupunta ang data ng pag log at pabatain laban sa panganib ng mga insecure na mga virtual keyboard ng third party na kumikilos bilang mga keyloggers upang makuha ang mga keystroke.
Kasama ang paggamit ng mga in app keyboard, dapat ipatupad ng mga developer ang mga sumusunod na mungkahi para sa mga input na nangangailangan ng sensitibong data (hal., PII at Authentication Data): Huwag paganahin ang autocorrect, autofill, autosuggestion, cut, kopyahin, at i paste para sa mga function o apps na naglalaman ng sensitibong data. Ang ilang mga gawain na dapat gamitin ang mga in app na keyboard ay kinabibilangan ng pag log in, pagpasok ng isang OTP, o iba pang mga kadahilanan ng pag verify.
