外文翻译 - 帮助开发人员构建安全的移动应用程序

外文原文及其中文翻译HelpingDevelopersConstructSecureMobileApplicationsMobilephoneshaveevolvedfromsimpledevicesusedforphonecallsandSMSmessagestoSophisticateddeviceswithfull-edgedoperatingsystems.Phoneownersarenolongerlimitedtothesimpleaddressbookandotherbasiccapabilitiesprovidedbytheoperatingsystemandphonemanufacturer.Infact,modernsmartphonessatisfymanyofthesamedemandsthatdesktopcomputerssatisfy.Modernmobilephonesprovidewirelessaccess,browsersupport,andtheabilitytocustomizethedevicebyinstallingthird-partyapplications.Userscanchecktheiremail,updatetheirsocialnetworkingproles,makebanktransactions,andplaymobilegames,notonlyfromtheirdesktopcomputers,butalsofromtheirmobilephones.Mobilephonesalsoprovideuniquecapabilitiesnotavailableondesktops.WithaccesstoGPS,userscangetne-grained,instantlocationupdates.Withaccesstothegyroscope,theynowcanhaveaportableportraitlevelingtool.Itisnotonlythephysicalresourcesofsmartphonesthatmakethemnotablydierentfromthetraditionalcomputermodel.ModernmobilephonesprovidenewparadigmsandpublicAPIsthatallowdeveloperstocreateapplicationswithrichinteractivefunctionality.Theseapplicationscommunicatewithotherapplications,withprotectedresourcesprovidedbythephone,andwithresourcesprovidedexternally(e.g.acrossthenetworkthroughwebapplications).Forexample,theAndroidplatformprovidesawayforapplicationstoexposetheirdataandservicestootherthird-partyapplicationsthroughAndroidsmessagepassingservice.Thesemessagesallowanapplicationtoinvokeanotherapplicationsservicewhilegivingtheend-usertheexperienceofusingasinglerich,multifunctional,seamlessapplication.ThesepublicAPIsintroducenewparadigmsthathelpdeveloperscreaterichapplications.Anotheruniquefeatureofsmartphonesisthecentralizedapplicationrepository(e.g.,AndroidMarketBlackBerryAppWorld,andiTunesAppStore).Thishaschangedtheapplicationlandscapeforbothusersanddevelopers.Fordevelopers,ithasloweredthebartoentryfordabblingdevelopers(throughlow,one-timedeveloperfees)andprovidedawayforthemtodistributetheirapplications.Forusers,theapplicationrepositoryprovidesastraightforward,centralizedwayforuserstobrowseandinstallapplications.Thecombinationofnewdesignparadigmsandthelargerrangeintheskillsofdeveloperscanleadtoconfusionandinsecurecode.Weexaminehowmobilephoneapplicationsinteractwitheachotherandtheirenvironmentandidentifyhowusingtheserichfeaturescanleadtovulnerableapplications.Wehelpsecuretheseapplicationsbyexposingcommondevelopermistakes,providingstaticanalysistoolstodetectvulnerabilities,suggestingplatformchanges,andrecommendingdevelopereducationandbetterAPIdocumentation.Weexaminethreefeaturesofmodernsmartphoneplatforms.IntentsFirst,weexaminehowapplicationsinteractwitheachother.IntentsaremessagesinAndroidsinter-andintra-applicationmessagepassingsystem.Thisapplicationcommunicationmodelpromotesthedevelopmentofrichapplications.Androiddeveloperscanleverageexistingdataandservicesprovidedbyotherapplicationswhilestillgivingtheimpressionofasingle,seamlessapplication.Forexample,arestaurantreviewapplicationcanaskotherapplicationstodisplaytherestaurantswebsite,provideamapwiththerestaurantslocation,andcalltherestaurant.Thiscommunicationmodelreducesdeveloperburdenandpromotesfunctionalityreuse.Androidsmessagepassingsystemcanbecomeanattacksurfaceifusedincorrectly.Thecontentofmessagescanbesnied,modied,stolen,orreplacedbymaliciousthird-partyapplications,whichcancompromiseuserprivacy.Also,amaliciousapplicationcaninjectforgedorotherwisemaliciousmessages,whichcanleadtobreachesofuserdataandviolateapplicationsecuritypolicies.Webuildatool,ComDroid,thatdetectsapplicationcommunicationvulnerabilitiesandndthat60%ofapplicationsanalyzedhaveatleastonevulnerability.Wealsondthatdeveloperscommonlyusethemessagepassingsysteminawaythatexposesboththemessageandtherecipienttoattack.Wediscussinsecuredeveloperpractices,thetoolwebuilttoidentifyexposedsurfaces,andthevulnerabilitieswefoundinthetop100mostpopularapplicationsingreaterdepthinthenextchapter.Wefurtheridentifyasubclassofcommunicationvulnerabilitiesthatariseduetodeveloperconfusionbetweeninter-applicationandintra-applicationcommunication.Wendthatdevelopersmaypubliclyexposestrictlyinternalmessages.Wendthat31%oftheawswefoundwithComDra-applicationconfusion.WefurtherproposemodicationstotheAndroidplatformtoautomaticallydetectandprotectinter-applicationmessagesthatshouldhavebeenintra-applicationmessages.PermissionsSecond,weexaminehowapplicationsinteractwithprotectedresources.Dangerousresources,suchasresourcesthatcostmoney(SMSmessagesorphonecalls),resourcesthatcontainprivatedata(accesstotheuserslocationorcontacts),ordeviceresources(bluetooth,WiFi),areprotectedbypermissions.Developersmustrequestthesepermissionsuponapplicationinstallation.Asthereisadisconnectbetweenthepermissionsanapplicationusesandthepermissionsanapplicationrequests,itispossibletooverprivilegeanapplication(i.e.,requestmorepermissionsthananapplicationactuallyuses).Thisunnecessarilyincreasesthecapabilitiesofasuccessfulattackeronanapplication.Ifanattackercanexploitavulnerabilityinanapplication,itwillreceiveaccesstoanyprotectedresourcestheapplicationrequested.Wedevelopedaframeworkfordeterminingwhetherdevelopersfollowtheprincipleofleastprivilegeandrequestonlythepermissionsthattheirapplicationneeds.Weanalyzed940applicationsandfoundthat30.4%ofapplicationsareoverprivileged.Ourndingsalsoshowthatmostapplicationsareoverprivilegedbyonly1permission,indicatingthatdevelopersaretryingtofollowleastprivilege.ExtraneouspermissionrequestscanbeattributedtothelackofadequatedocumentationontheAPIpermissions.Withoutthisdocumentation,developersarelefttoguesswhichpermissionsarerequired.Wehavefoundthatapplicationsfrequentlyhaveanextrapermissionthatsoundssimilartoapermissiontheyactuallyrequire.Wehavealsofoundmisleadingadviceonforumsthatsayapermissionisneededwhenitisnot.ThefulldetailsofourframeworkandanalysiscanbefoundinChapter3.WebViewsThird,weexaminehowapplicationsinteractwithwebcontent.Mobiledevicesandplatformsarearapidlyexpanding,divergentmarketplace.ApplicationdevelopersareforcedtocontendwithamultitudeofAndroidmobilephonesandtablets;customizedOSbranches(e.g.,KindleFire,NookTablet);andascoreofcompetingplatformsincludingiOSandWindowsPhone.AndroiddevelopersarerespondingtothechallengeofsupportingmultipleplatformsthroughtheuseofWebViews,whichallowHTMLcontenttobedisplayedwithinanapplication.Atahighlevel,WebViewsprovidethesamefunctionalityasawebbrowser,butallowfullcustomizabilitywithrespecttohowandwhatcontentisdisplayed(e.g.,navigationUIs,fullscreen,etc).Thesein-applicationbrowsersallowdeveloperstowritecodeinplatformneutralHTMLandJavaScriptthatcanbedisplayedbyanyAndroiddeviceandversion.Furthermore,applicationupdatesbecomesimple.DevelopersmerelyupdatetheHTMLcontentdownloadedbyanapplication.Whileconvenient,thesecustomizedbrowserscanalsoposeathreattoapplicationsecurity,asallowingwebcontenttointeractwiththeapplicationincreasestheapplicationsattacksurface.Weshowthattheseproblemsarereal.OneuniquefeatureofAndroidisthatitprovidesawayforJavaScriptinaWebViewtoinvokeAndroidapplicationcode,ifthisisenabledbytheapplication.Inparticular,theapplicationdevelopercanregisteraninterface(anAPItothemobileapplication)thatcanbecalledbytheJavaScript.Thisallowsthewebpagetoaccessfunctionalityanddataexposedbytheapplication.Thismayseemsafe,astypicallydevelopersuseWebViewstodisplaytrustedwebsites.However,itintroducesanewrisk.IftheusernavigatestheWebViewtoanuntrustedmaliciouswebsite,themaliciouspagemayreceiveaccesstopotentiallysensitiveapplicationdata.Similarly,iftheapplicationloadsapageoverHTTPandiftheuserisusinganinsecureWiFinetwork,aman-in-the-middlecouldinjectmaliciouscontentintothepageandmountasimilarattack.AllowingJavaScripttoinvokeapplicationcodebreakstraditionalbrowsersecuritymodels.Wendthatover20%ofapplicationshavethepotentialtogivewebsitesaccesstocode.Oftheseapplications,wend54%allowausertonavigatetomaliciousJavaScriptthatcouldaccessapplicationcode.Basedonourndings,werecommendmodicationstoAndroidtoaddresstheserisks.Ourexperimentssuggestthatthesemodicationswouldprotectmorethan60%ofthevulnerableapplications.Althoughallofthesefeaturesareprovidedbytheplatformwiththeintentionofeasingdeveloperburdenandpromotingrich,powerfulapplications,thisfunctionalitycancomeatthecostofapplicationsecurityifnotappliedcorrectly.WeshowthatwhentheAPIisnotclearornotdesignedwithsecurityinmind,developerswillcreateinsecureapplications.Werecommendseveralapproachesthatplatformdesignersandapplicationdeveloperscantaketoavoidthesevulnerabilities.First,platformbehaviorcanbemodiedtoclosethevulnerabilities.Thisapproachshiftstheimplementationburdenfromindividualapplicationdeveloperstotheplatformdeveloper.Insteadofrelyingondeveloperstoresolvetheirvulnerabilities(andwaitingforthemtomakethexes),platformchangescouldtakeeectwiththepushofoneover-the-airupdateandbeappliedtocurrentlyinstalledapplications.Someoftheapplicationfeaturesareenabledbydefault.Forexample,inthetheWebViewschapter,weseethatJavaScriptisgrantedaccesstothelesystembydefault.Thisisanunnecessarypolicythatcreatesthepotentialforattack.Featuresshouldbeturnedoffbydefault,anddevelopersshouldoptinwhentheywantspecialfunctionality.Similarly,intheIntentschapter,weseethatcomponentsareautomaticallymadepublicwhenthedeveloperincludesanIntentFilter.Thisbehaviorisinvisibleandunintuitive.Developersshouldexplicitlydeclaretheiraccessintentions.Second,weproposeextensionstotheAPItoenforcesecurityorimprovetheclarityofthefunctionality.Alteringtheplatformbehaviormaynotalwaysbeareasonableapproach,especiallyifwewanttoavoidbreakingbackwardcompatibility.ExtensionstotheAPI(e.g.,addingmethods)wouldapplysecurepracticestonewapplicationswithoutchangingthebehaviorofexistingmethods.Thisapproachwouldnotaffectlegacyapplications,whichisbothabenetanddrawback.Whileitavoidsbreakinglegacyapplications,italsodoesnotsecurethem.Italsohasthedrawbackofbeingslowertotakeeffect,relyingonthepaceatwhichnewAPIversionsareadopted.IntheIntentschapter,wesuggestextendingtheAPItoseparateinternalcommunicationfromexternalcommunication.Third,werecommenddevelopereducation.Unfortunately,securityisrarelyaprimarygoalofapplicationdevelopers.BycreatingclearAPIdocumentationanddiscussingsecurityissueswithusingtheAPIs,developersmayusetheAPIsasintendedandtakestepstoavoidtheidentiedapplicationvulnerabilities.Inthepermissionschapter,werecommendcleardocumentationonwhichAPIsrequirewhichpermissionsinordertoremovetheguessworkbydevelopersthatcontributetooverprivilege.Fourth,werecommendthatdeveloperspracticefundamentalsecurityprinciplessuchasprincipleofleastprivilegeandseparationofprivilege.Byseparatingprivilegedandunprivilegedcomponents,developersreducetheriskshouldavulnerabilitybeexploited.Finally,weprovidestaticanalysistoolsthatdeveloperscanusetoidentifyvulnerabilitiesintheirapplications.Throughtheseveapproaches,webelievewecanimprovethesecurityofmobileapplicationsandsubsequentlythesecurityofthemobiledevice.帮助开发人员构建安全的移动应用程序手机已经从用于通话和短信向有着先进的简便的设备和成熟的操作系统发展而来的。手机用户将不再局限于操作系统和手机制造商提供的简单通讯录等基本功能。事实上，在现代智能手机已经满足了许多的台式电脑满足相同的要求。现代的移动电话提供无线接入，浏览器的支持，并通过安装第三方应用程序来定制设备的能力。用户可以检查他们的电子邮件，更新社交网络配置文件，进行银行交易，和玩手机游戏，这些不仅可以在他们的台式电脑，而且也他们的移动手机上实现。手机还提供不可用在台式机上的独特能力。通过连接访问GPS，用户可以得到细致、即时位置更新。利用该陀螺仪，他们现在可以得到一个便携式的水平工具。使智能手机不同特别是与传统的计算机模型不同的不仅是物理资源。现代的移动电话提供新的范式和公共API，允许开发人员创建具有丰富的交互式功能的应用程序。这些应用程序可以与其他应用程序进行通信，可以访问由手机提供的受保护的资源，并可以访问外部提供（通过跨Web应用程序的网络EG）的资源。例如，Android平台提供了一种用于应用程序通过Android的消息传递的服务，他们的数据和服务提供给其他的第三方应用程序。这些消息使应用程序能够调用其他应用程序的服务，同时也让最终用户使用一个单一的、丰富的、多功能、无缝的应用体验。这些公共的API引入新的模式，以帮助开发人员创建丰富的应用程序。智能手机的另一个特点是集中式应用程序库（例如，Android市场，黑莓应用程序世界，和iTunes的AppStore）。对于用户和开发者这种情况已经改变了应用程序的形式。对于开发人员来说，它降低了开发门槛（通过低消耗、一次性开发费用），并为低成本开发人员提供了一种发布应用程序的发放。对于用户来说，应用程序库提供了一个简单、集中的方式供用户浏览和安装应用程序。新的设计模式和更大范围的开发人员的技能组合可能会导致混乱和不安全的代码。我们观察的手机应用与对方和他们的环境之间如何相互作用，并确定如何使用这些丰富多样的易受攻击的应用程序。我们通过揭示应用程序间共同开发的错误、提供静态分析工具来检测漏洞、提示平台的变化，并建议开发者接受更好的教育和更好的API文档保护来这些应用程序。我们研究了现代智能手机平台三个特点。Intent首先，我们研究应用程序相互交互的方式。意图是在Android的之间和内部应用程序消息传递的系统。这种应用程序的通信模式促进了丰富的应用程序的发展。Android开发者可以利用其他应用程序提供的现有的数据和服务，同时还提供一个单一、无缝的应用程序的印象。例如，一间餐厅检查应用程序可以要求其他应用程序显示餐厅的网站，提供地图与餐厅的位置，并呼入餐厅。这种通信模式降低了开发者的负担，促进功能的重用。如果使用不当Android的消息传递系统可以成为一个攻击面。消息的内容可以被嗅探、修改、被盗或恶意的第三方应用程序，这可能会危及用户隐私。此外，恶意应用程序可以注入伪造或其他恶意的消息，这可能会导致用户数据和应用程序破坏，违反安全策略。我们建立了一个工具，ComDroid，检测应用程序通信的漏洞和发现的分析应用发现60应用程序至少有一个漏洞。我们还发现，开发商通常使用消息传递系统中泄露双方的邮件和收件人攻击的方式。我们讨论了不安全的开发方式，并建立了以识别泄漏现象的工具，我们在TOP100最流行的应用更加深入下一章讲述。我们进一步确定了由于跨应用和内部应用程序之间的通讯开发的混乱通信漏洞的子类。我们发现，开发商可能会公开泄漏严格的内部消息。我们通过ComDroid发现的30%缺陷是由于与跨应用程序内部的混乱。我们进一步提出对Android平台的自动检测和保护应该是内部应用程序消息应用程序间的消息。Permissions其次，我们研究应用通过受保护资源的交互方式。危险的资源，如付费资源（短信或电话）、包含私人数据（访问用户的位置或联系人）、或设备资源（蓝牙，WiFi），通过权限保护。开发人员必须在应用程序安装请求赋予权限。由于有权限的应用程序用途和权限的应用程序请求之间的脱节，有可能越权的应用程序（即，要求的权限比应用程序实际使用的更多）。这不必要地增加了对应用程序一个成功的攻击者能力。如果一个攻击者可以利用应用程序中的一个漏洞，它会收到访问任何受保护的资源的应用要求。我们开发了用于确定一个框架，开发人员是否遵循最小特权原则，并要求只有权限，他们的应用需求。我们分析940个应用，发现30.4的应用有越权限的行为。我们的研究结果还表明，大多数应用程序是由单一许可引起的越权，这表明开发商正试图遵循最低权限。多余的权限请求可以归因于缺乏对API的权限足够的文件。如果没有这个文件，开发人员留下猜测的权限是必需的。我们发现，应用程序经常有这听起来类似于他们实际上需要权限的额外许可。我们还发现误导性建议的论坛，允许在不被需要时而被说成需要。我们的框架和分析的详细信息可在第3章中找到。WebViews第三，我们研究应用与Web内容交互的方式。移动设备和平台是一个扩张迅速，市场分歧大的地方。应用程序开发人员被迫与众多Android的sandtablets抗衡;定制操作系统的分支（例如，KindleFire，nook平板）;与之竞争的对手的平台包括iOS和WindowsPhone.Android开发者正在响应通过使用WebViews，它允许在应用程序中显示HTML内容的支持多平台的挑战。在较高的水平，WebViews提供相同的功能作为Web浏览器，允许全定制方面的方式和内容的内容显示（例如，导航的用户界面，全屏等）。这些在应用浏览器允许开发人员在平台中立的HTML和可以被任何Android设备和版本显示的JavaScript代码编写。此外，应用程序更新变得简单。开发商仅仅通过更新应用程序下载的H