View
4
Download
0
Category
Preview:
Citation preview
OWASP Mobile Application Security Verification Standard v1.0 3
FOREWORDBYBERNHARDMUELLER,OWASPMOBILEPROJECT 5
FRONTISPIECE 7
ABOUTTHESTANDARD 7COPYRIGHTANDLICENSE 7
THEMOBILEAPPLICATIONSECURITYVERIFICATIONSTANDARD 8
MOBILEAPPSECMODEL 8DOCUMENTSTRUCTURE 9VERIFICATIONLEVELSINDETAIL 9RECOMMENDEDUSE 9
ASSESSMENTANDCERTIFICATION 12
OWASP'SSTANCEONMASVSCERTIFICATIONSANDTRUSTMARKS 12GUIDANCEFORCERTIFYINGMOBILEAPPS 12USINGTHEOWASPMOBILESECURITYTESTINGGUIDE(MSTG) 12THEROLEOFAUTOMATEDSECURITYTESTINGTOOLS 13OTHERUSES 13ASDETAILEDSECURITYARCHITECTUREGUIDANCE 13ASAREPLACEMENTFOROFF-THE-SHELFSECURECODINGCHECKLISTS 13ASABASISFORSECURITYTESTINGMETHODOLOGIES 13ASAGUIDEFORAUTOMATEDUNITANDINTEGRATIONTESTS 13FORSECUREDEVELOPMENTTRAINING 13
V1:ARCHITECTURE,DESIGNANDTHREATMODELINGREQUIREMENTS 14
CONTROLOBJECTIVE 14SECURITYVERIFICATIONREQUIREMENTS 14REFERENCES 14
V2:DATASTORAGEANDPRIVACYREQUIREMENTS 16
CONTROLOBJECTIVE 16DEFINITIONOFSENSITIVEDATA 16SECURITYVERIFICATIONREQUIREMENTS 16REFERENCES 17
V3:CRYPTOGRAPHYREQUIREMENTS 18
CONTROLOBJECTIVE 18SECURITYVERIFICATIONREQUIREMENTS 18REFERENCES 18
V4:AUTHENTICATIONANDSESSIONMANAGEMENTREQUIREMENTS 19
CONTROLOBJECTIVE 19
OWASP Mobile Application Security Verification Standard v1.0 4
SECURITYVERIFICATIONREQUIREMENTS 19REFERENCES 19
V5:NETWORKCOMMUNICATIONREQUIREMENTS 21
CONTROLOBJECTIVE 21SECURITYVERIFICATIONREQUIREMENTS 21REFERENCES 21
V6:PLATFORMINTERACTIONREQUIREMENTS 22
CONTROLOBJECTIVE 22SECURITYVERIFICATIONREQUIREMENTS 22REFERENCES 22
V7:CODEQUALITYANDBUILDSETTINGREQUIREMENTS 23
CONTROLOBJECTIVE 23SECURITYVERIFICATIONREQUIREMENTS 23REFERENCES 23
V8:RESILIENCEREQUIREMENTS 24
CONTROLOBJECTIVE 24IMPEDEDYNAMICANALYSISANDTAMPERING 24DEVICEBINDING 25IMPEDECOMPREHENSION 25REFERENCES 25
APPENDIXA:GLOSSARY 27
APPENDIXB:REFERENCES 30
OWASP Mobile Application Security Verification Standard v1.0 5
ForewordbyBernhardMueller,OWASPMobileProject
Technologicalrevolutionscanhappenquickly.Lessthanadecadeago,smartphoneswereclunkydeviceswithlittlekeyboards-expensiveplaythingsfortech-savvybusinessusers.Today,
smartphonesareanessentialpartofourlives.We'vecometorelyonthemforinformation,navigationandcommunication,andtheyareubiquitousbothinbusinessandinoursociallives.
Everynewtechnologyintroducesnewsecurityrisks,andkeepingupwiththosechangesisoneofthemainchallengesthesecurityindustryfaces.Thedefensivesideisalwaysafewstepsbehind.For
example,thedefaultreflexformanywastoapplyoldwaysofdoingthings:Smartphonesarelike
smallcomputers,andmobileappsarejustlikeclassicsoftware,sosurelythesecurityrequirementsaresimilar?Butitdoesn'tworklikethat.SmartphoneoperatingsystemsaredifferentfromDesktop
operatingsystems,andmobileappsaredifferentfromwebapps.Forexample,theclassicalmethod
ofsignature-basedvirusscanningdoesn'tmakesenseinmodernmobileOSenvironments:Notonly
isitincompatiblewiththemobileappdistributionmodel,it'salsotechnicallyimpossibleduetosandboxingrestrictions.Also,somevulnerabilityclasses,suchasbufferoverflowsandXSSissues,
arelessrelevantinthecontextofrun-of-the-millmobileappsthanin,say,Desktopappsandweb
applications(exceptionsapply).
Overtime,ourindustryhasgottenabettergriponthemobilethreatlandscape.Asitturnsout,
mobilesecurityisallaboutdataprotection:Appsstoreourpersonalinformation,pictures,
recordings,notes,accountdata,businessinformation,locationandmuchmore.Theyactasclientsthatconnectustoservicesweuseonadailybasis,andascommunicationshubsthatprocesseseach
andeverymessageweexchangewithothers.Compromiseaperson'ssmartphoneandyouget
unfilteredaccesstothatperson'slife.Whenweconsiderthatmobiledevicesaremorereadilylost
orstolenandmobilemalwareisontherise,theneedfordataprotectionbecomesevenmoreapparent.
Asecuritystandardformobileappsmustthereforefocusonhowmobileappshandle,storeand
protectsensitiveinformation.EventhoughmodernmobileoperatingsystemslikeiOSandAndroid
offergoodAPIsforsecuredatastorageandcommunication,thosehavetobeimplementedand
usedcorrectlyinordertobeeffective.Datastorage,inter-appcommunication,properusageofcryptographicAPIsandsecurenetworkcommunicationareonlysomeoftheaspectsthatrequire
carefulconsideration.
Animportantquestioninneedofindustryconsensusishowfarexactlyoneshouldgoinprotecting
theconfidentialityandintegrityofdata.Forexample,mostofuswouldagreethatamobileapp
shouldverifytheservercertificateinaTLSexchange.ButwhataboutSSLcertificatepinning?Does
notdoingitresultinavulnerability?Shouldthisbearequirementifanapphandlessensitivedata,orisitmaybeevencounter-productive?DoweneedtoencryptdatastoredinSQLitedatabases,
eventhoughtheOSsandboxestheapp?Whatisappropriateforoneappmightbeunrealisticfor
another.TheMASVSisanattempttostandardizetheserequirementsusingverificationlevelsthat
fitdifferentthreatscenarios.
Furthermore,theappearanceofrootmalwareandremoteadministrationtoolshascreatedawarenessofthefactthatmobileoperatingsystemsthemselveshaveexploitableflaws,so
containerizationstrategiesareincreasinglyusedtoaffordadditionalprotectiontosensitivedata
andpreventclient-sidetampering.Thisiswherethingsgetcomplicated.Hardware-backedsecurity
featuresandOS-levelcontainerizationsolutions,suchasAndroidforWorkandSamsungKnox,doexist,buttheyaren'tconsistentlyavailableacrossdifferentdevices.Asabandaid,itispossibleto
OWASP Mobile Application Security Verification Standard v1.0 6
implementsoftware-basedprotectionmeasures-butunfortunately,therearenostandardsor
testingprocessesforverifyingthesekindsofprotections.
Asaresult,mobileappsecuritytestingreportsareallovertheplace:Forexample,sometesters
reportalackofobfuscationorrootdetectioninanAndroidappas“securityflaw”.Ontheother
hand,measureslikestringencryption,debuggerdetectionorcontrolflowobfuscationaren'tconsideredmandatory.However,thisbinarywayoflookingatthingsdoesn'tmakesensebecause
resiliencyisnotabinaryproposition:Itdependsontheparticularclient-sidethreatsoneaimsto
defendagainst.Softwareprotectionsarenotuseless,buttheycanultimatelybebypassed,sothey
mustneverbeusedasareplacementforsecuritycontrols.
TheoverallgoaloftheMASVSistoofferabaselineformobileapplicationsecurity(MASVS-L1),
whilealsoallowingfortheinclusionofdefense-in-depthmeasures(MASVS-L2)andprotectionsagainstclient-sidethreats(MASVS-R).TheMASVSismeanttoachievethefollowing:
• Providerequirementsforsoftwarearchitectsanddevelopersseekingtodevelopsecuremobileapplications;
• Offeranindustrystandardthatcanbetestedagainstinmobileappsecurityreviews;
• Clarifytheroleofsoftwareprotectionmechanismsinmobilesecurityandproviderequirementstoverifytheireffectiveness;
• Providespecificrecommendationsastowhatlevelofsecurityisrecommendedfordifferentuse-cases.
Weareawarethat100%industryconsensusisimpossibletoachieve.Nevertheless,wehopethattheMASVSisusefulinprovidingguidancethroughoutallphasesofmobileappdevelopmentand
testing.Asanopensourcestandard,theMASVSwillevolveovertime,andwewelcomeany
contributionsandsuggestions.
OWASP Mobile Application Security Verification Standard v1.0 7
Frontispiece
AbouttheStandard
WelcometotheMobileApplicationSecurityVerificationStandard(MASVS)1.0.TheMASVSisacommunityefforttoestablishaframeworkofsecurityrequirementsneededtodesign,developand
testsecuremobileappsoniOSandAndroid.
TheMASVSisaculminationofcommunityeffortandindustryfeedback.Weexpectthisstandardto
evolveovertimeandwelcomefeedbackfromthecommunity.ThebestwaytogetincontactwithusisviatheOWASPMobileProjectSlackchannel:
https://owasp.slack.com/messages/project-mobile_omtg/details/
AccountscanbecreatedatthefollowingURL:
http://owasp.herokuapp.com/.
CopyrightandLicense
Copyright©2018TheOWASPFoundation.ThisdocumentisreleasedundertheCreativeCommonsAttributionShareAlike3.0license.Foranyreuseordistribution,youmustmake
cleartoothersthelicensetermsofthiswork.
ProjectLeads LeadAuthors ContributorsandReviewers
BernhardMueller,SvenSchleier
BernhardMueller AbdessamadTemmar,AbhinavSejpal,AlexanderAntukh,AnantShrivastava,BenGardiner,FrancescoStillavato,JeroenWillemsen,Nikhil Soni,PrabhantSingh,RobertoMartelloni,StephenCorbiaux,StephenReda,SjoerdLangkemper,StefaanSeys,SvenSchleier,YogeshSharma
ThisdocumentstartedasaforkoftheOWASPApplicationSecurityVerificationStandard(ASVS)writtenbyJimManico.
OWASP Mobile Application Security Verification Standard v1.0 8
TheMobileApplicationSecurityVerificationStandard
TheMASVScanbeusedtoestablishalevelofconfidenceinthesecurityofmobileapps.Therequirementsweredevelopedwiththefollowingobjectivesinmind:
• Useasametric-Toprovideasecuritystandardagainstwhichexistingmobileappscanbe
comparedbydevelopersandapplicationowners;
• Useasguidance-Toprovideguidanceduringallphasesofmobileappdevelopmentand
testing;
• Useduringprocurement-Toprovideabaselineformobileappsecurityverification.
MobileAppSecModel
TheMASVSdefinestwostrictsecurityverificationlevels(L1andL2),aswellasetofreverseengineeringresiliencyrequirements(MASVS-R)thatisflexible,i.e.adaptabletoanapp-specific
threatmodel.MASVS-L1andMASVS-L2containgenericsecurityrequirementsandare
recommendedforallmobileapps(L1)andappsthathandlehighlysensitivedata(L2).MASVS-Rcoversadditionalprotectivecontrolsthatcanbeappliedifpreventingclient-sidethreatsisadesign
goal.
FulfillingtherequirementsinMASVS-L1resultsinasecureappthatfollowssecuritybestpractices
anddoesn'tsufferfromcommonvulnerabilities.MASVS-L2addsadditionaldefense-in-depth
controlssuchasSSLpinning,resultinginanappthatisresilientagainstmoresophisticatedattacks-assumingthesecuritycontrolsofthemobileoperatingsystemareintactandtheenduserisnot
viewedasapotentialadversary.Fulfillingall,orsubsetsof,thesoftwareprotectionrequirementsin
MASVS-Rhelpsimpedespecificclient-sidethreatswheretheenduserismaliciousand/orthe
mobileOSiscompromised.
NotethatsoftwareprotectioncontrolslistedinMASVS-RanddescribedintheOWASPMobileTestingGuidecanultimatelybebypassedandmustneverbeusedasareplacementforsecuritycontrols.Instead,theyareintendedtoaddthreat-specific,additionalprotectivecontrolstoappsthatalsofulfiltheMASVSrequirementsinMASVSL1orL2.
Figure1:SecurityVerificationLevels.MASVS-L1providesasolidsecuritybaselinethatisappropriateformostmobileapps.
MASVS-L2addsdefense-in-depth-controls.MASVS-Rrepresentsanoptionalprotectivelayerforimpedingreverseengineeringandtampering.
OWASP Mobile Application Security Verification Standard v1.0 9
DocumentStructure
ThefirstpartoftheMASVScontainsadescriptionofthesecuritymodelandavailableverification
levels,followedbyrecommendationsonhowtousethestandardinpractice.Thedetailedsecurityrequirements,alongwithamappingtotheverificationlevels,arelistedinthesecondpart.The
requirementshavebeengroupedintoeightcategories(V1toV8)basedontechnicalobjective/
scope.ThefollowingnomenclatureisusedthroughouttheMASVSandMSTG:
• Requirementcategory:MASVS-Vx,e.g.MASVS-V2:DataStorageandPrivacy• Requirement:MASVS-Vx.y,e.g.MASVS-V2.2:"Nosensitivedataiswrittentoapplicationlogs."
VerificationLevelsinDetail
MASVS-L1:StandardSecurity
AmobileappthatachievesMASVS-L1adherestomobileapplicationsecuritybestpractices.Itfulfillsbasicrequirementsintermsofcodequality,handlingofsensitivedata,andinteractionwith
themobileenvironment.Atestingprocessmustbeinplacetoverifythesecuritycontrols.Thislevelisappropriateforallmobileapplications.
MASVS-L2:Defense-in-Depth
MASVS-L2introducesadvancedsecuritycontrolsthatgobeyondthestandardrequirements.TofulfilL2,athreatmodelmustexist,andsecuritymustbeanintegralpartoftheapp'sarchitecture
anddesign.Thislevelisappropriateforapplicationsthathandlesensitivedata,suchasmobile
banking.
MASVS-R:ResiliencyAgainstReverseEngineeringandTampering
Theapphasstate-of-the-artsecurity,andisalsoresilientagainstspecific,clearlydefinedclient-sideattacks,suchastampering,modding,orreverseengineeringtoextractsensitivecodeordata.Such
anappeitherleverageshardwaresecurityfeaturesorsufficientlystrongandverifiablesoftware
protectiontechniques.MASVS-Risapplicabletoappsthathandlehighlysensitivedataandmayserveasameansofprotectingintellectualpropertyortamper-proofinganapp.
RecommendedUse
AppscanbeverifiedagainstMASVSL1orL2basedonpriorriskassessmentandoveralllevelofsecurityrequired.L1isapplicabletoallmobileapps,whileL2isgenerallyrecommendedforapps
thathandlemoresensitivedataand/orfunctionality.MASVS-R(orpartsofit)canbeappliedto
verifyresiliencyagainstspecificthreats,suchasrepackagingorextractionofsensitivedata,inadditiontopropersecurityverification.
Insummary,Thefollowingverificationtypesareavailable:
• MASVS-L1
• MASVS-L1+R
• MASVS-L2
• MASVS-L2+R
OWASP Mobile Application Security Verification Standard v1.0 10
Thedifferentcombinationsreflectdifferentgradesofsecurityandresiliency.Thegoalistoallow
forflexibility:Forexample,amobilegamemightnotwarrantaddingMASVS-L2securitycontrols
suchas2-factorauthenticationforusabilityreasons,buthaveastrongbusinessneedfortamperingprevention.
WhatVerificationTypetoChoose
ImplementingtherequirementsofMASVSL2increasessecurity,whileatthesametimeincreasingcostofdevelopmentandpotentiallyworseningtheenduserexperience(theclassicaltrade-off).In
general,L2shouldbeusedforappswheneveritmakessensefromariskvs.costperspective(i.e.,
wherethepotentiallosscausedbyacompromiseconfidentialityorintegrityishigherthanthecostincurredbytheadditionalsecuritycontrols).Ariskassessmentshouldbethefirststepbefore
applyingtheMASVS.
Examples
MASVS-L1• Allmobileapps.MASVS-L1listssecuritybestpracticesthatcanbefollowedwithareasonable
impactondevelopmentcostanduserexperience.ApplytherequirementsinMASVS-L1for
anyappthatdon'tqualifyforoneofthehigherlevels.
MASVS-L2• Health-CareIndustry:Mobileappsthatstorepersonallyidentifiableinformationthat
canbeusedforidentitytheft,fraudulentpayments,oravarietyoffraudschemes.FortheUShealthcaresector,complianceconsiderationsincludetheHealthInsurancePortabilityandAccountabilityAct(HIPAA)Privacy,Security,BreachNotificationRulesandPatientSafetyRule.
• FinancialIndustry:Appsthatenableaccesstohighlysensitiveinformationlikecreditcardnumbers,personalinformation,orallowtheusertomovefunds.Theseappswarrantadditionalsecuritycontrolstopreventfraud.FinancialappsneedtoensurecompliancetothePaymentCardIndustryDataSecurityStandard(PCIDSS),GrammLeechBlileyActandSarbanes-OxleyAct(SOX).
MASVSL1+R• MobileappswhereIPprotectionisabusinessgoal.Theresiliencycontrolslistedin
MASVS-Rcanbeusedtoincreasetheeffortneededtoobtaintheoriginalsourcecodeandtoimpedetampering/cracking.
• GamingIndustry:Gameswithanessentialneedtopreventmoddingandcheating,suchascompetitiveonlinegames.Cheatingisanimportantissueinonlinegames,asalargeamountofcheatersleadstoadisgruntledtheplayerbaseandcanultimatelycauseagametofail.MASVS-Rprovidesbasicanti-tamperingcontrolstohelpincreasetheeffortforcheaters.
OWASP Mobile Application Security Verification Standard v1.0 11
MASVSL2+R• FinancialIndustry:Onlinebankingappsthatallowtheusertomovefunds,where
techniquescodeinjectionandinstrumentationoncompromiseddevicesposearisk.Inthiscase,controlsfromMASVS-Rcanbeusedtoimpedetampering,raisingthebarformalwareauthors.
• Allmobileappsthat,bydesign,needtostoresensitivedataonthemobiledevice,andatthesametimemustsupportawiderangeofdevicesandoperatingsystemversions.Inthiscase,resiliencycontrolscanbeusedasandefense-in-depthmeasuretoincreasetheeffortforattackersaimingtoextractthesensitivedata.
OWASP Mobile Application Security Verification Standard v1.0 12
AssessmentandCertification
OWASP'sStanceonMASVSCertificationsandTrustMarks
OWASP,asavendor-neutralnot-for-profitorganization,doesnotcertifyanyvendors,verifiersorsoftware.
Allsuchassuranceassertions,trustmarks,orcertificationsarenotofficiallyvetted,registered,or
certifiedbyOWASP,soanorganizationrelyinguponsuchaviewneedstobecautiousofthetrust
placedinanythirdpartyortrustmarkclaimingASVScertification.
Thisshouldnotinhibitorganizationsfromofferingsuchassuranceservices,aslongastheydonot
claimofficialOWASPcertification.
GuidanceforCertifyingMobileApps
TherecommendedwayofverifyingcomplianceofamobileappwiththeMASVSisbyperformingan
"openbook"review,meaningthatthetestersaregrantedaccesstokeyresourcessuchasarchitectsanddevelopersoftheapp,projectdocumentation,sourcecode,andauthenticatedaccessto
endpoints,includingaccesstoatleastoneuseraccountforeachrole.
ItisimportanttonotethattheMASVSonlycoverssecurityofthe(client-side)mobileappandthe
networkcommunicationbetweentheappanditsremoteendpoint(s),aswellasafewbasicand
genericrequirementsrelatedtouserauthenticationandsessionmanagement.Itdoesnotcontainspecificrequirementsfortheremoteservices(e.g.webservices)associatedwiththeapp,safefora
limitedsetofgenericrequirementspertainingtoauthenticationandsessionmanagement.
However,MASVSV1specifiesthatremoteservicesmustbecoveredbytheoverallthreatmodel,
andbeverifiedagainstappropriatestandards,suchastheOWASPASVS.
Acertifyingorganizationmustincludeinanyreportthescopeoftheverification(particularlyifa
keycomponentisoutofscope),asummaryofverificationfindings,includingpassedandfailedtests,withclearindicationsofhowtoresolvethefailedtests.Keepingdetailedworkpapers,
screenshotsormovies,scriptstoreliablyandrepeatedlyexploitanissue,andelectronicrecordsof
testing,suchasinterceptingproxylogsandassociatednotessuchasacleanuplist,isconsidered
standardindustrypractice.Itisnotsufficienttosimplyrunatoolandreportonthefailures;thisdoesnotprovidesufficientevidencethatallissuesatacertifyinglevelhavebeentestedandtested
thoroughly.Incaseofdispute,thereshouldbesufficientsupportiveevidencetodemonstratethat
everyverifiedrequirementhasindeedbeentested.
UsingtheOWASPMobileSecurityTestingGuide(MSTG)
TheOWASPMSTGisamanualfortestingthesecurityofmobileapps.Itdescribesthetechnical
processesforverifyingtherequirementslistedintheMASVS.TheMSTGincludesalistoftestcases,eachofwhichmaptoarequirementintheMASVS.WhiletheMASVSrequirementsarehigh-level
andgeneric,theMSTGprovidesin-depthrecommendationsandtestingproceduresonaper-
mobile-OSbasis.
OWASP Mobile Application Security Verification Standard v1.0 13
TheRoleofAutomatedSecurityTestingTools
Theuseofsourcecodescannersandblack-boxtestingtoolsisencouragedinordertoincrease
efficiencywheneverpossible.ItishowevernotpossibletocompleteMASVSverificationusingautomatedtoolsalone:Everymobileappisdifferent,andunderstandingtheoverallarchitecture,
businesslogic,andtechnicalpitfallsofthespecifictechnologiesandframeworksbeingused,isa
mandatoryrequirementtoverifysecurityoftheapp.
OtherUses
AsDetailedSecurityArchitectureGuidance
OneofthemorecommonusesfortheMobileApplicationSecurityVerificationStandardisasaresourceforsecurityarchitects.Thetwomajorsecurityarchitectureframeworks,SABSAorTOGAF,
aremissingagreatdealofinformationthatisnecessarytocompletemobileapplicationsecurityarchitecturereviews.MASVScanbeusedtofillinthosegapsbyallowingsecurityarchitectsto
choosebettercontrolsforissuescommontomobileapps.
AsaReplacementforOff-the-shelfSecureCodingChecklists
ManyorganizationscanbenefitfromadoptingtheMASVS,bychoosingoneofthetwolevels,orbyforkingMASVSandchangingwhatisrequiredforeachapplication'srisklevelinadomain-specific
way.Weencouragethistypeofforkingaslongastraceabilityismaintained,sothatifanapphaspassedrequirement4.1,thismeansthesamethingforforkedcopiesasthestandardevolves.
AsaBasisforSecurityTestingMethodologies
AgoodmobileappsecuritytestingmethodologyshouldcoverallrequirementslistedintheMASVS.TheOWASPMobileSecurityTestingGuide(MSTG)describesblack-boxandwhite-boxtestcasesfor
eachverificationrequirement.
AsaGuideforAutomatedUnitandIntegrationTests
TheMASVSisdesignedtobehighlytestable,withthesoleexceptionofarchitecturalrequirements.
Automatedunit,integrationandacceptancetestingbasedontheMASVSrequirementscanbeintegratedinthecontinuousdevelopmentlifecycle.Thisnotonlyincreasesdevelopersecurity
awareness,butalsoimprovestheoverallqualityoftheresultingapps,andreducestheamountof
findingsduringsecuritytestinginthepre-releasephase.
ForSecureDevelopmentTraining
MASVScanalsobeusedtodefinecharacteristicsofsecuremobileapps.Many"securecoding"coursesaresimplyethicalhackingcourseswithalightsmearofcodingtips.Thisdoesnothelpdevelopers.Instead,securedevelopmentcoursescanusetheMASVS,withastrongfocusonthe
proactivecontrolsdocumentedintheMASVS,ratherthane.g.theTop10codesecurityissues.
OWASP Mobile Application Security Verification Standard v1.0 14
V1:Architecture,DesignandThreatModelingRequirements
ControlObjective
Inaperfectworld,securitywouldbeconsideredthroughoutallphasesofdevelopment.Inrealityhowever,securityisoftenonlyaconsiderationatalatestageintheSDLC.Besidesthetechnical
controls,theMASVSrequiresprocessestobeinplacethatensurethatthesecurityhasbeenexplicitlyaddressedwhenplanningthearchitectureofthemobileapp,andthatthefunctionaland
securityrolesofallcomponentsareknown.Sincemostmobileapplicationsactasclientstoremote
services,itmustbeensuredthatappropriatesecuritystandardsarealsoappliedtothoseservices-
testingthemobileappinisolationisnotsufficient.
Thecategory“V1”listsrequirementspertainingtoarchitectureanddesignoftheapp.Assuch,this
istheonlycategorythatdoesnotmaptotechnicaltestcasesintheOWASPMobileTestingGuide.Tocovertopicssuchasthreatmodelling,secureSDLC,keymanagement,usersoftheMASVSshould
consulttherespectiveOWASPprojectsand/orotherstandardssuchastheoneslinkedbelow.
SecurityVerificationRequirements
TherequirementsforMASVS-L1andMASVS-L2arelistedbelow.
# Description L1 L2
1.1 Allappcomponentsareidentifiedandknowntobeneeded. � �
1.2 Securitycontrolsareneverenforcedonlyontheclientside,butontherespectiveremoteendpoints.
� �
1.3 Ahigh-levelarchitectureforthemobileappandallconnectedremoteservices
hasbeendefinedandsecurityhasbeenaddressedinthatarchitecture.� �
1.4 Dataconsideredsensitiveinthecontextofthemobileappisclearlyidentified. � �
1.5 Allappcomponentsaredefinedintermsofthebusinessfunctionsand/or
securityfunctionstheyprovide.
�
1.6 Athreatmodelforthemobileappandtheassociatedremoteserviceshasbeenproducedthatidentifiespotentialthreatsandcountermeasures.
�
1.7 Allsecuritycontrolshaveacentralizedimplementation. �
1.8 Thereisanexplicitpolicyforhowcryptographickeys(ifany)aremanaged,andthelifecycleofcryptographickeysisenforced.Ideally,followakeymanagement
standardsuchasNISTSP800-57.
�
1.9 Amechanismforenforcingupdatesofthemobileappexists. �
1.10 Securityisaddressedwithinallpartsofthesoftwaredevelopmentlifecycle. �
References
Formoreinformation,seealso:
• OWASPMobileTop10:M10-ExtraneousFunctionality:
https://www.owasp.org/index.php/Mobile_Top_10_2016-M10-Extraneous_Functionality
OWASP Mobile Application Security Verification Standard v1.0 15
• 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
OWASP Mobile Application Security Verification Standard v1.0 16
V2:DataStorageandPrivacyRequirements
ControlObjective
Theprotectionofsensitivedata,suchasusercredentialsandprivateinformation,isakeyfocusinmobilesecurity.Firstly,sensitivedatacanbeunintentionallyexposedtootherappsrunningonthe
samedeviceifoperatingsystemmechanismslikeIPCareusedimproperly.Datamayalsounintentionallyleaktocloudstorage,backups,orthekeyboardcache.Additionally,mobiledevices
canbelostorstolenmoreeasilycomparedtoothertypesofdevices,soanadversarygaining
physicalaccessisamorelikelyscenario.Inthatcase,additionalprotectionscanbeimplementedto
makeretrievingthesensitivedatamoredifficult.
Notethat,astheMASVSisapp-centric,itdoesnotcoverdevice-levelpoliciessuchasthoseenforced
byMDMsolutions.WeencouragetheuseofsuchpoliciesinanEnterprisecontexttofurtherenhancedatasecurity.
DefinitionofSensitiveData
SensitivedatainthecontextoftheMASVSpertainstobothusercredentialsandanyotherdataconsideredsensitiveintheparticularcontext,suchas:
• Personallyidentifiableinformation(PII)thatcanbeabusedforidentitytheft:Socialsecurity
numbers,creditcardnumbers,bankaccountnumbers,healthinformation;
• Highlysensitivedatathatwouldleadtoreputationalharmand/orfinancialcostsif
compromised:Contractualinformation,informationcoveredbynon-disclosureagreements,
managementinformation;
• Anydatathatmustbeprotectedbylaworforcompliancereasons.
SecurityVerificationRequirements
Thevastmajorityofdatadisclosureissuescanbepreventedbyfollowingsimplerules.Mostofthecontrolslistedinthischapteraremandatoryforallverificationlevels.
# 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.
�
OWASP Mobile Application Security Verification Standard v1.0 17
2.9 Theappremovessensitivedatafromviewswhenbackgrounded. �
2.10 Theappdoesnotholdsensitivedatainmemorylongerthannecessary,andmemoryisclearedexplicitlyafteruse.
�
2.11 Theappenforcesaminimumdevice-access-securitypolicy,suchasrequiringthe
usertosetadevicepasscode.
�
2.12 Theappeducatestheuseraboutthetypesofpersonallyidentifiableinformationprocessed,aswellassecuritybestpracticestheusershouldfollowinusingthe
app.
�
References
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.md
Formoreinformation,seealso:
• OWASPMobileTop10:M2-InsecureDataStorage:https://www.owasp.org/index.php/Mobile_Top_10_2016-M2-Insecure_Data_Storage
• CWE:https://cwe.mitre.org/data/definitions/922.html
OWASP Mobile Application Security Verification Standard v1.0 18
V3:CryptographyRequirements
ControlObjective
Cryptographyisanessentialingredientwhenitcomestoprotectingdatastoredonamobiledevice.Itisalsoacategorywherethingscangohorriblywrong,especiallywhenstandardconventionsare
notfollowed.Thepurposeofthecontrolsinthischapteristoensurethattheverifiedapplicationusescryptographyaccordingtoindustrybestpractices,including:
• Useofprovencryptographiclibraries;
• Properchoiceandconfigurationofcryptographicprimitives;
• Asuitablerandomnumbergeneratorwhereverrandomnessisrequired.
SecurityVerificationRequirements# Description L1 L2
3.1 Theappdoesnotrelyonsymmetriccryptographywithhardcodedkeysasasolemethodofencryption.
� �
3.2 Theappusesprovenimplementationsofcryptographicprimitives. � �
3.3 Theappusescryptographicprimitivesthatareappropriatefortheparticularuse-case,configuredwithparametersthatadheretoindustrybestpractices.
� �
3.4 Theappdoesnotusecryptographicprotocolsoralgorithmsthatarewidelyconsidereddepreciatedforsecuritypurposes.
� �
3.5 Theappdoesn'tre-usethesamecryptographickeyformultiplepurposes. � �
3.6 Allrandomvaluesaregeneratedusingasufficientlysecurerandomnumbergenerator.
� �
References
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05e-Testing-
Cryptography.md
• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06e-Testing-
Cryptography.md
Formoreinformation,seealso:
• OWASPMobileTop10:M5-InsufficientCryptography
• CWE:https://cwe.mitre.org/data/definitions/310.html
OWASP Mobile Application Security Verification Standard v1.0 19
V4:AuthenticationandSessionManagementRequirements
ControlObjective
Inmostcases,usersloggingintoaremoteserviceisanintegralpartoftheoverallmobileapparchitecture.Eventhoughmostofthelogichappensattheendpoint,MASVSdefinessomebasic
requirementsregardinghowuseraccountsandsessionsaretobemanaged.
SecurityVerificationRequirements# Description L1 L2
4.1 Iftheappprovidesusersaccesstoaremoteservice,someformofauthentication,suchasusername/passwordauthentication,isperformedatthe
remoteendpoint.
� �
4.2 Ifstatefulsessionmanagementisused,theremoteendpointusesrandomly
generatedsessionidentifierstoauthenticateclientrequestswithoutsendingtheuser'scredentials.
� �
4.3 Ifstatelesstoken-basedauthenticationisused,theserverprovidesatokenthathasbeensignedusingasecurealgorithm.
� �
4.4 Theremoteendpointterminatestheexistingsessionwhentheuserlogsout. � �
4.5 Apasswordpolicyexistsandisenforcedattheremoteendpoint. � �
4.6 Theremoteendpointimplementsamechanismtoprotectagainstthesubmissionofcredentialsanexcessivenumberoftimes.
� �
4.7 Biometricauthentication,ifany,isnotevent-bound(i.e.usinganAPIthatsimplyreturns"true"or"false").Instead,itisbasedonunlockingthe
keychain/keystore.
�
4.8 Sessionsareinvalidatedattheremoteendpointafterapredefinedperiodofinactivityandaccesstokensexpire.
�
4.9 Asecondfactorofauthenticationexistsattheremoteendpointandthe2FA
requirementisconsistentlyenforced.
�
4.10 Sensitivetransactionsrequirestep-upauthentication. �
4.11 Theappinformstheuserofallloginactivitieswiththeiraccount.Usersareable
viewalistofdevicesusedtoaccesstheaccount,andtoblockspecificdevices.
�
References
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
• 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
OWASP Mobile Application Security Verification Standard v1.0 20
Formoreinformation,seealso:
• OWASPMobileTop10:M4-InsecureAuthentication,M6-InsecureAuthorization
• CWE:https://cwe.mitre.org/data/definitions/287.html
OWASP Mobile Application Security Verification Standard v1.0 21
V5:NetworkCommunicationRequirements
ControlObjective
Thepurposeofthecontrolslistedinthissectionistoensuretheconfidentialityandintegrityofinformationexchangedbetweenthemobileappandremoteserviceendpoints.Attheveryleast,a
mobileappmustsetupasecure,encryptedchannelfornetworkcommunicationusingtheTLSprotocolwithappropriatesettings.Level2listsadditionaldefense-in-depthmeasuresuchasSSL
pinning.
SecurityVerificationRequirements# Description L1 L2
5.1 DataisencryptedonthenetworkusingTLS.Thesecurechannelisusedconsistentlythroughouttheapp.
� �
5.2 TheTLSsettingsareinlinewithcurrentbestpractices,orascloseaspossibleifthemobileoperatingsystemdoesnotsupporttherecommendedstandards.
� �
5.3 TheappverifiestheX.509certificateoftheremoteendpointwhenthesecurechannelisestablished.OnlycertificatessignedbyatrustedCAareaccepted.
� �
5.4 Theappeitherusesitsowncertificatestore,orpinstheendpointcertificateorpublickey,andsubsequentlydoesnotestablishconnectionswithendpointsthat
offeradifferentcertificateorkey,evenifsignedbyatrustedCA.
�
5.5 Theappdoesn'trelyonasingleinsecurecommunicationchannel(emailorSMS)
forcriticaloperations,suchasenrollmentsandaccountrecovery.
�
5.6 Theapponlydependsonup-to-dateconnectivityandsecuritylibraries. �
References
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05g-Testing-
Network-Communication.md
• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06g-Testing-
Network-Communication.md
Formoreinformation,seealso:
• OWASPMobileTop10:M3-InsecureCommunication:
https://www.owasp.org/index.php/Mobile_Top_10_2016-M3-Insecure_Communication
• CWE:https://cwe.mitre.org/data/definitions/319.html
• CWE:https://cwe.mitre.org/data/definitions/295.html
OWASP Mobile Application Security Verification Standard v1.0 22
V6:PlatformInteractionRequirements
ControlObjective
ThecontrolsinthisgroupensurethattheappusesplatformAPIsandstandardcomponentsinasecuremanner.Additionally,thecontrolscovercommunicationbetweenapps(IPC).
SecurityVerificationRequirements# Description L1 L2
6.1 Theapponlyrequeststheminimumsetofpermissionsnecessary. � �
6.2 Allinputsfromexternalsourcesandtheuserarevalidatedandifnecessarysanitized.ThisincludesdatareceivedviatheUI,IPCmechanismssuchasintents,
customURLs,andnetworksources.
� �
6.3 TheappdoesnotexportsensitivefunctionalityviacustomURLschemes,unlessthesemechanismsareproperlyprotected.
� �
6.4 TheappdoesnotexportsensitivefunctionalitythroughIPCfacilities,unlessthesemechanismsareproperlyprotected.
� �
6.5 JavaScriptisdisabledinWebViewsunlessexplicitlyrequired. � �
6.6 WebViewsareconfiguredtoallowonlytheminimumsetofprotocolhandlersrequired(ideally,onlyhttpsissupported).Potentiallydangeroushandlers,such
asfile,telandapp-id,aredisabled.
� �
6.7 IfnativemethodsoftheappareexposedtoaWebView,verifythattheWebViewonlyrendersJavaScriptcontainedwithintheapppackage.
� �
6.8 Objectdeserialization,ifany,isimplementedusingsafeserializationAPIs. � �
References
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05h-Testing-
Platform-Interaction.md
• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06h-Testing-
Platform-Interaction.md
Formoreinformation,seealso:
• OWASPMobileTop10:M1-ImproperPlatformUsage
• CWE:https://cwe.mitre.org/data/definitions/20.html
• CWE:https://cwe.mitre.org/data/definitions/749.html
OWASP Mobile Application Security Verification Standard v1.0 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 Allthirdpartycomponentsusedbythemobileapp,suchaslibrariesand
frameworks,areidentified,andcheckedforknownvulnerabilities.� �
7.6 Theappcatchesandhandlespossibleexceptions. � �
7.7 Errorhandlinglogicinsecuritycontrolsdeniesaccessbydefault. � �
7.8 Inunmanagedcode,memoryisallocated,freedandusedsecurely. � �
7.9 Freesecurityfeaturesofferedbythetoolchain,suchasbyte-codeminification,
stackprotection,PIEsupportandautomaticreferencecounting,areactivated.� �
References
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05i-Testing-
Code-Quality-and-Build-Settings.md
• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06i-Testing-Code-
Quality-and-Build-Settings.md
Formoreinformation,seealso:
• 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
OWASP Mobile Application Security Verification Standard v1.0 24
V8:ResilienceRequirements
Controlobjective
Thissectioncoversdefense-in-depthmeasuresrecommendedforappsthatprocess,orgiveaccessto,sensitivedataorfunctionality.Lackofanyofthesecontrolsdoesnotcauseavulnerability-
instead,theyaremeanttoincreasetheapp'sresilienceagainstreverseengineeringandspecificclient-sideattacks.
Thecontrolsinthissectionshouldbeappliedasneeded,basedonanassessmentoftheriskscausedbyunauthorizedtamperingwiththeappand/orreverseengineeringofthecode.We
suggestconsultingtheOWASPdocument"TechnicalRisksofReverseEngineeringand
UnauthorizedCodeModificationReverseEngineeringandCodeModificationPrevention"(see
referencesbelow)foralistbusinessrisksaswellasassociatedtechnicalthreats.
Foranyofthecontrolsinthelistbelowtobeeffective,theappmustfulfilatleastallofMASVS-L1
(i.e.,solidsecuritycontrolsmustbeinplace),aswellasalllower-numberedrequirementsinV8.Forexamples,theobfuscationcontrolslistedinunder"impedecomprehension"mustbecombined
with"appisolation","impededynamicanalysisandtampering"and"devicebinding".
Notethatsoftwareprotectionsmustneverbeusedasareplacementforsecuritycontrols.ThecontrolslistedinMASVR-Rareintendedtoaddthreat-specific,additionalprotectivecontrolstoappsthatalsofulfiltheMASVSsecurityrequirements.
Thefollowingconsiderationsapply:
i. Athreatmodelmustbedefinedthatclearlyoutlinestheclient-sidethreatsdefendedagainst.Additionally,thegradeofprotectiontheschemeismeanttoprovidemustbespecified.Forexample,astatedgoalcouldbetoforceauthorsoftargetedmalwareseekingtoinstrumenttheapptoinvestsignificantmanualreverseengineeringeffort.
ii. Thethreatmodelmustbesensical.Forexample,hidingacryptographickeyinawhite-boximplementationisbesidesthepointiftheattackercansimplycode-liftthewhite-boxasawhole.
iii. Theeffectivenessoftheprotectionshouldalwaysbeverifiedbyahumanexpertwithexperienceintestingtheparticulartypesofanti-tamperingandobfuscationused(seealsothe"reverseengineering"and"assessingsoftwareprotections"chaptersintheMobileSecurityTestingGuide).
ImpedeDynamicAnalysisandTampering# Description R
8.1 Theappdetects,andrespondsto,thepresenceofarootedorjailbrokendeviceeitherbyalertingtheuserorterminatingtheapp.
�
8.2 Theapppreventsdebuggingand/ordetects,andrespondsto,adebuggerbeing
attached.Allavailabledebuggingprotocolsmustbecovered.�
8.3 Theappdetects,andrespondsto,tamperingwithexecutablefilesandcriticaldatawithinitsownsandbox.
�
OWASP Mobile Application Security Verification Standard v1.0 25
8.4 Theappdetects,andrespondsto,thepresenceofwidelyusedreverseengineering
toolsandframeworksonthedevice.�
8.5 Theappdetects,andrespondsto,beingruninanemulator. �
8.6 Theappdetects,andrespondsto,tamperingthecodeanddatainitsownmemory
space.�
8.7 Theappimplementsmultiplemechanismsineachdefensecategory(8.1to8.6).Notethatresiliencyscaleswiththeamount,diversityoftheoriginalityofthemechanisms
used.
�
8.8 Thedetectionmechanismstriggerresponsesofdifferenttypes,includingdelayedandstealthyresponses.
�
8.9 Obfuscationisappliedtoprogrammaticdefenses,whichinturnimpedede-obfuscationviadynamicanalysis.
�
DeviceBinding# Description R
8.10 Theappimplementsa'devicebinding'functionalityusingadevicefingerprintderivedfrommultiplepropertiesuniquetothedevice.
�
ImpedeComprehension# Description R
8.11 Allexecutablefilesandlibrariesbelongingtotheappareeitherencryptedonthefileleveland/orimportantcodeanddatasegmentsinsidetheexecutablesareencrypted
orpacked.Trivialstaticanalysisdoesnotrevealimportantcodeordata.
�
8.12 Ifthegoalofobfuscationistoprotectsensitivecomputations,anobfuscationschemeisusedthatisbothappropriatefortheparticulartaskandrobustagainstmanualand
automatedde-obfuscationmethods,consideringcurrentlypublishedresearch.The
effectivenessoftheobfuscationschememustbeverifiedthroughmanualtesting.
Notethathardware-basedisolationfeaturesarepreferredoverobfuscationwheneverpossible.
�
References
TheOWASPMobileSecurityTestingGuideprovidesdetailedinstructionsforverifyingtherequirementslistedinthissection.
• Android-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05j-Testing-
Resiliency-Against-Reverse-Engineering.md
• iOS-https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-
Resiliency-Against-Reverse-Engineering.md
Formoreinformation,seealso:
• OWASPMobileTop10:M8-CodeTampering,M9-ReverseEngineering
• WASPReverseEngineeringThreats-https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthoriz
ed_Code_Modification
OWASP Mobile Application Security Verification Standard v1.0 26
• OWASPReverseEngineeringandCodeModificationPrevention-
https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Pre
vention_Project
OWASP Mobile Application Security Verification Standard v1.0 27
AppendixA:Glossary• 2FA–Two-factorauthentication(2FA)addsasecondlevelofauthenticationtoanaccountlog-
in.
• AddressSpaceLayoutRandomization(ASLR)–Atechniquetomakeexploitingmemorycorruptionbugsmoredifficult.
• ApplicationSecurity–Application-levelsecurityfocusesontheanalysisofcomponentsthatcomprisetheapplicationlayeroftheOpenSystemsInterconnectionReferenceModel(OSI
Model),ratherthanfocusingonforexampletheunderlyingoperatingsystemorconnectednetworks.
• ApplicationSecurityVerification–ThetechnicalassessmentofanapplicationagainsttheOWASPMASVS.
• ApplicationSecurityVerificationReport–Areportthatdocumentstheoverallresultsandsupportinganalysisproducedbytheverifierforaparticularapplication.
• Authentication–Theverificationoftheclaimedidentityofanapplicationuser.• AutomatedVerification–Theuseofautomatedtools(eitherdynamicanalysistools,static
analysistools,orboth)thatusevulnerabilitysignaturestofindproblems.
• Blackboxtesting–Itisamethodofsoftwaretestingthatexaminesthefunctionalityofanapplicationwithoutpeeringintoitsinternalstructuresorworkings.
• Component–aself-containedunitofcode,withassociateddiskandnetworkinterfacesthatcommunicateswithothercomponents.
• Cross-SiteScripting(XSS)–Asecurityvulnerabilitytypicallyfoundinwebapplicationsallowingtheinjectionofclient-sidescriptsintocontent.
• Cryptographicmodule–Hardware,software,and/orfirmwarethatimplementscryptographicalgorithmsand/orgeneratescryptographickeys.
• CWE-CWEisacommunity-developedlistofcommonsoftwaresecurityweaknesses.Itservesasacommonlanguage,ameasuringstickforsoftwaresecuritytools,andasabaselinefor
weaknessidentification,mitigation,andpreventionefforts.
• DAST–Dynamicapplicationsecuritytesting(DAST)technologiesaredesignedtodetectconditionsindicativeofasecurityvulnerabilityinanapplicationinitsrunningstate.
• DesignVerification–Thetechnicalassessmentofthesecurityarchitectureofanapplication.• DynamicVerification–Theuseofautomatedtoolsthatusevulnerabilitysignaturestofind
problemsduringtheexecutionofanapplication.
• GloballyUniqueIdentifier(GUID)–auniquereferencenumberusedasanidentifierinsoftware.
• HyperTextTransferProtocol(HTTP)–Anapplicationprotocolfordistributed,collaborative,hypermediainformationsystems.Itisthefoundationofdatacommunicationfor
theWorldWideWeb.
• Hardcodedkeys–Cryptographickeyswhicharestoredinthedeviceitself.• IPC–InterProcessCommunications,InIPCProcessescommunicatewitheachotherandwith
thekerneltocoordinatetheiractivities.
• InputValidation–Thecanonicalizationandvalidationofuntrusteduserinput.• JAVABytecode-JavabytecodeistheinstructionsetoftheJavavirtualmachine(JVM).Each
bytecodeiscomposedofone,orinsomecasestwobytesthatrepresenttheinstruction
(opcode),alongwithzeroormorebytesforpassingparameters.
OWASP Mobile Application Security Verification Standard v1.0 28
• MaliciousCode–Codeintroducedintoanapplicationduringitsdevelopmentunbeknownsttotheapplicationowner,whichcircumventstheapplication'sintendedsecuritypolicy.Notthe
sameasmalwaresuchasavirusorworm!
• Malware–Executablecodethatisintroducedintoanapplicationduringruntimewithouttheknowledgeoftheapplicationuseroradministrator.
• OpenWebApplicationSecurityProject(OWASP)–TheOpenWebApplicationSecurityProject(OWASP)isaworldwidefreeandopencommunityfocusedonimprovingthesecurityofapplicationsoftware.Ourmissionistomakeapplicationsecurity"visible,"sothatpeople
andorganizationscanmakeinformeddecisionsaboutapplicationsecurityrisks.See:
http://www.owasp.org/
• PersonallyIdentifiableInformation(PII)-isinformationthatcanbeusedonitsownorwithotherinformationtoidentify,contact,orlocateasingleperson,ortoidentifyan
individualincontext.
• PIE–Position-independentexecutable(PIE)isabodyofmachinecodethat,beingplacedsomewhereintheprimarymemory,executesproperlyregardlessofitsabsoluteaddress.
• PKI–APKIisanarrangementthatbindspublickeyswithrespectiveidentitiesofentities.Thebindingisestablishedthroughaprocessofregistrationandissuanceofcertificatesatandbya
certificateauthority(CA).
• SAST–Staticapplicationsecuritytesting(SAST)isasetoftechnologiesdesignedtoanalyzeapplicationsourcecode,bytecodeandbinariesforcodinganddesignconditionsthatare
indicativeofsecurityvulnerabilities.SASTsolutionsanalyzeanapplicationfromthe“inside
out”inanonrunningstate.
• SDLC–Softwaredevelopmentlifecycle.• SecurityArchitecture–Anabstractionofanapplication'sdesignthatidentifiesanddescribes
whereandhowsecuritycontrolsareused,andalsoidentifiesanddescribesthelocationand
sensitivityofbothuserandapplicationdata.
• SecurityConfiguration–Theruntimeconfigurationofanapplicationthataffectshowsecuritycontrolsareused.
• SecurityControl–Afunctionorcomponentthatperformsasecuritycheck(e.g.anaccesscontrolcheck)orwhencalledresultsinasecurityeffect(e.g.generatinganauditrecord).
• SQLInjection(SQLi)–Acodeinjectiontechniqueusedtoattackdatadrivenapplications,inwhichmaliciousSQLstatementsareinsertedintoanentrypoint.
• SSOAuthentication–SingleSignOn(SSO)occurswhenauserlogsintooneClientandisthensignedintootherClientsautomatically,regardlessoftheplatform,technology,ordomainthe
userisusing.Forexamplewhenyouloginingoogleyouautomaticallyloginintheyoutube,
docsandmailservice.
• ThreatModeling-Atechniqueconsistingofdevelopingincreasinglyrefinedsecurityarchitecturestoidentifythreatagents,securityzones,securitycontrols,andimportant
technicalandbusinessassets.
• TransportLayerSecurity–CryptographicprotocolsthatprovidecommunicationsecurityovertheInternet
• URI/URL/URLfragments–AUniformResourceIdentifierisastringofcharactersusedtoidentifyanameorawebresource.AUniformResourceLocatorisoftenusedasareferencetoaresource.
• Useracceptancetesting(UAT)–Traditionallyatestenvironmentthatbehavesliketheproductionenvironmentwhereallsoftwaretestingisperformedbeforegoinglive.
OWASP Mobile Application Security Verification Standard v1.0 29
• Verifier–ThepersonorteamthatisreviewinganapplicationagainsttheOWASPASVSrequirements.
• Whitelist–Alistofpermitteddataoroperations,forexamplealistofcharactersthatareallowedtoperforminputvalidation.
• X.509Certificate–AnX.509certificateisadigitalcertificatethatusesthewidelyacceptedinternationalX.509publickeyinfrastructure(PKI)standardtoverifythatapublickeybelongs
totheuser,computerorserviceidentitycontainedwithinthecertificate.
OWASP Mobile Application Security Verification Standard v1.0 30
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.0RequirementsandSecurityAssessmentProcedures
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf
Recommended