foreword by bernhard mueller, owasp ......owasp mobile application security verification standard...
Post on 09-Jun-2020
2 Views
Preview:
TRANSCRIPT
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 3
FOREWORDBYBERNHARDMUELLER,OWASPMOBILEPROJECT 5
FRONTISPIECE 7ABOUTTHESTANDARD 7COPYRIGHTANDLICENSE 7ACKNOWLEDGEMENTS 7
THEMOBILEAPPLICATIONSECURITYVERIFICATIONSTANDARD 8
MOBILEAPPSECMODEL 8
ASSESSMENTANDCERTIFICATION 12
OWASP'SSTANCEONCERTIFICATIONSANDTRUSTMARKS 12GUIDANCEFORCERTIFYINGMOBILEAPPS 12OTHERUSES 13
V1:ARCHITECTURE,DESIGNANDTHREATMODELLINGREQUIREMENTS 15
CONTROLOBJECTIVE 15SECURITYVERIFICATIONREQUIREMENTS 15REFERENCES 16
V2:DATASTORAGEANDPRIVACYREQUIREMENTS 17
CONTROLOBJECTIVE 17SECURITYVERIFICATIONREQUIREMENTS 17VERIFICATIONPROCESSES 18REFERENCES 18
V3:CRYPTOGRAPHYREQUIREMENTS 19
CONTROLOBJECTIVE 19SECURITYVERIFICATIONREQUIREMENTS 19VERIFICATIONPROCESSES 19REFERENCES 19
V4:AUTHENTICATIONANDSESSIONMANAGEMENTREQUIREMENTS 20
CONTROLOBJECTIVE 20SECURITYVERIFICATIONREQUIREMENTS 20VERIFICATIONPROCESSES 20REFERENCES 21
V5:NETWORKCOMMUNICATIONREQUIREMENTS 22
CONTROLOBJECTIVE 22SECURITYVERIFICATIONREQUIREMENTS 22VERIFICATIONPROCESSES 22REFERENCES 22
V6:ENVIRONMENTALINTERACTIONREQUIREMENTS 23
CONTROLOBJECTIVE 23
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 4
SECURITYVERIFICATIONREQUIREMENTS 23VERIFICATIONPROCESSES 23REFERENCES 23
V7:CODEQUALITYANDBUILDSETTINGREQUIREMENTS 24
CONTROLOBJECTIVE 24SECURITYVERIFICATIONREQUIREMENTS 24VERIFICATIONPROCESSES 24REFERENCES 24
V8:RESILIENCYAGAINSTREVERSEENGINEERINGREQUIREMENTS 25
CONTROLOBJECTIVE 25VERIFICATIONPROCESSES 27REFERENCES 27
APPENDIXA:GLOSSARY 28
APPENDIXB:REFERENCES 31
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 5
ForewordbyBernhardMueller,OWASPMobileProject
Technological revolutions can happen quickly.Less than a decade ago, smartphones wereclunkydeviceswithlittlekeyboards-expensiveplaythingsfortech-savvybusinessusers.Today,smartphonesareanessentialpartofourlives.We've come to rely on them for information,navigation and communication, and they areubiquitous both in business and in our sociallives.
Everynewtechnology introducesnewsecurityrisks,andkeepingupwiththosechangesisoneof the main challenges the security industryfaces.Thedefensivesideisalwaysafewstepsbehind.Forexample,thedefaultreflexformanywas to apply old ways of doing things:Smartphones are like small computers, andmobileappsarejustlikeclassicsoftware,sosurelythesecurityrequirementsaresimilar?Butitdoesn'tworklikethat.SmartphoneoperatingsystemsaredifferentfromDesktopoperatingsystems,andmobileappsaredifferentfromwebapps.Forexample,theclassicalmethodofsignature-basedvirusscanningdoesn'tmakesenseinmodernmobileOSenvironments:Notonlyisitincompatiblewiththemobileappdistributionmodel,it'salsotechnicallyimpossibleduetosandboxingrestrictions.Also,somevulnerabilityclasses,suchasbufferoverflowsandXSSissues,arelessrelevantinthecontextofrun-of-the-millmobileappsthanin,say,Desktopappsandwebapplications(exceptionsapply).
Overtime,ourindustryhasgottenabettergriponthemobilethreatlandscape.Asitturnsout,mobilesecurityisallaboutdataprotection:Appsstoreourpersonalinformation,pictures,recordings,notes,accountdata,businessinformation,locationandmuchmore.Theyactasclientsthatconnectustoservicesweuseonadailybasis,andascommunicationshubsthatprocesseseachandeverymessageweexchangewithothers.Compromiseaperson'ssmartphoneandyougetunfilteredaccesstothatperson'slife.Whenweconsiderthatmobiledevicesaremorereadilylostorstolenandmobilemalwareisontherise,theneedfordataprotectionbecomesevenmoreapparent.
Asecuritystandardformobileappsmustthereforefocusonhowmobileappshandle,storeandprotectsensitiveinformation.EventhoughmodernmobileoperatingsystemslikeiOSandAndroidoffergoodAPIsforsecuredatastorageandcommunication,thosehavetobeimplementedandusedcorrectlyinordertobeeffective.Datastorage,inter-appcommunication,properusageofcryptographicAPIsandsecurenetworkcommunicationareonlysomeoftheaspectsthatrequirecarefulconsideration.
Animportantquestioninneedofindustryconsensusishowfarexactlyoneshouldgoinprotectingtheconfidentialityandintegrityofdata.Forexample,mostofuswouldagreethatamobileappshouldverifytheservercertificateinaTLSexchange.ButwhataboutSSLcertificatepinning?Doesnotdoingitresultinavulnerability?Shouldthisbearequirement
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 6
ifanapphandlessensitivedata,orisitmaybeevencounter-productive?DoweneedtoencryptdatastoredinSQLitedatabases,eventhoughtheOSsandboxestheapp?Whatisappropriateforoneappmightbeunrealisticforanother.TheMASVSisanattempttostandardizetheserequirementsusingverificationlevelsthatfitdifferentthreatscenarios.
Furthermore,theappearanceofrootmalwareandremoteadministrationtoolshascreatedawarenessofthefactthatmobileoperatingsystemsthemselveshaveexploitableflaws,socontainerizationstrategiesareincreasinglyusedtoaffordadditionalprotectiontosensitivedataandpreventclient-sidetampering.Thisiswherethingsgetcomplicated.Hardware-backedsecurityfeaturesandOS-levelcontainerizationsolutions,suchasAndroidforWorkandSamsungKnox,doexist,buttheyaren'tconsistentlyavailableacrossdifferentdevices.Asabandaid,itispossibleimplementsoftware-basedprotectionmeasures-butunfortunately,therearenostandardsortestingprocessesforverifyingthesekindsofprotections.
Asaresult,mobileappsecuritytestingreportsareallovertheplace:Forexample,sometestersreportalackofobfuscationorrootdetectioninanAndroidappas“securityflaw”.Ontheotherhand,measureslikestringencryption,debuggerdetectionorcontrolflowobfuscationaren'tconsideredmandatory.However,thisbinarywayoflookingatthingsdoesn'tmakesensebecauseresiliencyisnotabinaryproposition:Itdependsontheparticularclient-sidethreatsoneaimstodefendagainst.Softwareprotectionsarenotuseless,buttheycanultimatelybebypassed,sotheymustneverbeusedasareplacementforsecuritycontrols.
TheoverallgoaloftheMASVSistoofferabaselineformobileapplicationsecurity(MASVS-L1),whilealsoallowingfortheinclusionofdefense-in-depthmeasures(MASVS-L2)andprotectionsagainstclient-sidethreats(MASVS-R).TheMASVSismeanttoachievethefollowing:
• Providerequirementsforsoftwarearchitectsanddevelopersseekingtodevelopsecuremobileapplications;
• Offeranindustrystandardthatcanbetestedagainstinmobileappsecurityreviews;• Providespecificrecommendationsastowhatlevelofsecurityisrecommendedfor
differentuse-cases.
Weareawarethat100%industryconsensusisimpossibletoachieve.Nevertheless,wehopethattheMASVSisusefulinprovidingguidancethroughoutallphasesofmobileappdevelopmentandtesting.Asanopensourcestandard,theMASVSwillevolveovertime,andwewelcomeanycontributionsandsuggestions.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 7
Frontispiece
AbouttheStandard
WelcometotheMobileApplicationSecurityVerificationStandard(MASVS)0.9.2.TheMASVSisacommunityefforttoestablishaframeworkofsecurityrequirementsneededtodesign,developandtestsecuremobileappsoniOSandAndroid.
TheMASVSisaculminationofcommunityeffortandindustryfeedback.Weexpectthisstandardtoevolveovertimeandwelcomefeedbackfromthecommunity.ThebestwaytogetincontactwithusisviatheOWASPMobileProjectSlackchannel:
https://owasp.slack.com/messages/project-mobile_omtg/details/
AccountscanbecreatedatthefollowingURL:
http://owasp.herokuapp.com/.
CopyrightandLicense
Copyright©2017TheOWASPFoundation.ThisdocumentisreleasedundertheCreativeCommonsAttributionShareAlike3.0license.Foranyreuseordistribution,youmustmakecleartoothersthelicensetermsofthiswork.
Acknowledgements
Version0.9.2,February2017
ProjectLeads Authors ContributorsandReviewers
BernhardMuellerSvenSchleier
BernhardMueller StephenCorbiauxSvenSchleierJeroenWillemsenAnantShrivastavaAbdessamadTemmarAlexanderAntukhRobertoMartelloniStefaanSeysPrabhantSinghFrancescoStillavatoAbhinavSejpal
ThisdocumentstartedasaforkoftheOWASPApplicationSecurityVerificationStandardwrittenbyJimManico.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 8
TheMobileApplicationSecurityVerificationStandard
TheMASVScanbeusedtoestablishalevelofconfidenceinthesecurityofmobileapps.Therequirementsweredevelopedwiththefollowingobjectivesinmind:
• Useasametric-Toprovideasecuritystandardagainstwhichexistingmobileappscanbecomparedbydevelopersandapplicationowners;
• Useasguidance-Toprovideguidanceduringallphasesofmobileappdevelopmentandtesting;
• Useduringprocurement-Toprovideabaselineformobileappsecurityverification.
MobileAppSecModel
TheMASVSdefinestwostrictsecurityverificationlevels(L1andL2),aswellasetofreverseengineeringresiliencyrequirements(MASVS-R)thatisflexible,i.e.adaptabletoanapp-specificthreatmodel.MASVS-L1andMASVS-L2containgenericsecurityrequirementsandarerecommendedforallmobileapps(L1)andappsthathandlehighlysensitivedata(L2).MASVS-Rcoversadditionalprotectivecontrolsthatcanbeappliedifpreventingclient-sidethreatsisadesigngoal.
FulfillingtherequirementsinMASVS-L1resultsinasecureappthatfollowssecuritybestpracticesanddoesn'tsufferfromcommonvulnerabilities.MASVS-L2addsadditionalsecuritymeasuressuchasSSLpinning,resultinginanappthatisresilientagainstmoresophisticatedattacks-assumingthesecuritycontrolsofthemobileoperatingsystemareintactandtheenduserisnotviewedasapotentialadversary.Fulfillingall,orsubsetsof,thesoftwareprotectionrequirementsinMASVS-Rhelpsimpedespecificclient-sidethreatswheretheenduserismaliciousand/orthemobileOSiscompromised.
NotethatthesoftwareprotectioncontrolslistedinMASVS-Rmustneverbeusedasareplacementforsecuritycontrols.Instead,theyareintendedtoaddthreat-specific,additionalprotectivecontrolstoappsthatalsofulfiltheMASVSrequirementsinMASVSL1orL2.
Figure1:SecurityVerificationLevels.MASVS-L1providesasolidsecuritybaselinethatisappropriateformostmobileapps.
MASVS-L2addsdefense-in-depth-controls.MASVS-Rrepresentsanoptionalprotectivelayerforimpedingreverseengineeringandtampering.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 9
DocumentStructure
ThefirstpartoftheMASVScontainsadescriptionofthesecuritymodelandavailableverificationlevels,followedbyrecommendationsonhowtousethestandardinpractice.Thedetailedsecurityrequirements,alongwithamappingtotheverificationlevels,arelistedinthesecondpart.Therequirementshavebeengroupedintoeightcategories(V1toV8)basedontechnicalobjective/scope.ThefollowingnomenclatureisusedthroughouttheMASVSandMSTG:
• Requirementcategory:MASVS-V[x],e.g.MASVS-V2:DataStorageandPrivacy• Requirement:MASVS-[x].[y],e.g.MASVS-V2.2:"Nosensitivedataiswrittento
applicationlogs."
Attheendofeachcategory,weincludealinktotherespectivegroupoftestcasesintheOWASPMobileSecurityTestingGuide,manyofwhichelaboratefurtheroneachrequirementinthecontextofaparticularmobileoperatingsystem.FollowingtheMSTGlink,wealsolistlinkstootherusefulstandardsandresources.
TheVerificationLevelsinDetail
MASVS-L1:StandardSecurity
AmobileappthatachievesMASVS-L1adherestomobileapplicationsecuritybestpractices.Itfulfilsbasicrequirementsintermsofcodequality,handlingofsensitivedata,andinteractionwiththemobileenvironment.Atestingprocessmustbeinplacetoverifythesecuritycontrols.Thislevelisappropriateforallmobileapplications.
MASVS-L2:Defense-in-Depth
MASVS-L2introducesadvancedsecuritycontrolsthatgobeyondthestandardrequirements.TofulfilL2,athreatmodelmustexist,andsecuritymustbeanintegralpartoftheapp'sarchitectureanddesign.Thislevelisappropriateforapplicationsthathandlesensitivedata,suchasmobilebanking.
MASVS-R:ResiliencyAgainstReverseEngineeringandTampering
Theapphasstate-of-the-artsecurity,andisalsoresilientagainstspecific,clearlydefinedclient-sideattacks,suchastampering,modding,orreverseengineeringtoextractsensitivecodeordata.Suchanappeitherleverageshardwaresecurityfeaturesorsufficientlystrongandverifiablesoftwareprotectiontechniques.MASVS-Risapplicabletoappsthathandlehighlysensitivedataandmayserveasameansofprotectingintellectualpropertyortamper-proofinganapp.
RecommendedUse
AppscanbeverifiedagainstMASVSL1orL2basedonpriorriskassessmentandoveralllevelofsecurityrequired.L1isapplicabletoallmobileapps,whileL2isgenerallyrecommendedforappsthathandlemoresensitivedataand/orfunctionality.MASVS-R(orpartsofit)canbeappliedtoverifyresiliencyagainstspecificthreats,suchasrepackagingorextractionofsensitivedata,inadditiontopropersecurityverification.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 10
Insummary,thefollowingverificationtypesareavailable:
• MASVS-L1• MASVS-L1+R• MASVS-L2• MASVS-L2+R
Thedifferentcombinationsreflectdifferentgradesofsecurityandresiliency.Thegoalistoallowforflexibility:Forexample,amobilegamemightnotwarrantaddingMASVS-L2securitycontrolssuchas2-factorauthenticationforusabilityreasons,buthaveastrongbusinessneedfortamperingprevention.
WhatVerificationTypetoChoose
ImplementingtherequirementsofMASVSL2increasessecurity,whileatthesametimeincreasingcostofdevelopmentandpotentiallyworseningtheenduserexperience(theclassicaltrade-off).Ingeneral,L2shouldbeusedforappswheneveritmakessensefromariskvs.costperspective(i.e.,wherethepotentiallosscausedbyacompromiseconfidentialityorintegrityishigherthanthecostincurredbytheadditionalsecuritycontrols).AriskassessmentshouldbethefirststepbeforeapplyingtheMASVS.
Examples
MASVS-L1
• Allmobileapps.MASVS-L1listssecuritybestpracticesthatcanbefollowedwithareasonableimpactondevelopmentcostanduserexperience.ApplytherequirementsinMASVS-L1foranyappthatdon'tqualifyforoneofthehigherlevels.
MASVS-L2
• Health-CareIndustry:Mobileappsthatstorepersonallyidentifiableinformationthatcanbeusedforidentitytheft,fraudulentpayments,oravarietyoffraudschemes.FortheUShealthcaresector,complianceconsiderationsincludetheHealthInsurancePortabilityandAccountabilityAct(HIPAA)Privacy,Security,BreachNotificationRulesandPatientSafetyRule.
• FinancialIndustry:Appsthatenableaccesstohighlysensitiveinformationlikecreditcardnumbers,personalinformation,orallowtheusertomovefunds.Theseappswarrantadditionalsecuritycontrolstopreventfraud.FinancialappsneedtoensurecompliancetothePaymentCardIndustryDataSecurityStandard(PCIDSS),GrammLeechBlileyActandSarbanes-OxleyAct(SOX).
MASVSL1+R
• MobileappswhereIPprotectionisabusinessgoal.TheresiliencycontrolslistedinMASVS-Rcanbeusedtoincreasetheeffortneededtoobtaintheoriginalsourcecodeandtoimpedetampering/cracking.
• GamingIndustry:Gameswithanessentialneedtopreventmoddingandcheating,suchascompetitiveonlinegames.Cheatingisanimportantissueinonlinegames,asalargeamountofcheatersleadstoadisgruntledtheplayerbaseandcanultimatelycausea
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 11
gametofail.MASVS-Rprovidesbasicanti-tamperingcontrolstohelpincreasetheeffortforcheaters.
MASVSL2+R
• FinancialIndustry:Onlinebankingappsthatallowtheusertomovefunds,wheretechniquescodeinjectionandinstrumentationoncompromiseddevicesposearisk.Inthiscase,controlsfromMASVS-Rcanbeusedtoimpedetampering,raisingthebarformalwareauthors.
• Allmobileappsthat,bydesign,needtostoresensitivedataonthemobiledevice,andatthesametimemustsupportawiderangeofdevicesandoperatingsystemversions.Inthiscase,resiliencycontrolscanbeusedasandefense-in-depthmeasuretoincreasetheeffortforattackersaimingtoextractthesensitivedata.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 12
AssessmentandCertification
OWASP'sStanceonCertificationsandTrustMarks
OWASP,asavendor-neutralnot-for-profitorganization,doesnotcertifyanyvendors,verifiersorsoftware.
Allsuchassuranceassertions,trustmarks,orcertificationsarenotofficiallyvetted,registered,orcertifiedbyOWASP,soanorganizationrelyinguponsuchaviewneedstobecautiousofthetrustplacedinanythirdpartyortrustmarkclaimingASVScertification.
Thisshouldnotinhibitorganizationsfromofferingsuchassuranceservices,aslongastheydonotclaimofficialOWASPcertification.
GuidanceforCertifyingMobileApps
TherecommendedwayofverifyingcomplianceofamobileappwiththeMASVSisbyperformingan"openbook"review,meaningthatthetestersaregrantedaccesstokeyresourcessuchasarchitectsanddevelopersoftheapp,projectdocumentation,sourcecode,andauthenticatedaccesstoendpoints,includingaccesstoatleastoneuseraccountforeachrole.
ItisimportanttonotethattheMASVSonlycoverssecurityofthe(client-side)mobileappandthenetworkcommunicationbetweentheappanditsremoteendpoint(s),aswellasafewbasicandgenericrequirementsrelatedtouserauthenticationandsessionmanagement.Itdoesnotcontainspecificrequirementsfortheremoteservices(e.g.webservices)associatedwiththeapp,safeforalimitedsetofgenericrequirementspertainingtoauthenticationandsessionmanagement.However,MASVSV1specifiesthatremoteservicesmustbecoveredbytheoverallthreatmodel,andbeverifiedagainstappropriatestandards,suchastheOWASPASVS.
Acertifyingorganizationmustincludeinanyreportthescopeoftheverification(particularlyifakeycomponentisoutofscope),asummaryofverificationfindings,includingpassedandfailedtests,withclearindicationsofhowtoresolvethefailedtests.Keepingdetailedworkpapers,screenshotsormovies,scriptstoreliablyandrepeatedlyexploitanissue,andelectronicrecordsoftesting,suchasinterceptingproxylogsandassociatednotessuchasaclean-uplist,isconsideredstandardindustrypractice.Itisnotsufficienttosimplyrunatoolandreportonthefailures;thisdoesnotprovidesufficientevidencethatallissuesatacertifyinglevelhavebeentestedandtestedthoroughly.Incaseofdispute,thereshouldbesufficientsupportiveevidencetodemonstrateeachandeveryverifiedrequirementhasindeedbeentested.
TheOWASPMobileSecurityTestingGuide(MSTG)
TheOWASPMSTGisamanualfortestingthesecurityofmobileapps.ItdescribesthetechnicalprocessesforverifyingtherequirementslistedintheMASVS.TheMSTGincludesalistoftestcases,eachofwhichmaptoarequirementintheMASVS.Forexample,OWASPMASVSV2"DataStorageandPrivacyRequirements"mapstothe"OMTG-DATAST"section
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 13
oftheMSTG.TheMSTGtestcaseOMTG-DATAST-009describeshowtoverifytherequirementOWASPMASVSV2.9:
• OWASPMASVSV2.9"Verifythatsensitivedatadoesnotleaktobackups."• OMTG-DATAST-009:"TestforSensitiveDatainBackups"
WhilemanyoftheMASVSrequirementsarehigh-levelandgeneric,theMSTGprovidesin-depthrecommendationsandtestingproceduresonaper-mobile-OSbasis.
TheRoleofAutomatedSecurityTestingTools
Theuseofsourcecodescannersandblack-boxtestingtoolsisencouragedinordertoincreaseefficiencywheneverpossible.ItishowevernotpossibletocompleteMASVSverificationusingautomatedtoolsalone:Everymobileappisdifferent,andunderstandingtheoverallarchitecture,businesslogic,andtechnicalpitfallsofthespecifictechnologiesandframeworksbeingusedisamandatoryrequirementtoverifysecurity.
OtherUses
AsDetailedSecurityArchitectureGuidance
OneofthemorecommonusesfortheMobileApplicationSecurityVerificationStandardisasaresourceforsecurityarchitects.Thetwomajorsecurityarchitectureframeworks,SABSAorTOGAF,aremissingagreatdealofinformationthatisnecessarytocompletemobileapplicationsecurityarchitecturereviews.MASVScanbeusedtofillinthosegapsbyallowingsecurityarchitectstochoosebettercontrolsforissuescommontomobileapps.
AsaReplacementforOff-the-ShelfSecureCodingChecklists
ManyorganizationscanbenefitfromadoptingtheMASVS,bychoosingoneofthefourlevels,orbyforkingMASVSandchangingwhatisrequiredforeachapplication'srisklevelinadomain-specificway.Weencouragethistypeofforkingaslongastraceabilityismaintained,sothatifanapphaspassedrequirement4.1,thismeansthesamethingforforkedcopiesasthestandardevolves.
AsaBasisforSecurityTestingMethodologies
AgoodmobileappsecuritytestingmethodologyshouldcoverallrequirementslistedintheMASVS.TheOWASPMobileSecurityTestingGuide(MSTG)describesblack-boxandwhite-boxtestcasesforeachverificationrequirement.
AsaGuideforAutomatedUnitandIntegrationTests
TheMASVSisdesignedtobehighlytestable,withthesoleexceptionofarchitecturalrequirements.Automatedunit,integrationandacceptancetestingbasedontheMASVSrequirementscanbeintegratedinthecontinuousdevelopmentlifecycle.Thisnotonlyincreasesdevelopersecurityawareness,butalsoimprovestheoverallqualityoftheresultingapps,andreducestheamountoffindingsduringsecuritytestinginthepre-releasephase.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 14
ForSecureDevelopmentTraining
MASVScanalsobeusedtodefinecharacteristicsofsecuremobileapps.Many"securecoding"coursesaresimplyethicalhackingcourseswithalightsmearofcodingtips.Thisdoesnothelpdevelopers.Instead,securedevelopmentcoursescanusetheMASVS,withastrongfocusontheproactivecontrolsdocumentedintheMASVS,ratherthane.g.theTop10codesecurityissues.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 15
V1:Architecture,DesignandThreatModellingRequirements
ControlObjective
Inaperfectworld,securitywouldbeconsideredthroughoutallphasesofdevelopment.Inrealityhowever,securityisoftenonlyaconsiderationatalatestageintheSDLC.Besidesthetechnicalcontrols,theMASVSrequiresprocessestobeinplacethatensurethatthesecurityhasbeenexplicitlyaddressedwhenplanningthearchitectureofthemobileapp,andthatthefunctionalandsecurityrolesofallcomponentsareknown.Sincemostmobileapplicationsactasclientstoremoteservices,itmustbeensuredthatappropriatesecuritystandardsarealsoappliedtothoseservices-testingthemobileappinisolationisnotsufficient.
Thecategory“V1”listsrequirementspertainingtoarchitectureanddesignoftheapp.Assuch,thisistheonlycategorythatdoesnotmaptotechnicaltestcasesintheOWASPMobileTestingGuide.Tocovertopicssuchasthreatmodelling,secureSDLC,keymanagement,usersoftheMASVSshouldconsulttherespectiveOWASPprojectsand/orotherstandardssuchastheoneslinkedbelow.
SecurityVerificationRequirements
# Description L1 L21.1 Allappcomponentsareidentifiedandknowntobeneeded. ✓ ✓
1.2 Allthirdpartycomponentsusedbythemobileapp,suchaslibrariesandframeworks,areidentified,andcheckedforknownvulnerabilities. ✓ ✓
1.3 Securitycontrolsareneverenforcedonlyontheclientside,butontherespectiveremoteendpoints. ✓ ✓
1.4 Ahigh-levelarchitectureforthemobileappandallconnectedremoteserviceshasbeendefinedandsecurityhasbeenaddressedinthatarchitecture.
✓ ✓
1.5 Dataconsideredsensitiveinthecontextofthemobileappisclearlyidentified.
✓ ✓
1.6 Allappcomponentsaredefinedintermsofthebusinessfunctionsand/orsecurityfunctionstheyprovide.
✓
1.7 Athreatmodelforthemobileappandtheassociatedremoteserviceshasbeenproducedthatidentifiespotentialthreatsandcountermeasures.
✓
1.8 Allthirdpartycomponentshavebeenassessed(associatedrisks)beforebeingusedorimplemented.Aprocessisinplacetoensurethateachtimeasecurityupdateforathirdpartycomponentispublished,thechangeisinspectedandtheriskevaluated.
✓
1.9 Allsecuritycontrolshaveacentralizedimplementation. ✓
1.10 Allcomponentsthatarenotpartoftheapplicationbutthattheapplicationreliesontooperate,areclearlyidentifiedandthesecurityimplicationsofusingthosecomponentsareknown.
✓
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 16
# Description L1 L21.11 Thereisanexplicitpolicyforhowcryptographickeys(ifany)are
managed,andthelifecycleofcryptographickeysisenforced.Ideally,followakeymanagementstandardsuchasNISTSP800-57.
✓
1.12 Remoteendpointsverifythatconnectingclientsuseanup-to-dateversionofthemobileapp.
✓
1.13 Securityisaddressedwithinallpartsofthesoftwaredevelopmentlifecycle.
✓
References
Formoreinformation,seealso:
• OWASPMobileTop10:M10-ExtraneousFunctionality• OWASPSecurityArchitecturecheatsheet:
https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet• OWASPThreadmodelling:
https://www.owasp.org/index.php/Application_Threat_Modeling• OWASPSecureSDLCCheatSheet:
https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet• MicrosoftSDL:https://www.microsoft.com/en-us/sdl/• NISTSP800-57:http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-
revised2_Mar08-2007.pdf
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 17
V2:DataStorageandPrivacyRequirements
ControlObjective
Theprotectionofsensitivedata,suchasusercredentialsandprivateinformation,isakeyfocusinmobilesecurity.Firstly,sensitivedatamaybeunintentionallyexposedtootherappsrunningonthesamedeviceifoperatingsystemmechanismslikeIPCareusedimproperly.Datamayalsounintentionallyleaktoplatformcloudstorage,backups,orthekeyboardcache.Furthermore,mobiledevicesarelostorstolenmoreeasilycomparedtoothertypesofdevices,soanadversarygainingphysicalaccessisamorelikelyscenario.Inthatcase,additionalprotectionscanbeimplementedtomakeretrievingthesensitivedatamoredifficult.
Notethat,astheMASVSisapp-centric,itdoesnotcoverdevice-levelpoliciessuchasthoseenforcedbyMDMandEDMsolutions.WehoweverencouragetheuseofsuchsolutionsinanEnterprisecontexttofurtherenhancedatasecurity.
DefinitionofSensitiveData
SensitivedatainthecontextoftheMASVSpertainstobothusercredentialsandanyotherdataconsideredsensitiveintheparticularcontext,suchas:
• Personallyidentifiableinformation(PII)thatcanbeabusedforidentitytheft:Socialsecuritynumbers,creditcardnumbers,bankaccountnumbers,healthinformation;
• Highlysensitivedatathatwouldleadtoreputationalharmand/orfinancialcostsifcompromised:Contractualinformation,informationcoveredbynon-disclosureagreements,managementinformation;
• Anydatathatmustbeprotectedbylaworforcompliancereasons.
Themajorityofdatadisclosureissuescanbepreventedbyfollowingsimplerules.Therefore,mostofthecontrolslistedinthischapteraremandatoryfromMASVS-L1.
SecurityVerificationRequirements
# Description L1 L22.1 Systemcredentialstoragefacilitiesareusedappropriatelytostore
sensitivedata,suchasusercredentialsorcryptographickeys. ✓ ✓
2.2 Nosensitivedataiswrittentoapplicationlogs. ✓ ✓
2.3 Nosensitivedataissharedwiththirdpartiesunlessitisanecessarypartofthearchitecture.
✓ ✓
2.4 Thekeyboardcacheisdisabledontextinputsthatprocesssensitivedata. ✓ ✓
2.5 Theclipboardisdeactivatedontextfieldsthatmaycontainsensitivedata. ✓ ✓
2.6 NosensitivedataisexposedviaIPCmechanisms. ✓ ✓
2.7 Nosensitivedata,suchaspasswordsandcreditcardnumbers,isexposedthroughtheuserinterfaceorleakstoscreenshots. ✓ ✓
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 18
# Description L1 L22.8 Nosensitivedataisincludedinbackupsgeneratedbythemobile
operatingsystem. ✓
2.9 Theappremovessensitivedatafromviewswhenbackgrounded. ✓
2.10 Theappdoesnotholdsensitivedatainmemorylongerthannecessary,andmemoryisclearedexplicitlyafteruse.
✓
2.11 Theappenforcesaminimumdevice-access-securitypolicy,suchasrequiringtheusertosetadevicepasscode.
✓
2.12 Theappeducatestheuseraboutthetypesofpersonallyidentifiableinformationprocessed,aswellassecuritybestpracticestheusershouldfollowinusingtheapp.
✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection,aswellasbestpracticesbymobileoperatingsystem:
(...TODO...linkthistov1.0insteadofmasteroncetagged).
ForAndroid:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x01a_OMTG-DATAST_Android.md
ForiOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x02a_OMTG-DATAST_iOS.md
References
• OWASPMobileTop10:M2-InsecureDataStorage• CWE:https://cwe.mitre.org/data/definitions/922.html
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 19
V3:CryptographyRequirements
ControlObjective
Cryptographyisanessentialingredientwhenitcomestoprotectingdatastoredonamobiledevice.Itisalsoacategorywherethingscangoutterlywrong,especiallywhenstandardconventionsarenotfollowed.Thepurposeofthecontrolsinthischapteristoensurethattheverifiedapplicationusescryptographyaccordingtoindustrybestpractices,including:
• Useofprovencryptographiclibraries;• Properchoiceandconfigurationofcryptographicprimitives;• Asuitablerandomnumbergeneratorwhereverrandomnessisrequired.
SecurityVerificationRequirements
# Description L1 L23.1 Theappdoesnotrelyonsymmetriccryptographywithhardcodedkeysasa
solemethodofencryption.✓ ✓
3.2 Theappusesprovenimplementationsofcryptographicprimitives. ✓ ✓
3.3 Theappusescryptographicprimitivesthatareappropriatefortheparticularuse-case,configuredwithparametersthatadheretoindustrybestpractices.
✓ ✓
3.4 Theappdoesnotusecryptographicprotocolsoralgorithmsthatarewidelyconsidereddepreciatedforsecuritypurposes. ✓ ✓
3.5 Theappdoesn'tre-usethesamecryptographickeyformultiplepurposes. ✓ ✓
3.6 Allrandomvaluesaregeneratedusingasufficientlysecurerandomnumbergenerator.
✓ ✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection,aswellasbestpracticesbymobileoperatingsystem:
(...TODO...linkthistov1.0insteadofmasteroncetagged).
ForAndroid:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x01b_OMTG-CRYPTO_Android.md
ForiOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x02b_OMTG-CRYPTO_iOS.md
References
• OWASPMobileTop10:M6-BrokenCryptography• CWE:https://cwe.mitre.org/data/definitions/310.html
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 20
V4:AuthenticationandSessionManagementRequirements
ControlObjective
Inmostcases,userlogintoaremoteserviceisanintegralpartoftheoverallmobileapparchitecture.Eventhoughmostofthelogichappensattheendpoint,MASVSdefinessomebasicrequirementsregardinghowuseraccountsandsessionsaremanaged.Therequirementscanbeeasilyverifiedwithoutaccesstothesourcecodeoftheserviceendpoint.
SecurityVerificationRequirements
# Description L1 L2
4.1
Iftheappprovidesuserswithaccesstoaremoteservice,anacceptableformofauthenticationsuchasusername/passwordauthenticationisperformedattheremoteendpoint.
✓ ✓
4.2Theremoteendpointusesrandomlygeneratedaccesstokenstoauthenticateclientrequestswithoutsendingtheuser'scredentials. ✓ ✓
4.3Theremoteendpointterminatestheexistingsessionwhentheuserlogsout.
✓ ✓
4.4 Apasswordpolicyexistsandisenforcedattheremoteendpoint. ✓ ✓
4.5
Theremoteendpointimplementsanexponentialback-off,ortemporarilylockstheuseraccount,whenincorrectauthenticationcredentialsaresubmittedanexcessivenumberoftimes.
✓ ✓
4.6
Biometricauthentication,ifany,isnotevent-bound(i.e.usinganAPIthatsimplyreturns"true"or"false").Instead,itisbasedonunlockingthekeychain/keystore.
✓
4.7Sessionsareterminatedattheremoteendpointafterapredefinedperiodofinactivity.
✓
4.8Asecondfactorofauthenticationexistsattheremoteendpointandthe2FArequirementisconsistentlyenforced.
✓
4.9Step-upauthenticationisrequiredtoenableactionsthatdealwithsensitivedataortransactions.
✓
4.10
Theappinformstheuserofallloginactivitieswithhisorheraccount.Usersareableviewalistofdevicesusedtoaccesstheaccount,andtoblockspecificdevices.
✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection,aswellasbestpracticesbymobileoperatingsystem:
(...TODO...linkthistov1.0insteadofmasteroncetagged).
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 21
ForAndroid:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x01c_OMTG-AUTH_Android.md
ForiOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x02c_OMTG-AUTH_iOS.md
References
• OWASPMobileTop10:M4-InsecureAuthentication,M6-InsecureAuthorization• CWE:https://cwe.mitre.org/data/definitions/287.html
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 22
V5:NetworkCommunicationRequirements
ControlObjective
Thepurposeofthiscontrolistoensuretheconfidentialityandintegrityofinformationexchangedbetweenthemobileappandremoteserviceendpoints.Attheveryleast,amobileappmustsetupasecure,encryptedchannelfornetworkcommunicationusingtheTLSprotocolwithappropriatesettings.Forleveltwoorhigher,additionaldefense-in-depthmeasuresuchasSSLpinningarerequired.
SecurityVerificationRequirements
# Description L1 L2
5.1DataisencryptedonthenetworkusingTLS.Thesecurechannelisusedconsistentlythroughouttheapp. ✓ ✓
5.2
TheTLSsettingsareinlinewithcurrentbestpractices,orascloseaspossibleifthemobileoperatingsystemdoesnotsupporttherecommendedstandards.
✓ ✓
5.3
TheappverifiestheX.509certificateoftheremoteendpointwhenthesecurechannelisestablished.OnlycertificatessignedbyavalidCAareaccepted.
✓ ✓
5.4
Theappeitherusesitsowncertificatestore,orpinstheendpointcertificateorpublickey,andsubsequentlydoesnotestablishconnectionswithendpointsthatofferadifferentcertificateorkey,evenifsignedbyatrustedCA.
✓
5.5Theappdoesn'trelyonasingleinsecurecommunicationchannel(emailorSMS)forcriticaloperations,suchasenrolmentsandaccountrecovery.
✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection,aswellasbestpracticesbymobileoperatingsystem:
(...TODO...linkthistov1.0insteadofmasteroncetagged).
ForAndroid:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x01d_OMTG-NET_Android.md
ForiOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x02d_OMTG-NET_iOS.md
References
• OWASPMobileTop10:M3-InsecureCommunication• CWE:https://cwe.mitre.org/data/definitions/319.html• CWE:https://cwe.mitre.org/data/definitions/295.html
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 23
V6:EnvironmentalInteractionRequirements
ControlObjective
ThecontrolsinthisgroupensurethattheappusesplatformAPIsandstandardcomponentsinasecuremanner.Additionally,thecontrolscovercommunicationbetweenapps(IPC).
SecurityVerificationRequirements
# Description L1 L2
6.1 Theapponlyrequeststheminimumsetofpermissionsnecessary. ✓ ✓
6.2
All inputs from external sources and the user are validated and, ifnecessary,sanitized.ThisincludesdatareceivedviatheUI,IPCmechanismssuchasintents,customURLs,andnetworksources.
✓ ✓
6.3TheappdoesnotexportsensitivefunctionalityviacustomURLschemes,unlessthesemechanismsareproperlyprotected.
✓ ✓
6.4TheappdoesnotexportsensitivefunctionalitythroughIPCfacilities,unlessthesemechanismsareproperlyprotected.
✓ ✓
6.5 JavaScriptisdisabledinWebViewsunlessexplicitlyrequired. ✓ ✓
6.6
WebViews are configured to allow only the minimum set of protocolhandlersrequired(ideally,onlyhttpsissupported).Potentiallydangeroushandlers,suchasfile,telandapp-id,aredisabled.
✓ ✓
6.7 Theappdoesnotloaduser-suppliedlocalresourcesintoWebViews. ✓ ✓
6.8If Javaobjectsareexposed inaWebView,verify that theWebViewonlyrendersJavaScriptcontainedwithintheapppackage. ✓ ✓
6.9 Objectserialization,ifany,isimplementedusingsafeserializationAPIs. ✓ ✓
6.10
The app detectswhether it is being executed on a rooted or jailbrokendevice.Dependingonthebusinessrequirement,usersarewarned,ortheappisterminatedifthedeviceisrootedorjailbroken.
✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection,aswellasbestpracticesbymobileoperatingsystem:
Android:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x01e_OMTG-ENV_Android.md
iOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x02e_OMTG-ENV_iOS.md
References
• OWASPMobileTop10:M1-ImproperPlatformUsage• CWE:https://cwe.mitre.org/data/definitions/20.html• CWE:https://cwe.mitre.org/data/definitions/749.html
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 24
V7:CodeQualityandBuildSettingRequirements
ControlObjective
Thegoalofthiscontrolistoensurethatbasicsecuritycodingpracticesarefollowedindevelopingtheapp,andthat"free"securityfeaturesofferedbythecompilerareactivated.
SecurityVerificationRequirements
# Description L1 L27.1 Theappissignedandprovisionedwithvalidcertificate. ✓ ✓
7.2Theapphasbeenbuiltinreleasemode,withsettingsappropriateforareleasebuild(e.g.non-debuggable). ✓ ✓
7.3 Debuggingsymbolshavebeenremovedfromnativebinaries. ✓ ✓
7.4Debuggingcodehasbeenremoved,andtheappdoesnotlogverboseerrorsordebuggingmessages.
✓ ✓
7.5 Theappcatchesandhandlespossibleexceptions. ✓ ✓
7.6 Errorhandlinglogicinsecuritycontrolsdeniesaccessbydefault. ✓ ✓
7.7 Inunmanagedcode,memoryisallocated,freedandusedsecurely. ✓ ✓
7.8Securityfeaturesofferedbythecompiler,suchasstackprotection,PIEsupportandautomaticreferencecounting,areactivated. ✓ ✓
7.9 Javabytecodehasbeenminified. ✓ ✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection,aswellasbestpracticesbymobileoperatingsystem:
(...TODO...linkthistov1.0insteadofmasteroncetagged).
Android:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x01f_OMTG-CODE_Android.md
iOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x02f_OMTG-CODE_iOS.md
References
• OWASPMobileTop10:M7-ClientCodeQuality• CWE:https://cwe.mitre.org/data/definitions/119.html• CWE:https://cwe.mitre.org/data/definitions/89.html• CWE:https://cwe.mitre.org/data/definitions/388.html• CWE:https://cwe.mitre.org/data/definitions/489.html
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 25
V8:ResiliencyAgainstReverseEngineeringRequirements
Controlobjective
Thissectioncoverssoftwareprotectionmeasuresthatarerecommendedforappsthatprocess,orgiveaccessto,sensitivedataorfunctionality.Lackofanyofthesecontrolsdoesnotcauseavulnerability-instead,theyaremeanttoincreasetheapp'sresiliencyagainstreverseengineering,makingitmoredifficultforadversariestogainanunderstandingoftheapp'sinternalsorextractdatafromtheapp.
Thecontrolsinthissectiondifferfromprevioussectionsinthattheydonotapplytoallmobileappsgenerically.Rather,thecontrolsdescribedhereshouldbeappliedasneeded,basedonassessmentoftheriskcausedbyunauthorizedmodificationand/orreverseengineeringoftheapp.
TheOWASPdocument"TechnicalRisksofReverseEngineeringandUnauthorizedCodeModificationReverseEngineeringandCodeModificationPrevention"(seereferencesbelow)listsbusinessrisksaswellasdependenttechnicalthreatsrelatedtotamperingandreverseengineering.Inthesectionsbelow,werefertothetechnicalthreatsdescribedinthatdocument.
Foranyofthecontrolsinthelistbelowtobeeffective,theappmustfulfilatleastallofMASVS-L1,aswellasallanylower-numberedrequirements.Forexamples,theobfuscationcontrolslistedinunder"impedecomprehension"mustbecombinedwiththoselistedunder"appisolation","impededynamicanalysisandtampering"and"devicebinding".
Notethatsoftwareprotectionsmustneverbeusedasareplacementforsecuritycontrols.ThecontrolslistedinMASVR-Rareintendedtoaddthreat-specific,additionalprotectivecontrolstoappsthatalsofulfiltheMASVSsecurityrequirements.
Thefollowingconsiderationsapply:
1. Athreatmodelmustbedefinedthatclearlyoutlinestheattacker'sgoals.Additionally,atargetsmustbesetthatspecifiesthelevelofprotectiontheprotectionschemeismeanttoprovide(e.g.,causeaneffortofatleast20man-daysforaskilledreverseengineertoreachdefinedgoalXusingstate-of-the-arttoolsandprocesses).
2. Theprotectionschemeshouldbeverifiedusingmanualresiliencytestingbyasubjectmatterexpert(seealsothe"reverseengineering"and"assessingsoftwareprotections"chaptersintheMobileSecurityTestingGuide).
AppIsolation
# Description R8.1 Theappprovidesacustomkeyboardwheneversensitivedataisentered. ✓
8.2 CustomUIcomponentsareusedtodisplaysensitivedata.TheUIcomponentsshouldnotrelyonimmutabledatastructures.
✓
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 26
ImpedeDynamicAnalysisandTampering
# Description R8.3 Theappimplementstwoormorefunctionallyindependentmethodsofroot
detectionandrespondstothepresenceofarooteddeviceeitherbyalertingtheuserorterminatingtheapp.
✓
8.4 Theappimplementsmultiplefunctionallyindependentdebuggingdefensesthat,incontextoftheoverallprotectionscheme,forceadversariestoinvestconsiderablemanualefforttoenabledebugging.Allavailabledebuggingprotocolsmustbecovered(e.g.JDWPandnative).
✓
8.5 Theappdetects,andrespondsto,tamperingwithexecutablefilesandcriticaldata.
✓
8.6 Theappdetectsthepresenceofwidelyusedreverseengineeringtools,suchascodeinjectiontools,hookingframeworksanddebuggingservers.
✓
8.7 Theappdetects,andresponseto,beingruninanemulatorusinganymethod. ✓
8.8 Theappdetects,andrespondsto,modificationsofprocessmemory,suchasrelocationtablepatchesandinjectedcode. ✓
8.9 Theappimplementsmultipledifferentresponsestotampering,debuggingandemulation,includingstealthyresponsesthatdon'tsimplyterminatetheapp.
✓
8.10 Allexecutablefilesandlibrariesbelongingtotheappareeitherencryptedonthefileleveland/orimportantcodeanddatasegmentsinsidetheexecutablesareencryptedorpacked.Trivialstaticanalysisdoesnotrevealimportantcodeordata.
✓
8.11 Obfuscatingtransformationsandfunctionaldefensesareinterdependentandwell-integratedthroughouttheapp. ✓
DeviceBinding
# Description R8.12 Theappimplementsa'devicebinding'functionalityusingadevice
fingerprintderivedfrommultiplepropertiesuniquetothedevice.✓
ImpedeComprehension
# Description R8.13 Theappusesmultiplefunctionallyindependentmethodsofemulator
detectionthat,incontextoftheoverallprotectionscheme,forceadversariestoinvestsignificantmanualefforttoruntheappinanemulator(supersedesrequirement8.7).
✓
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 27
# Description R8.14 Ifthearchitecturerequiressensitiveinformationbestoredonthedevice,
theapponlyrunsonoperatingsystemversionsanddevicesthatofferhardware-backedkeystorage.Alternatively,theinformationisprotectedusingobfuscation.Consideringcurrentpublishedresearch,theobfuscationtypeandparametersaresufficienttocausesignificantmanualeffortforreverseengineersseekingtocomprehendorextractthesensitivedata.
✓
8.15 Ifthearchitecturerequiressensitivecomputationsbeperformedontheclient-side,thesecomputationsareisolatedfromtheoperatingsystembyusingahardware-basedSE/TEE.Alternatively,theinformationisprotectedusingobfuscation.Consideringcurrentpublishedresearch,theobfuscationtypeandparametersaresufficienttocausesignificantmanualeffortforreverseengineersseekingtocomprehendthesensitiveportionsofthecodeand/ordata.
✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection,aswellasbestpracticesbymobileoperatingsystem:
(...TODO...linkthistov1.0insteadofmasteroncetagged).
Android:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x01g_OMTG-RARE_Android.md
iOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/Testcases/0x02g_OMTG-RARE_iOS.md
References
• OWASPMobileTop10:M8-CodeTampering,M9-ReverseEngineering• WASPReverseEngineeringThreats-
https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification
• OWASPReverseEngineeringandCodeModificationPrevention-https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 28
AppendixA:Glossary
• 2FA–Two-factorauthentication(2FA)addsasecondlevelofauthenticationtoanaccountlog-in.
• AddressSpaceLayoutRandomization(ASLR)–Atechniquetomakeexploitingmemorycorruptionbugsmoredifficult.
• ApplicationSecurity–Application-levelsecurityfocusesontheanalysisofcomponentsthatcomprisetheapplicationlayeroftheOpenSystemsInterconnectionReferenceModel(OSIModel),ratherthanfocusingonforexampletheunderlyingoperatingsystemorconnectednetworks.
• ApplicationSecurityVerification–ThetechnicalassessmentofanapplicationagainsttheOWASPMASVS.
• ApplicationSecurityVerificationReport–Areportthatdocumentstheoverallresultsandsupportinganalysisproducedbytheverifierforaparticularapplication.
• Authentication–Theverificationoftheclaimedidentityofanapplicationuser.• AutomatedVerification–Theuseofautomatedtools(eitherdynamicanalysistools,
staticanalysistools,orboth)thatusevulnerabilitysignaturestofindproblems.• Blackboxtesting–Itisamethodofsoftwaretestingthatexaminesthefunctionalityof
anapplicationwithoutpeeringintoitsinternalstructuresorworkings.• Component–aself-containedunitofcode,withassociateddiskandnetwork
interfacesthatcommunicateswithothercomponents.• Cross-SiteScripting(XSS)–Asecurityvulnerabilitytypicallyfoundinwebapplications
allowingtheinjectionofclient-sidescriptsintocontent.• Cryptographicmodule–Hardware,software,and/orfirmwarethatimplements
cryptographicalgorithmsand/orgeneratescryptographickeys.• DAST–Dynamicapplicationsecuritytesting(DAST)technologiesaredesignedtodetect
conditionsindicativeofasecurityvulnerabilityinanapplicationinitsrunningstate.• DesignVerification–Thetechnicalassessmentofthesecurityarchitectureofan
application.• DynamicVerification–Theuseofautomatedtoolsthatusevulnerabilitysignaturesto
findproblemsduringtheexecutionofanapplication.• GloballyUniqueIdentifier(GUID)–auniquereferencenumberusedasanidentifierin
software.• HyperTextTransferProtocol(HTTP)–Anapplicationprotocolfordistributed,
collaborative,hypermediainformationsystems.ItisthefoundationofdatacommunicationfortheWorldWideWeb.
• Hardcodedkeys–Cryptographickeyswhicharestoredinthedeviceitself.• IPC–InterProcessCommunications,InIPCProcessescommunicatewitheachother
andwiththekerneltocoordinatetheiractivities.• InputValidation–Thecanonicalizationandvalidationofuntrusteduserinput.• JAVABytecode-JavabytecodeistheinstructionsetoftheJavavirtualmachine(JVM).
Eachbytecodeiscomposedofone,orinsomecasestwobytesthatrepresenttheinstruction(opcode),alongwithzeroormorebytesforpassingparameters.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 29
• MaliciousCode–Codeintroducedintoanapplicationduringitsdevelopmentunbeknownsttotheapplicationowner,whichcircumventstheapplication'sintendedsecuritypolicy.Notthesameasmalwaresuchasavirusorworm!
• Malware–Executablecodethatisintroducedintoanapplicationduringruntimewithouttheknowledgeoftheapplicationuseroradministrator.
• OpenWebApplicationSecurityProject(OWASP)–TheOpenWebApplicationSecurityProject(OWASP)isaworldwidefreeandopencommunityfocusedonimprovingthesecurityofapplicationsoftware.Ourmissionistomakeapplicationsecurity"visible,"sothatpeopleandorganizationscanmakeinformeddecisionsaboutapplicationsecurityrisks.See:http://www.owasp.org/
• PersonallyIdentifiableInformation(PII)-isinformationthatcanbeusedonitsownorwithotherinformationtoidentify,contact,orlocateasingleperson,ortoidentifyanindividualincontext.
• PIE–Position-independentexecutable(PIE)isabodyofmachinecodethat,beingplacedsomewhereintheprimarymemory,executesproperlyregardlessofitsabsoluteaddress.
• PKI–APKIisanarrangementthatbindspublickeyswithrespectiveidentitiesofentities.Thebindingisestablishedthroughaprocessofregistrationandissuanceofcertificatesatandbyacertificateauthority(CA).
• SAST–Staticapplicationsecuritytesting(SAST)isasetoftechnologiesdesignedtoanalyzeapplicationsourcecode,bytecodeandbinariesforcodinganddesignconditionsthatareindicativeofsecurityvulnerabilities.SASTsolutionsanalyzeanapplicationfromthe“insideout”inanonrunningstate.
• SDLC–Softwaredevelopmentlifecycle.• SecurityArchitecture–Anabstractionofanapplication'sdesignthatidentifiesand
describeswhereandhowsecuritycontrolsareused,andalsoidentifiesanddescribesthelocationandsensitivityofbothuserandapplicationdata.
• SecurityConfiguration–Theruntimeconfigurationofanapplicationthataffectshowsecuritycontrolsareused.
• SecurityControl–Afunctionorcomponentthatperformsasecuritycheck(e.g.anaccesscontrolcheck)orwhencalledresultsinasecurityeffect(e.g.generatinganauditrecord).
• SQLInjection(SQLi)–Acodeinjectiontechniqueusedtoattackdatadrivenapplications,inwhichmaliciousSQLstatementsareinsertedintoanentrypoint.
• SSOAuthentication–SingleSignOn(SSO)occurswhenauserlogsintooneClientandisthensignedintootherClientsautomatically,regardlessoftheplatform,technology,ordomaintheuserisusing.Forexamplewhenyouloginingoogleyouautomaticallyloginintheyoutube,docsandmailservice.
• ThreatModeling-Atechniqueconsistingofdevelopingincreasinglyrefinedsecurityarchitecturestoidentifythreatagents,securityzones,securitycontrols,andimportanttechnicalandbusinessassets.
• TransportLayerSecurity–CryptographicprotocolsthatprovidecommunicationsecurityovertheInternet
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 30
• URI/URL/URLfragments–AUniformResourceIdentifierisastringofcharactersusedtoidentifyanameorawebresource.AUniformResourceLocatorisoftenusedasareferencetoaresource.
• Useracceptancetesting(UAT)–Traditionallyatestenvironmentthatbehavesliketheproductionenvironmentwhereallsoftwaretestingisperformedbeforegoinglive.
• Verifier–ThepersonorteamthatisreviewinganapplicationagainsttheOWASPASVSrequirements.
• Whitelist–Alistofpermitteddataoroperations,forexamplealistofcharactersthatareallowedtoperforminputvalidation.
• X.509Certificate–AnX.509certificateisadigitalcertificatethatusesthewidelyacceptedinternationalX.509publickeyinfrastructure(PKI)standardtoverifythatapublickeybelongstotheuser,computerorserviceidentitycontainedwithinthecertificate.
OWASPMobileApplicationSecurityVerificationStandardv0.9.2 31
AppendixB:References
ThefollowingOWASPprojectsaremostlikelytobeusefultousers/adoptersofthisstandard:
• OWASPMobileSecurityProject-https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
• OWASPMobileSecurityTestingGuide-https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide
• OWASPMobileTop10Risks-https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
• OWASPReverseEngineeringandCodeModificationPrevention-https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project
Similarly,thefollowingwebsitesaremostlikelytobeusefultousers/adoptersofthisstandard:
• MITRECommonWeaknessEnumeration-http://cwe.mitre.org/• PCISecurityStandardsCouncil-https://www.pcisecuritystandards.org• PCIDataSecurityStandard(DSS)v3.0RequirementsandSecurityAssessment
Procedureshttps://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf
top related