FOREWORD BY BERNHARD MUELLER, OWASP MOBILE TESTING … · OWASP Mobile Application Security Verification Standard v0.9.4 5 Foreword by Bernhard Mueller, OWASP Mobile Testing Guide

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



V6:PLATFORMINTERACTIONREQUIREMENTS 22


V7:CODEQUALITYANDBUILDSETTINGREQUIREMENTS 23


V8:RESILIENCYAGAINSTREVERSEENGINEERINGREQUIREMENTS 24

CONTROLOBJECTIVE 24IMPEDEDYNAMICANALYSISANDTAMPERING 24DEVICEBINDING 25IMPEDECOMPREHENSION 25VERIFICATIONPROCESSES 26REFERENCES 26

APPENDIXA:GLOSSARY 27

APPENDIXB:REFERENCES 30


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


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.


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.


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.


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:


• 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.


MASVSL2+R

• FinancialIndustry:Onlinebankingappsthatallowtheusertomovefunds,wheretechniquescodeinjectionandinstrumentationoncompromiseddevicesposearisk.Inthiscase,controlsfromMASVS-Rcanbeusedtoimpedetampering,raisingthebarformalwareauthors.

• Allmobileappsthat,bydesign,needtostoresensitivedataonthemobiledevice,andatthesametimemustsupportawiderangeofdevicesandoperatingsystemversions.Inthiscase,resiliencycontrolscanbeusedasadefense-in-depthmeasuretoincreasetheeffortforattackersaimingtoextractthesensitivedata.


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.


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.


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.

✓


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


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.


# 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.

✓


# 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


V3:CryptographyRequirements

ControlObjective

Cryptographyisanessentialingredientwhenitcomestoprotectingdatastoredonamobiledevice.Itisalsoacategorywherethingscangohorriblywrong,especiallywhenstandardconventionsarenotfollowed.Thepurposeofthecontrolsinthischapteristoensurethattheverifiedapplicationusescryptographyaccordingtoindustrybestpractices,including:

• Usingprovencryptographiclibraries;• Properlychoosingandconfiguringcryptographicprimitives;• Usingsuitablerandomnumbergeneratorwhereverrandomnessisrequired.


# 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


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


V4:AuthenticationandSessionManagementRequirements

ControlObjective

Inmostcases,userlogintoaremoteserviceisanintegralpartoftheoverallmobileapparchitecture.Eventhoughmostofthelogichappensattheendpoint,MASVSdefinessomebasicrequirementsregardinghowuseraccountsandsessionsaremanaged.Therequirementscanbeeasilyverifiedwithoutaccesstothesourcecodeoftheserviceendpoint.


# 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.

✓




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


V5:NetworkCommunicationRequirements

ControlObjective

Thepurposeofthecontrolslistedinthissectionistoensuretheconfidentialityandintegrityofinformationexchangedbetweenthemobileappandremoteserviceendpoints.Attheveryleast,amobileappmustsetupasecure,encryptedchannelfornetworkcommunicationusingtheTLSprotocolwithappropriatesettings.Level2listsadditionaldefense-in-depthmeasuresuchasSSLpinning.


# 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.

✓



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


V6:PlatformInteractionRequirements

ControlObjective

ThecontrolsinthisgroupensurethattheappusesplatformAPIsandstandardcomponentsinasecuremanner.Additionally,thecontrolscovercommunicationbetweenapps(IPC).


# 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. ✓ ✓



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


V7:CodeQualityandBuildSettingRequirements

ControlObjective

Thegoalofthiscontrolistoensurethatbasicsecuritycodingpracticesarefollowedindevelopingtheapp,andthat"free"securityfeaturesofferedbythecompilerareactivated.


# 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.

✓ ✓



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


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. ✓


# 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.

✓




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


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.


• 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


• URI/URL/URLfragments–AUniformResourceIdentifierisastringofcharactersusedtoidentifyanameorawebresource.AUniformResourceLocatorisoftenusedasareferencetoaresource.

• Useracceptancetesting(UAT)–Traditionallyatestenvironmentthatbehavesliketheproductionenvironmentwhereallsoftwaretestingisperformedbeforegoinglive.

• Verifier–ThepersonorteamthatisreviewinganapplicationagainsttheOWASPASVSrequirements.

• Whitelist–Alistofpermitteddataoroperations,forexamplealistofcharactersthatareallowedtoperforminputvalidation.

• X.509Certificate–AnX.509certificateisadigitalcertificatethatusesthewidelyacceptedinternationalX.509publickeyinfrastructure(PKI)standardtoverifythatapublickeybelongstotheuser,computerorserviceidentitycontainedwithinthecertificate.


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

Documents

FOREWORD BY BERNHARD MUELLER, OWASP MOBILE TESTING … · OWASP Mobile Application Security Verification Standard v0.9.4 5 Foreword by Bernhard Mueller, OWASP Mobile Testing Guide