foreword by bernhard mueller, owasp mobile testing … · owasp mobile application security...
TRANSCRIPT
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 3
FOREWORDBYBERNHARDMUELLER,OWASPMOBILETESTINGGUIDEPROJECT 5
FRONTISPIECE 7
ABOUTTHESTANDARD 7COPYRIGHTANDLICENSE 7ACKNOWLEDGEMENTS 7
THEMOBILEAPPLICATIONSECURITYVERIFICATIONSTANDARD 8
MOBILEAPPSECMODEL 8
ASSESSMENTANDCERTIFICATION 12
OWASP'SSTANCEONCERTIFICATIONSANDTRUSTMARKS 12GUIDANCEFORCERTIFYINGMOBILEAPPS 12THEOWASPMOBILESECURITYTESTINGGUIDE(MSTG) 12THEROLEOFAUTOMATEDSECURITYTESTINGTOOLS 13OTHERUSES 13
V1:ARCHITECTURE,DESIGNANDTHREATMODELLINGREQUIREMENTS 14
CONTROLOBJECTIVE 14SECURITYVERIFICATIONREQUIREMENTS 14REFERENCES 15
V2:DATASTORAGEANDPRIVACYREQUIREMENTS 16
CONTROLOBJECTIVE 16DEFINITIONOFSENSITIVEDATA 16SECURITYVERIFICATIONREQUIREMENTS 16VERIFICATIONPROCESSES 17REFERENCES 17
V3:CRYPTOGRAPHYREQUIREMENTS 18
CONTROLOBJECTIVE 18SECURITYVERIFICATIONREQUIREMENTS 18REFERNCES 18REFERENCES 18
V4:AUTHENTICATIONANDSESSIONMANAGEMENTREQUIREMENTS 19
CONTROLOBJECTIVE 19SECURITYVERIFICATIONREQUIREMENTS 19VERIFICATIONPROCESSES 19REFERENCES 20
V5:NETWORKCOMMUNICATIONREQUIREMENTS 21
CONTROLOBJECTIVE 21SECURITYVERIFICATIONREQUIREMENTS 21VERIFICATIONPROCESSES 21REFERENCES 21
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 4
V6:PLATFORMINTERACTIONREQUIREMENTS 22
CONTROLOBJECTIVE 22SECURITYVERIFICATIONREQUIREMENTS 22VERIFICATIONPROCESSES 22REFERENCES 22
V7:CODEQUALITYANDBUILDSETTINGREQUIREMENTS 23
CONTROLOBJECTIVE 23SECURITYVERIFICATIONREQUIREMENTS 23VERIFICATIONPROCESSES 23REFERENCES 23
V8:RESILIENCYAGAINSTREVERSEENGINEERINGREQUIREMENTS 24
CONTROLOBJECTIVE 24IMPEDEDYNAMICANALYSISANDTAMPERING 24DEVICEBINDING 25IMPEDECOMPREHENSION 25VERIFICATIONPROCESSES 26REFERENCES 26
APPENDIXA:GLOSSARY 27
APPENDIXB:REFERENCES 30
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 5
ForewordbyBernhardMueller,OWASPMobileTestingGuideProjectTechnological revolutionscanhappenquickly.Less thanadecadeago,smartphoneswereclunky deviceswith little keyboards - expensive playthings for tech-savvy business users.Today, smartphones are an essential part of our lives.We've come to rely on them forinformation,navigationandcommunication,andtheyareubiquitousbothinbusinessandinoursociallives.
Everynewtechnologyintroducesnewsecurityrisks,andkeepingupwiththosechangesisoneofthemainchallengesthesecurity industryfaces.Thedefensiveside isalwaysafewstepsbehind.Forexample,thedefaultreflexformanywastoapplyoldwaysofdoingthings:Smartphones are like small computers, andmobile apps are just like classic software, sosurely the security requirements are similar? But it doesn't work like that. Smartphoneoperating systems are different from Desktop operating systems, and mobile apps aredifferentfromwebapps.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?Shouldthisbearequirementifanapphandlessensitivedata,orisitmaybeevencounter-productive?DoweneedtoencryptdatastoredinSQLitedatabases,eventhoughtheOSsandboxestheapp?Whatisappropriateforoneappmightbeunrealisticforanother.TheMASVSisanattempttostandardizetheserequirementsusingverificationlevelsthatfitdifferentthreatscenarios.
Furthermore,theappearanceofrootmalwareandremoteadministrationtoolshascreatedawarenessofthefactthatmobileoperatingsystemsthemselveshaveexploitableflaws,so
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 6
containerizationstrategiesareincreasinglyusedtoaffordadditionalprotectiontosensitivedataandpreventclient-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.4 7
Frontispiece
AbouttheStandard
WelcometotheMobileApplicationSecurityVerificationStandard(MASVS)0.9.4.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.4,September2017ProjectLeads Authors Contributorsand
Reviewers
BernhardMuellerSvenSchleier
BernhardMueller AbdessamadTemmarAbhinavSejpalAlexanderAntukhAnantShrivastavaFrancescoStillavatoJeroenWillemsenNikhilSoniPrabhantSinghStephenCorbiauxSvenSchleierRobertoMartelloniSjoerdLangkemperStefaanSeysYogeshSharma
ThisdocumentstartedasaforkoftheOWASPApplicationSecurityVerificationStandardwrittenbyJimManico.
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 8
TheMobileApplicationSecurityVerificationStandardTheMASVScanbeusedtoestablishalevelofconfidenceinthesecurityofmobileapps.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.4 9
DocumentStructure
ThefirstpartoftheMASVScontainsadescriptionofthesecuritymodelandavailableverificationlevels,followedbyrecommendationsonhowtousethestandardinpractice.Thedetailedsecurityrequirements,alongwithamappingtotheverificationlevels,arelistedinthesecondpart.Therequirementshavebeengrouped2intoeightcategories(V1toV8)basedontechnicalobjective/scope.ThefollowingnomenclatureisusedthroughouttheMASVS:
• Requirementcategory:MASVS-V[x],e.g.MASVS-V2:DataStorageandPrivacy• Requirement:MASVS-[x].[y],e.g.MASVS-V2.2:"Nosensitivedataiswrittento
applicationlogs."Attheendofeachcategory,weincludedalinktotherelevantsectionintheOWASPMobileSecurityTestingGuide.ThetestingguideelaboratesfurtheroneachrequirementandprovidesdetailedverificationinstructionsforiOSandAndroidapps.Wealsoaddedlinkstootherusefulstandardsandresources.
TheVerificationLevelsinDetailMASVS-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.
Insummary,thefollowingverificationtypesareavailable:
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 10
• 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,asalargeamountofcheatersleadstoadisgruntledtheplayerbaseandcanultimatelycauseagametofail.MASVS-Rprovidesbasicanti-tamperingcontrolstohelpincreasetheeffortforcheaters.
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 11
MASVSL2+R
• FinancialIndustry:Onlinebankingappsthatallowtheusertomovefunds,wheretechniquescodeinjectionandinstrumentationoncompromiseddevicesposearisk.Inthiscase,controlsfromMASVS-Rcanbeusedtoimpedetampering,raisingthebarformalwareauthors.
• Allmobileappsthat,bydesign,needtostoresensitivedataonthemobiledevice,andatthesametimemustsupportawiderangeofdevicesandoperatingsystemversions.Inthiscase,resiliencycontrolscanbeusedasadefense-in-depthmeasuretoincreasetheeffortforattackersaimingtoextractthesensitivedata.
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 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,suchasinterceptingproxylogsandassociatednotessuchasacleanuplist,isconsideredstandardindustrypractice.Itisnotsufficienttosimplyrunatoolandreportonthefailures;thisdoesnotprovidesufficientevidencethatallissuesatacertifyinglevelhavebeentestedandtestedthoroughly.Incaseofdispute,thereshouldbesufficientsupportiveevidencetodemonstratethateveryverifiedrequirementhasindeedbeentested.
TheOWASPMobileSecurityTestingGuide(MSTG)
TheOWASPMSTGisamanualfortestingthesecurityofmobileapps.ItdescribesthetechnicalprocessesforverifyingtherequirementslistedintheMASVS.TheMSTGincludesalistoftestcases,eachofwhichmaptoarequirementintheMASVS.WhiletheMASVSrequirementsarehigh-levelandgeneric,theMSTGprovidesin-depthrecommendationsandtestingproceduresonaper-mobile-OSbasis.
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 13
TheRoleofAutomatedSecurityTestingTools
Theuseofsourcecodescannersandblack-boxtestingtoolsisencouragedinordertoincreaseefficiencywheneverpossible.ItishowevernotpossibletocompleteMASVSverificationusingautomatedtoolsalone:Everymobileappisdifferent,andunderstandingtheoverallarchitecture,businesslogic,andtechnicalpitfallsofthespecifictechnologiesandframeworksbeingusedisamandatoryrequirementtoverifysecurity.
OtherUses
AsDetailedSecurityArchitectureGuidance
OneofthemorecommonusesfortheMobileApplicationSecurityVerificationStandardisasaresourceforsecurityarchitects.Thetwomajorsecurityarchitectureframeworks,SABSAorTOGAF,aremissingagreatdealofinformationthatisnecessarytocompletemobileapplicationsecurityarchitecturereviews.MASVScanbeusedtofillinthosegapsbyallowingsecurityarchitectstochoosebettercontrolsforissuescommontomobileapps.
AsaReplacementforOff-the-ShelfSecureCodingChecklists
ManyorganizationscanbenefitfromadoptingtheMASVS,bychoosingoneofthetwolevels,orbyforkingMASVSandchangingwhatisrequiredforeachapplication'srisklevelinadomain-specificway.Weencouragethistypeofforkingaslongastraceabilityismaintained,sothatifanapphaspassedrequirement4.1,thismeansthesamethingforforkedcopiesasthestandardevolves.
AsaBasisforSecurityTestingMethodologies
AgoodmobileappsecuritytestingmethodologyshouldcoverallrequirementslistedintheMASVS.TheOWASPMobileSecurityTestingGuide(MSTG)describesblack-boxandwhite-boxtestcasesforeachverificationrequirement.
AsaGuideforAutomatedUnitandIntegrationTests
TheMASVSisdesignedtobehighlytestable,withthesoleexceptionofarchitecturalrequirements.Automatedunit,integrationandacceptancetestingbasedontheMASVSrequirementscanbeintegratedinthecontinuousdevelopmentlifecycle.Thisnotonlyincreasesdevelopersecurityawareness,butalsoimprovestheoverallqualityoftheresultingapps,andreducestheamountoffindingsduringsecuritytestinginthepre-releasephase.
ForSecureDevelopmentTraining
MASVScanalsobeusedtodefinecharacteristicsofsecuremobileapps.Many"securecoding"coursesaresimplyethicalhackingcourseswithalightsmearofcodingtips.Thisdoesnothelpdevelopers.Instead,securedevelopmentcoursescanusetheMASVS,withastrongfocusontheproactivecontrolsdocumentedintheMASVS,ratherthane.g.theTop10codesecurityissues.
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 14
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 Securitycontrolsareneverenforcedonlyontheclientside,butontherespectiveremoteendpoints.
✓ ✓
1.3Ahigh-levelarchitectureforthemobileappandallconnectedremoteserviceshasbeendefinedandsecurityhasbeenaddressedinthatarchitecture.
✓ ✓
1.4 Dataconsideredsensitiveinthecontextofthemobileappisclearlyidentified.
✓ ✓
1.5 Allappcomponentsaredefinedintermsofthebusinessfunctionsand/orsecurityfunctionstheyprovide.
✓
1.6Athreatmodelforthemobileappandtheassociatedremoteserviceshasbeenproducedthatidentifiespotentialthreatsandcountermeasures.
✓
1.7 Allsecuritycontrolshaveacentralizedimplementation. ✓
1.8Thereisanexplicitpolicyforhowcryptographickeys(ifany)aremanaged,andthelifecycleofcryptographickeysisenforced.Ideally,followakeymanagementstandardsuchasNISTSP800-57.
✓
1.9 Amechanismforenforcingupdatesofthemobileappexists. ✓
1.10 Securityisaddressedwithinallpartsofthesoftwaredevelopmentlifecycle.
✓
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 15
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.4 16
V2:DataStorageandPrivacyRequirements
ControlObjective
Theprotectionofsensitivedata,suchasusercredentialsandprivateinformation,isakeyfocusinmobilesecurity.Firstly,sensitivedatamaybeunintentionallyexposedtootherappsrunningonthesamedeviceifoperatingsystemmechanismslikeIPCareusedimproperly.Datamayalsounintentionallyleaktoplatformcloudstorage,backups,orthekeyboardcache.Furthermore,mobiledevicesarelostorstolenmoreeasilycomparedtoothertypesofdevices,soanadversarygainingphysicalaccessisamorelikelyscenario.Inthatcase,additionalprotectionscanbeimplementedtomakeretrievingthesensitivedatamoredifficult.
Notethat,astheMASVSisapp-centric,itdoesnotcoverdevice-levelpoliciessuchasthoseenforcedbyMDMandEDMsolutions.WehoweverencouragetheuseofsuchsolutionsinanEnterprisecontexttofurtherenhancedatasecurity.
DefinitionofSensitiveData
SensitivedatainthecontextoftheMASVSpertainstobothusercredentialsandanyotherdataconsideredsensitiveinthegivencontext,suchas:
• Personallyidentifiableinformation(PII)thatcanbeabusedforidentitytheft:Socialsecuritynumbers,creditcardnumbers,bankaccountnumbers,healthinformation;
• Highlysensitivedatathatwouldleadtoreputationalharmand/orfinancialcostsifcompromised:Contractualinformation,informationcoveredbynon-disclosureagreements,managementinformation;
• Anydatathatmustbeprotectedbylaworforcompliancereasons.
Thevastmajorityofdatadisclosureissuescanbepreventedbyfollowingsimplerules.Mostofthecontrolslistedinthischapteraremandatoryforallverificationlevels.
SecurityVerificationRequirements
# Description L1 L2
2.1 Systemcredentialstoragefacilitiesareusedappropriatelytostoresensitivedata,suchasusercredentialsorcryptographickeys.
✓ ✓
2.2 Nosensitivedataiswrittentoapplicationlogs. ✓ ✓
2.3 Nosensitivedataissharedwiththirdpartiesunlessitisanecessarypartofthearchitecture. ✓ ✓
2.4 Thekeyboardcacheisdisabledontextinputsthatprocesssensitivedata. ✓ ✓
2.5 Theclipboardisdeactivatedontextfieldsthatmaycontainsensitivedata. ✓ ✓
2.6 NosensitivedataisexposedviaIPCmechanisms. ✓ ✓
2.7 Nosensitivedata,suchaspasswordsorpins,isexposedthroughtheuserinterface.
✓ ✓
2.8 Nosensitivedataisincludedinbackupsgeneratedbythemobileoperatingsystem.
✓
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 17
# Description L1 L22.9 Theappremovessensitivedatafromviewswhenbackgrounded. ✓
2.10 Theappdoesnotholdsensitivedatainmemorylongerthannecessary,andmemoryisclearedexplicitlyafteruse.
✓
2.11 Theappenforcesaminimumdevice-access-securitypolicy,suchasrequiringtheusertosetadevicepasscode.
✓
2.12Theappeducatestheuseraboutthetypesofpersonallyidentifiableinformationprocessed,aswellassecuritybestpracticestheusershouldfollowinusingtheapp.
✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
ForAndroid:
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-Testing-Data-Storage.md
ForiOS:
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06d-Testing-Data-Storage.mdhttps://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.4 18
V3:CryptographyRequirements
ControlObjective
Cryptographyisanessentialingredientwhenitcomestoprotectingdatastoredonamobiledevice.Itisalsoacategorywherethingscangohorriblywrong,especiallywhenstandardconventionsarenotfollowed.Thepurposeofthecontrolsinthischapteristoensurethattheverifiedapplicationusescryptographyaccordingtoindustrybestpractices,including:
• Usingprovencryptographiclibraries;• Properlychoosingandconfiguringcryptographicprimitives;• Usingsuitablerandomnumbergeneratorwhereverrandomnessisrequired.
SecurityVerificationRequirements
# Description L1 L2
3.1 Theappdoesnotrelyonsymmetriccryptographywithhardcodedkeysasasolemethodofencryption.
✓ ✓
3.2 Theappusesprovenimplementationsofcryptographicprimitives. ✓ ✓
3.3Theappusescryptographicprimitivesthatareappropriatefortheparticularuse-case,configuredwithparametersthatadheretoindustrybestpractices.
✓ ✓
3.4 Theappdoesnotusecryptographicprotocolsoralgorithmsthatarewidelyconsidereddepreciatedforsecuritypurposes.
✓ ✓
3.5 Theappdoesn'tre-usethesamecryptographickeyformultiplepurposes. ✓ ✓
3.6 Allrandomvaluesaregeneratedusingasufficientlysecurerandomnumbergenerator.
✓ ✓
Refernces
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
ForAndroid:
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05e-Testing-Cryptography.md
ForiOS:
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06e-Testing-Cryptography.md
References
• OWASPMobileTop10:M6-BrokenCryptography• CWE:https://cwe.mitre.org/data/definitions/310.html
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 19
V4:AuthenticationandSessionManagementRequirements
ControlObjective
Inmostcases,userlogintoaremoteserviceisanintegralpartoftheoverallmobileapparchitecture.Eventhoughmostofthelogichappensattheendpoint,MASVSdefinessomebasicrequirementsregardinghowuseraccountsandsessionsaremanaged.Therequirementscanbeeasilyverifiedwithoutaccesstothesourcecodeoftheserviceendpoint.
SecurityVerificationRequirements
# Description L1 L2
4.1Iftheappprovidesusersaccesstoaremoteservice,someformofauthentication,suchasusername/passwordauthentication,isperformedattheremoteendpoint.
✓ ✓
4.2Ifstatefulsessionmanagementisused,theremoteendpointusesrandomlygeneratedsessionidentifierstoauthenticateclientrequestswithoutsendingtheuser'scredentials.
✓ ✓
4.3 Ifstatelesstoken-basedauthenticationisused,theserverprovidesatokenthathasbeensignedusingasecurealgorithm.
✓ ✓
4.4 Theremoteendpointterminatestheexistingsessionwhentheuserlogsout.
✓ ✓
4.5 Apasswordpolicyexistsandisenforcedattheremoteendpoint. ✓ ✓
4.6Theremoteendpointimplementsanexponentialback-off,ortemporarilylockstheuseraccount,whenincorrectauthenticationcredentialsaresubmittedanexcessivenumberoftimes.
✓ ✓
4.7Biometricauthentication,ifany,isnotevent-bound(i.e.usinganAPIthatsimplyreturns"true"or"false").Instead,itisbasedonunlockingthekeychain/keystore.
✓
4.8 Sessionsareinvalidatedattheremoteendpointafterapredefinedperiodofinactivityandaccesstokensexpire.
✓
4.9 Asecondfactorofauthenticationexistsattheremoteendpointandthe2FArequirementisconsistentlyenforced.
✓
4.10 Sensitivetransactionsrequirestep-upauthentication. ✓
4.11Theappinformstheuserofallloginactivitieswiththeiraccount.Usersareableviewalistofdevicesusedtoaccesstheaccount,andtoblockspecificdevices.
✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 20
ForAndroid:
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05f-Testing-Authentication.md
ForiOS:
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06f-Testing-Authentication-and-Session-Management.md
References
• OWASPMobileTop10:M4-InsecureAuthentication,M6-InsecureAuthorization• CWE:https://cwe.mitre.org/data/definitions/287.html
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 21
V5:NetworkCommunicationRequirements
ControlObjective
Thepurposeofthecontrolslistedinthissectionistoensuretheconfidentialityandintegrityofinformationexchangedbetweenthemobileappandremoteserviceendpoints.Attheveryleast,amobileappmustsetupasecure,encryptedchannelfornetworkcommunicationusingtheTLSprotocolwithappropriatesettings.Level2listsadditionaldefense-in-depthmeasuresuchasSSLpinning.
SecurityVerificationRequirements
# Description L1 L2
5.1 DataisencryptedonthenetworkusingTLS.Thesecurechannelisusedconsistentlythroughouttheapp. ✓ ✓
5.2TheTLSsettingsareinlinewithcurrentbestpractices,orascloseaspossibleifthemobileoperatingsystemdoesnotsupporttherecommendedstandards.
✓ ✓
5.3TheappverifiestheX.509certificateoftheremoteendpointwhenthesecurechannelisestablished.OnlycertificatessignedbyatrustedCAareaccepted.
✓ ✓
5.4
Theappeitherusesitsowncertificatestore,orpinstheendpointcertificateorpublickey,andsubsequentlydoesnotestablishconnectionswithendpointsthatofferadifferentcertificateorkey,evenifsignedbyatrustedCA.
✓
5.5 Theappdoesn'trelyonasingleinsecurecommunicationchannel(emailorSMS)forcriticaloperations,suchasenrollmentsandaccountrecovery.
✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
ForAndroid:https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05g-Testing-Network-Communication.mdForiOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06g-Testing-Network-Communication.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.4 22
V6:PlatformInteractionRequirements
ControlObjective
ThecontrolsinthisgroupensurethattheappusesplatformAPIsandstandardcomponentsinasecuremanner.Additionally,thecontrolscovercommunicationbetweenapps(IPC).
SecurityVerificationRequirements
# Description L1 L2
6.1 Theapponlyrequeststheminimumsetofpermissionsnecessary. ✓ ✓
6.2Allinputsfromexternalsourcesandtheuserarevalidatedandifnecessarysanitized.ThisincludesdatareceivedviatheUI,IPCmechanismssuchasintents,customURLs,andnetworksources.
✓ ✓
6.3 TheappdoesnotexportsensitivefunctionalityviacustomURLschemes,unlessthesemechanismsareproperlyprotected. ✓ ✓
6.4 TheappdoesnotexportsensitivefunctionalitythroughIPCfacilities,unlessthesemechanismsareproperlyprotected.
✓ ✓
6.5 JavaScriptisdisabledinWebViewsunlessexplicitlyrequired. ✓ ✓
6.6WebViews are configured to allow only the minimum set of protocolhandlersrequired(ideally,onlyhttpsissupported).Potentiallydangeroushandlers,suchasfile,telandapp-id,aredisabled.
✓ ✓
6.7 Ifnativemethodsof theappareexposedtoaWebView,verify that theWebViewonlyrendersJavaScriptcontainedwithintheapppackage. ✓ ✓
6.8 Objectserialization,ifany,isimplementedusingsafeserializationAPIs. ✓ ✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
ForAndroid:https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05h-Testing-Platform-Interaction.mdForiOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06h-Testing-Platform-Interaction.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.4 23
V7:CodeQualityandBuildSettingRequirements
ControlObjective
Thegoalofthiscontrolistoensurethatbasicsecuritycodingpracticesarefollowedindevelopingtheapp,andthat"free"securityfeaturesofferedbythecompilerareactivated.
SecurityVerificationRequirements
# Description L1 L2
7.1 Theappissignedandprovisionedwithvalidcertificate. ✓ ✓
7.2 Theapphasbeenbuiltinreleasemode,withsettingsappropriateforareleasebuild(e.g.non-debuggable). ✓ ✓
7.3 Debuggingsymbolshavebeenremovedfromnativebinaries. ✓ ✓
7.4 Debuggingcodehasbeenremoved,andtheappdoesnotlogverboseerrorsordebuggingmessages.
✓ ✓
7.5 Allthird-partycomponentsusedbythemobileapp,suchaslibrariesandframeworks,areidentified,andcheckedforknownvulnerabilities.
✓ ✓
7.6 Theappcatchesandhandlespossibleexceptions. ✓ ✓
7.7 Errorhandlinglogicinsecuritycontrolsdeniesaccessbydefault. ✓ ✓
7.8 Inunmanagedcode,memoryisallocated,freedandusedsecurely. ✓ ✓
7.9Freesecurityfeaturesofferedbythetoolchain,suchasbyte-codeminification,stackprotection,PIEsupportandautomaticreferencecounting,areactivated.
✓ ✓
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
ForAndroid:https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.mdForiOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06i-Testing-Code-Quality-and-Build-Settings.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.4 24
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,atargetmustbesetthatspecifiesthelevelofprotectiontheprotectionschemeismeanttoprovide(e.g.,causeaneffortofatleast20man-daysforaskilledreverseengineertoreachdefinedgoalXusingstate-of-the-arttoolsandprocesses).
2. Theprotectionschemeshouldbeverifiedusingmanualresiliencytestingbyasubjectmatterexpert(seealsothe"reverseengineering"and"assessingsoftwareprotections"chaptersintheMobileSecurityTestingGuide).
ImpedeDynamicAnalysisandTampering
# Description R
8.1 Theappdetects,andrespondsto,thepresenceofarootedorjailbrokendeviceeitherbyalertingtheuserorterminatingtheapp. ✓
8.2 Theapppreventsdebuggingand/ordetects,andrespondsto,adebuggerbeingattached.Allavailabledebuggingprotocolsmustbecovered. ✓
8.3 Theappdetects,andrespondsto,tamperingwithexecutablefilesandcriticaldatawithinitsownsandbox. ✓
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 25
# Description R
8.4 Theappdetects,andrespondsto,thepresenceofwidelyusedreverseengineeringtoolsandframeworksonthedevice.
✓
8.5 Theappdetects,andrespondsto,beingruninanemulator. ✓
8.6 Theappdetects,andrespondsto,tamperingthecodeanddatainitsownmemoryspace. ✓
8.7Theappimplementsmultiplemechanismsineachdefensivecategory(8.1to8.6).Notethatresiliencyscaleswiththeamount,diversityoftheoriginalityofthemechanismsused.
✓
8.8 Thedetectionmechanismstriggerresponsesofdifferenttypes,includingdelayedandstealthyresponses. ✓
8.9
Allexecutablefilesandlibrariesbelongingtotheappareeitherencryptedonthefileleveland/orimportantcodeanddatasegmentsinsidetheexecutablesareencryptedorpacked.Trivialstaticanalysisdoesnotrevealimportantcodeordata.
✓
8.10 Obfuscationisappliedtoprogrammaticdefenses,whichinturnimpedede-obfuscationviadynamicanalysis. ✓
DeviceBinding
# Description R8.11 Theappimplementsa'devicebinding'functionalityusingadevice
fingerprintderivedfrommultiplepropertiesuniquetothedevice.✓
ImpedeComprehension
# Description R
8.12
Allexecutablefilesandlibrariesbelongingtotheappareeitherencryptedonthefileleveland/orimportantcodeanddatasegmentsinsidetheexecutablesareencryptedorpacked.Trivialstaticanalysisdoesnotrevealimportantcodeordata.
✓
8.13
Ifthegoaloftheobfuscationistoprotectsensitivecomputations,anobfuscationschemeisusedthatisbothappropriateforthetaskathandandrobustagainstmanualandautomatedde-obfuscationmethods,consideringcurrentlypublishedresearch.Theeffectivenessoftheobfuscationschememustbeverifiedthroughmanualtesting.Notethathardware-basedisolationfeaturesarepreferredoverobfuscationwheneverpossible.
✓
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 26
VerificationProcesses
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
ForAndroid:https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.mdForiOS:https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md
References
• OWASPMobileTop10:M8-CodeTampering,M9-ReverseEngineering• OWASPReverseEngineeringThreats-
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.4 27
AppendixA:Glossary• 2FA–Two-factorauthentication(2FA)addsasecondlevelofauthenticationtoan
accountlog-in.• AddressSpaceLayoutRandomization(ASLR)–Atechniquetomakeexploiting
memorycorruptionbugsmoredifficult.• ApplicationSecurity–Application-levelsecurityfocusesontheanalysisofcomponents
thatcomprisetheapplicationlayeroftheOpenSystemsInterconnectionReferenceModel(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.4 28
• 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.4 29
• URI/URL/URLfragments–AUniformResourceIdentifierisastringofcharactersusedtoidentifyanameorawebresource.AUniformResourceLocatorisoftenusedasareferencetoaresource.
• Useracceptancetesting(UAT)–Traditionallyatestenvironmentthatbehavesliketheproductionenvironmentwhereallsoftwaretestingisperformedbeforegoinglive.
• Verifier–ThepersonorteamthatisreviewinganapplicationagainsttheOWASPASVSrequirements.
• Whitelist–Alistofpermitteddataoroperations,forexamplealistofcharactersthatareallowedtoperforminputvalidation.
• X.509Certificate–AnX.509certificateisadigitalcertificatethatusesthewidelyacceptedinternationalX.509publickeyinfrastructure(PKI)standardtoverifythatapublickeybelongstotheuser,computerorserviceidentitycontainedwithinthecertificate.
OWASPMobileApplicationSecurityVerificationStandardv0.9.4 30
AppendixB:ReferencesThefollowingOWASPprojectsaremostlikelytobeusefultousers/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