这些问题与一般安全软件开发的问题基本相同。

请注意，安全软件开发最关键的问题是 (1) 将安全性集成到您的软件开发生命周期中（因此将安全性集成到流程的每个步骤中：设计、实施、维护、操作），以及 (2) 对开发人员的培训。认为软件库或框架会神奇地确保系统安全是错误的。

特定于移动设备的问题。也就是说，这里有一些在移动领域值得特别关注的问题：

• 使用安全的沟通渠道。 警惕从移动应用程序到其他地方的服务器的 HTTP 或其他未加密通信。手机用户经常使用开放的 Wifi 网络进行网络连接，这些网络很容易受到窃听和中间人攻击。因此，如果您要发送任何机密或安全关键信息（个人信息、会话 cookie、身份验证令牌），您应该使用 HTTPS，而不是 HTTP。对于自定义网络协议，请使用 TLS。

  一般来说，如果有疑问，请对明文通信的任何使用持怀疑态度。 几个备受瞩目的应用程序存在这种形式的漏洞（它们通过明文 HTTP 发送会话令牌）；不要犯同样的错误。

• 安全地存储安全关键数据。如果您有一个对安全至关重要的应用程序，请注意在手机上存储高度敏感的数据。例如，你不想在手机上存储网上银行密码或类似的东西，你可能要小心信用卡之类的东西——因为如果手机被盗，这些信息就可以被访问小偷。盗窃和人身安全尤其重要，因为盗窃、丢失或借用手机非常容易。

• 注意存储应用程序数据的位置。存储应用程序数据时，请注意存储位置以及使用的权限。您不想无意中将敏感信息提供给其他应用程序。例如，在 Android 上，应用程序可以将特定于应用程序的数据存储在内部存储器、SD 卡或内容提供程序中。这些具有不同的安全含义。默认情况下，内部存储是安全的（没有其他应用程序可以查看数据），并且是一个不错的标准选择。SD 卡默认对其他应用程序可见，因此您需要更加小心。如果您将数据存储在 SD 卡上，至少要设置文件权限，以便其他应用程序无法读取它，除非数据打算共享。可以使用 Android 权限保护内容提供者。

• 尊重用户隐私。不要做会让你的用户感到害怕的事情，如果他们发现的话。提前了解您的应用程序的功能。例如，不要在未经用户同意的情况下获取用户地址簿的副本并将其上传到您的服务器（即使您是出于好意，例如帮助他们与朋友联系）。不要将照片上传到用户背后的服务器。

  在处理设备 ID、电子邮件地址或电话号码等唯一标识符时，一种有时会有所帮助的技术是在这些标识符离开手机之前对其进行散列处理。不要只是将它们上传到您的服务器。相反，将它们与一些特定于应用程序的值一起散列，然后上传散列。在某些情况下，这可以帮助改善用户隐私。

• 静态分析。考虑使用了解移动特定风险的静态分析工具。对于商业工具，Fortify 在这方面有很好的口碑。对于免费工具，Comdroid和Stowaway会检查一些特定于 Android 应用程序的风险。但是，请注意，免费工具不如 Fortify 等商业产品全面或完善。

了解您的平台。让自己了解特定于您的特定移动平台的安全风险。例如：

• 在 Android 上，请注意与 Webview 相关的漏洞。 如果您在应用程序中使用 webviews，并且您通过 Javascript 接口（例如 、 ）公开您的任何应用程序webview.addJavascriptInterface()，webview.setWebViewClient()那么就会存在细微的安全风险。

• 在 Android 上，请注意与 Intent 相关的漏洞。Android Intent 很棒；它们允许灵活的跨应用程序通信。但是，它们也引入了新的安全风险。特别是，它们共享其他通信渠道的许多潜在风险：窃听、欺骗和中间人攻击。

  为了避免这些问题，您知道风险。使用 Intent 进行应用内部通信时，仅使用显式 Intent（而不是隐式 Intent），并确保所有 Intent 接收器都是内部的，不会导出到世界（请注意，在某些情况下，Android 会隐式导出组件；你想避免那些可能收到你的内部意图的人）。在使用 Intent 进行跨应用通信时，请注意，如果不小心，Intent 可能会被注入和窃听。因此，当接收到可能来自另一个应用程序的 Intent 时，将其内容视为不受信任并应用适当的输入验证/清理；您可能还想检查您收到的每个 Intent 的发件人。当发送可能被其他应用程序接收到的隐式 Intent 时，请注意它们可能会被恶意应用程序拦截，因此您应避免在 Intent 中包含任何敏感或机密信息。避免将内部沟通与外部沟通混为一谈。

  有关 Intent 相关漏洞的介绍，请阅读此处和此处。更多技术细节可以在技术文件中找到。

• 在 Android 上，避免权限重新委托攻击。权限重委托漏洞是您的应用程序拥有权限P，并且愿意通过执行需要权限P的操作来响应其他应用程序的请求。如果其他应用程序没有权限P，则您刚刚泄漏与 P 关联的其他应用程序的权限。

• 在 Android 上，请注意 SQL 注入漏洞。在 Android 上，可以通过 SQL 查询访问内容提供程序。您需要避免经典的 SQL 注入漏洞。此外，如果您构建自己的 Content Provider 并实现自己的方法（如delete、execSQL、rawQuery、update、updateWithNoConflict）来处理 Content Provider 上的查询，那么在实现这些方法时要小心，以避免无意中引入 SQL 注入漏洞——经验表明，开发人员在实施这些方法时经常会引入问题。避免这些问题的最佳方法与在非移动平台上相同：使用参数化查询（准备好的语句）。

其他资源。 对于 Android，我强烈推荐以下演示文稿：

• 使用 Google Android 上吊的七种方法（幻灯片）

对于一般的移动安全，我还建议查看以下问题：

• Android API/开发安全陷阱

• 安全软件开发

• 仅在移动解决方案中常见的漏洞？

• 顶级移动设备安全问题？

• 有什么有用的 Android 源代码审查工具吗？

• 移动操作系统是否提供加密质量的随机性？

我不知道，但我也不认为它需要。移动平台并不是什么新鲜事。归根结底，许多相同的漏洞都会影响该平台。许多移动应用程序只是 Web 应用程序，其中代码的客户端完全用 HTML/JavaScript 编写。

话虽如此，移动开发者违反CWE-602 的次数比任何其他平台的开发者都要多。老实说，它相当莫名其妙，因为漏洞是如此明显。一个很好的例子是直接连接到 MySQL 后端的 Super Meat Boy。这个游戏有移动版，但它也是一个普通的旧桌面应用程序，它们都容易受到相同的攻击！

自从一月份提出这个问题以来，已经发布了很多东西，包括：

• 应用程序开发人员的 ENISA 智能手机安全开发指南
• viaForensics Secure Mobile Development Best Practices（需要注册才能下载PDF版本）
• W3C 移动 Web 应用程序最佳实践：W3C 推荐 2010 年 12 月 14 日
• Denim Group：安全移动应用程序开发参考 uTest：移动应用程序测试指南 Klocwork：安全嵌入式软件的威胁建模

Threadstrong还提供在线课程。