• 1. M- Improper Platform Usage（平台使用不当）
  • 1.1. 常见类型
  • 1.2. 避免方式
• 2. M- Insecure Data Storage（不安全的数据存储）
  • 2.1. 威胁代理
  • 2.2. 影响
  • 2.3. 常见类型
    • 2.3.1. 存储不安全的数据
    • 2.3.2. 意外的数据泄漏
  • 2.4. 避免方式
• 3. M- Insecure Communication（不安全的通信）
  • 3.1. 威胁代理
  • 3.2. 影响
  • 3.3. 常见类型
  • 3.4. 避免方式
    • 3.4.1. 通用最佳实践
    • 3.4.2. iOS特定的最佳实践
    • 3.4.3. Android特定的最佳实践
• 4. M- Insecure Authentication（不安全的身份验证）
  • 4.1. 威胁代理
  • 4.2. 影响
  • 4.3. 常见类型
  • 4.4. 避免方式
• 5. M- Insufficient Cryptography（弱加密）
  • 5.1. 影响
  • 5.2. 常见类型
  • 5.3. 避免方式
• 6. M- Insecure Authorization（不安全的授权）
  • 6.1. 影响
  • 6.2. 常见类型
  • 6.3. 避免方式
• 7. M- Client Code Quality（客户端代码质量）
  • 7.1. 影响
  • 7.2. 避免方式
• 8. M- Code Tampering（代码篡改）
  • 8.1. 影响
  • 8.2. 常见类型
  • 8.3. 避免方式
    • 8.3.1. Android Root检测
    • 8.3.2. IOS 越狱检测
• 9. M- Reverse Engineering（逆向）
  • 9.1. 影响
  • 9.2. 常见类型
  • 9.3. 避免方式
• 10. M- Extraneous Functionality（无关功能）
  • 10.1. 影响
  • 10.2. 常见类型
  • 10.3. 避免方式

原文地址

1. M- Improper Platform Usage（平台使用不当）

会引入传统的OWASP top 10问题，可以在客户端对服务端实施攻击
违反开发指南、违反惯例、无意的误用等会引入此类问题
此类别中风险的定义特征是平台（iOS，Android，Windows Phone等）提供了记录和充分理解的功能或功能。该应用程序无法使用该功能或​​未正确使用它，比如Android中WebView的js和file协议

1.1. 常见类型

1、糟糕的Web服务强化
a)逻辑缺陷
b)弱认证
c)弱会话管理或没有会话管理
d)会话固定
e)使用GET方法传输的敏感数据
2、不安全的Web服务器配置
a)默认内容
b)管理界面
3、Web服务和支持移动的网站上的注入（SQL，XSS，Command）
4、身份验证缺陷
5、会话管理缺陷
6、访问控制漏洞
7、本地和远程文件包括

1.2. 避免方式

必须在移动应用程序的服务器端使用安全编码和配置实践。有关特定漏洞信息，请参阅OWASP Web Top Ten或Cloud Top Ten项目

2. M- Insecure Data Storage（不安全的数据存储）

敏感数据未加密存储、本地文件未加密、WebView本地明文存储cookie等问题

2.1. 威胁代理

1、手机丢失且被攻击者获取
2、恶意软件在设备上运行

2.2. 影响

直接影响就是会导致敏感信息泄露，由此会产生以下影响：
1、身份盗用
2、侵犯隐私
3、欺诈
4、声誉受损
5、外部策略冲突（PCI）
6、物质损失

2.3. 常见类型

2.3.1. 存储不安全的数据

1、SQL数据库
2、日志文件
3、XML数据存储或清单文件
4、二进制数据存储
5、Cookie
6、敏感数据存储到SD卡
SD卡上的数据可以被任意应用读取
7、云同步

2.3.2. 意外的数据泄漏

1、操作系统缓存数据，图像，按键，记录和缓冲区的方式;
2、开发框架缓存数据，图像，按键，日志记录和缓冲区的方式;
3、数据广告，分析，社交或启用框架的方式或数量缓存数据，图像，按键，日志记录和缓冲区。

2.4. 避免方式

了解你的移动应用程序，操作系统，平台和框架如何处理以下类型的功能，并对其进行加密或及时将其清除：
1、URL缓存（请求和响应）
2、键盘按键缓存
3、复制/粘贴缓冲区缓存
4、应用背景
5、中间数据
6、记录
7、HTML5数据存储
8、浏览器cookie对象
9、分析数据发送给第三方

3. M- Insecure Communication（不安全的通信）

此风险包括移动端到移动端通信，APP到服务器通信或移动端到其他的通信。此风险包括移动设备可能使用的所有通信技术：TCP / IP，WiFi，蓝牙/蓝牙-LE，NFC，音频，红外，GSM，3G，SMS等。
此类问题的特征包括打包某种敏感数据并将其传输到设备或从设备传出。敏感数据包括加密密钥，密码，私有用户信息，帐户详细信息，会话令牌，文档，元数据和二进制文件。敏感数据可以从服务器到达设备，可以从应用程序到服务器，或者可以在设备和本地其他东西之间（例如，NFC终端或NFC卡）传输。这种风险的定义特征是存在两个设备而且它们之间会传递某些数据

3.1. 威胁代理

1、共享您本地网络的对手（受感染或受监控的Wi-Fi）
2、运营商或网络设备（路由器，手机信号塔，代理服务器等）
3、移动设备上的恶意软件

3.2. 影响

1、隐私泄露
2、身份盗用
3、网络钓鱼
4、中间人攻击
5、欺诈
6、声誉损害

3.3. 常见类型

不安全通信的常见风险是:完整性、保密性、来源完整性。如：数据可以在传输过程中更改，而无法检测到更改（例如，通过中间人攻击）、机密数据可以通过在通信中观察通信（即窃听）或通过记录发生的对话并稍后进行攻击（离线攻击）来暴露，学习或获得、未能正确设置和验证TLS连接（例如，证书检查，弱密码，其他TLS配置问题）都属于不安全通信的范畴
1、缺少证书检查
比如：自定义SSL x509 TrustManager，重写checkServerTrusted方法，方法内不做任何服务端的证书校验，或者构造HttpClient时设置HostnameVerifier时参数使用ALLOW_ALL_HOSTNAME_VERIFIER或空的HostnameVerifier，这样的话移动应用程序会无条件接受服务器提供给它的任何证书。这会破坏移动应用程序和端点之间的任何相互身份验证功能，黑客可以使用中间人攻击获取加密内容。
2、弱握手协商
移动应用程序和端点成功连接并协商密码套件，作为连接握手的一部分。客户端成功与服务器协商以使用弱密码套件，导致弱加密，攻击者可以轻松解密。这会危及移动应用程序和端点之间通道的机密性
3、隐私信息泄露
移动应用程序通过非安全通道而不是通过SSL将个人身份信息传输到端点。这会危及移动应用程序和端点之间任何与隐私相关的数据的机密性

3.4. 避免方式

3.4.1. 通用最佳实践

• 假设网络层不安全且容易被窃听。
• 将SSL / TLS应用于传输渠道，移动应用程序将使用该渠道将敏感信息，会话令牌或其他敏感数据传输到后端API或Web服务。
• 当应用程序通过浏览器/ webkit运行例程时，通过使用其SSL版本来考虑外部实体（如第三方分析公司，社交网络等）。避免混合SSL会话，因为它们可能会暴露用户的会话ID。
• 使用具有适当密钥长度的强大的行业标准密码套件。
• 使用由受信任的CA提供商签名的证书。
• 永远不要允许自签名证书，并考虑将证书固定用于安全意识的应用程序。
• 始终需要SSL链验证。
• 仅在使用密钥链中的受信任证书验证端点服务器的标识后才建立安全连接。
• 如果移动应用检测到无效证书，则通过用户界面提醒用户。
• 不要通过备用信道（例如，SMS，MMS或通知）发送敏感数据。
• 如果可能，请在将任何敏感数据提供给SSL通道之前对其应用单独的加密层。如果在SSL实施中发现未来的漏洞，加密数据将提供防止机密性违规的二级防御。
• 较新的威胁允许攻击者通过在移动设备的SSL库加密并将网络流量传输到目标服务器之前拦截移动设备内的流量来窃听敏感流量。有关此风险性质的更多信息，请参阅M10。

3.4.2. iOS特定的最佳实践

最新版本的iOS中的默认类很好地处理SSL密码强度协商。当开发人员临时添加代码以绕过这些默认值以适应开发障碍时，就会遇到麻烦。除上述一般做法外还有：

• 确保证书有效且失败。
• 使用CFNetwork时，请考虑使用Secure Transport API指定可信客户端证书。在几乎所有情况下，NSStreamSocketSecurityLevelTLSv1都应该用于更高的标准密码强度。
• 在开发之后，确保所有NSURL调用（或NSURL的包装器）不允许自签名或无效的证书，例如NSURL类方法setAllowsAnyHTTPSCertificate。
• 通过执行以下操作考虑使用证书固定：导出证书，将其包含在应用程序包中，并将其锚定到您的信任对象。使用NSURL方法连接：willSendRequestForAuthenticationChallenge：现在将接受您的证书。

3.4.3. Android特定的最佳实践

• 在开发周期之后删除所有可能允许应用程序接受所有证书的代码，例如org.apache.http.conn.ssl.AllowAllHostnameVerifier或SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER。这相当于信任所有证书。
• 如果使用扩展SSLSocketFactory的类，请确保正确实现checkServerTrusted方法，以便正确检查服务器证书。

4. M- Insecure Authentication（不安全的身份验证）

4.1. 威胁代理

利用身份验证漏洞的威胁代理通常通过使用可用或自定义工具的自动攻击来实现。

4.2. 影响

1、信息窃取
2、未经经授权的数据访问
3、无法识别执行操作请求的用户，因为用户的身份不能被建立，应用将无法记录或审计用户活动。这将导致无法检测到攻击的来源、潜在的利用的本质和以及防止未来的攻击。

4.3. 常见类型

一般来讲，问题都出现在没有对操作进行验证，或者说默认将操作当做了可信的，就会导致此类问题

• 如果移动应用程序能够匿名执行后端API服务请求而不提供访问令牌，则此应用程序会遭受不安全的身份验证
• 如果移动应用程序在设备上本地存储任何密码或共享机密，则很可能会出现不安全的身份验证
• 如果移动应用使用弱密码策略来简化输入密码，则会出现不安全的身份验证
• 如果移动应用程序使用TouchID等功能，则会遭受不安全的身份验证
  1、隐藏服务请求：开发人员假设只有经过身份验证的用户才能生成移动应用程序提交给其后端进行处理的服务请求。在处理请求期间，服务器代码不验证传入请求是否与已知用户相关联。因此，攻击者向后端服务提交服务请求，并匿名执行影响解决方案合法用户的功能。
  2、可用性要求：由于可用性要求，移动应用程序允许4位数的密码。服务器代码正确存储密码的散列版本。但是，由于密码长度非常短，攻击者可以使用彩虹哈希表快速推断出原始密码。如果服务器上的密码文件（或数据存储）遭到破坏，攻击者将能够快速推断出用户的密码。

4.4. 避免方式

避免弱模式
避免以下不安全的移动应用程序身份验证设计模式：

• 如果要将Web应用程序移植到其移动端，则移动应用程序的身份验证要求应与Web应用程序组件的身份验证要求相匹配。因此，不应该使用比Web浏览器更少的身份验证因素进行身份验证;
• 在本地验证用户可能会导致客户端绕过漏洞。如果应用程序在本地存储数据，则可以通过运行时操作或修改二进制文件在越狱设备上绕过身份验证。如果离线身份验证存在令人信服的业务要求，请参阅M10以获取有关防止针对移动应用程序的二进制攻击的其他指导;
• 尽可能确保所有身份验证请求都在服务器端执行。验证成功后，应用程序数据将加载到移动设备上。这将确保应用程序数据仅在成功验证后才可用;
• 如果需要客户端存储数据，则需要使用从用户的登录凭据安全地派生出的加密密钥对数据进行加密。这将确保只有在输入正确的凭据后才能访问本地存储的应用程序数据。本地数据存在通过二进制攻击解密以及其他风险。有关防止导致本地数据被盗的二进制攻击的其他指导，请参阅M9;
• 移动应用程序中实现的持久身份验证功能永远不应该在设备上存储用户密码;
• 理想情况下，移动应用程序应使用特定于设备的身份验证令牌，该令牌可由用户在移动应用程序中撤消。这将确保应用程序可以减少被盗/丢失设备的未授权访问;
• 请勿使用任何可欺骗的值来验证用户身份。这包括设备标识符或地理位置;
• 移动应用程序中的持久身份验证应实现为可选，默认情况下不启用;
• 如果可能，请勿允许用户为身份验证密码提供4位数的PIN码。
  加强身份验证
• 开发人员应该假设恶意用户可以绕过所有客户端授权和身份验证控制。必要时，必须在服务器端重新强制执行授权和身份验证控制
• 由于离线使用要求，可能需要移动应用程序在移动应用程序代码中执行本地身份验证或授权检查。如果是这种情况，开发人员应在其代码中进行本地完整性检查，以检测任何未经授权的代码更改。有关检测和响应二进制攻击的更多信息，请参阅M9。

5. M- Insufficient Cryptography（弱加密）

5.1. 影响

• 隐私侵犯
• 信息窃取
• 代码盗窃
• 知识产权盗窃
• 声誉损害

5.2. 常见类型

• 依赖于内置代码加密
  可能被逆向获取加密逻辑进行破解
• 糟糕的密钥管理
  将密钥包含在与加密内容相同的攻击者可读目录中
使攻击者可以使用密钥
在代码中使用硬编码密钥
密钥可能通过二进制攻击被截获。有关防止二进制攻击的更多信息，请参阅M10
• 创建和使用自定义加密协议
  使用广为人知的加密算法不好么，这样搞不是作死么 (*^▽^*)，费力不讨好
• 使用不安全和/或过时的算法
  RC2/MD4/MD5/SHA1

5.3. 避免方式

• 始终使用安全社区认可的现代算法，并尽可能利用移动平台中最先进的加密API
• 尽可能避免在移动设备上存储任何敏感数据
• 应用将在未来至少10年内经受住时间考验的加密标准
• 遵循NIST关于推荐算法的指南

6. M- Insecure Authorization（不安全的授权）

允许攻击者使用移动应用程序的经过身份验证但权限较低的用户执行他们不应该被授权的功能。在移动设备内而不是通过远程服务器进行授权决策时，授权要求更容易受到攻击
这个问题看上去和身份验证有点相似：身份验证是识别个人的行为。授权是检查所识别的个人是否具有执行该行为所必需的权限的行为。这两者密切相关。如果服务端在处理来自APP的请求时未能进行身份验证和个人身份验证，则也会出现不安全的授权问题，当未建立呼叫者的身份时，对传入请求进行授权检查基本上是不可能的

6.1. 影响

授权不佳的技术影响在性质上与认证不良的技术影响相似
1、声誉损害
2、欺诈
3、信息盗窃

6.2. 常见类型

• 存在不安全的直接对象引用（IDOR）漏洞
• 隐藏端点
  通常，开发人员不会对后端隐藏功能执行授权检查，因为他们认为只有具有正确角色的人才能看到隐藏功能
• 用户角色或权限传输
  如果移动应用程序将用户的角色或权限作为请求的一部分传输到后端系统，则会受到不安全授权的影响

6.3. 避免方式

• 仅使用后端系统中包含的信息验证经过身份验证的用户的角色和权限。避免依赖来自移动设备本身的任何角色或权限信息
• 后端代码应该独立地验证与标识一起出现的与请求（所请求操作的操作数）相关联的任何传入标识符是否匹配并属于传入标识

7. M- Client Code Quality（客户端代码质量）

可以将不受信任的输入传递给移动代码中的方法调用的实体。这些类型的问题本身不一定是安全问题，但会导致安全漏洞
目前此问题的解决方式貌似一是规范代码写作，还有就是安全代码扫描了哦

7.1. 影响

1、信息窃取
2、声誉损害
3、知识产权盗窃
4、性能下降等

7.2. 避免方式

• 保持组织中每个人都同意的一致编码模式
• 编写易于阅读和记录良好的代码
• 使用缓冲区时，始终验证任何传入缓冲区数据的长度不会超过目标缓冲区的长度
• 通过自动化，通过使用第三方静态分析工具识别缓冲区溢出和内存泄漏
• 优先解决缓冲区溢出和内存泄漏问题超过其他“代码质量”问题

8. M- Code Tampering（代码篡改）

8.1. 影响

• 未经授权的新功能
• 身份盗用
• 欺诈

8.2. 常见类型

• 修改代码
• 修改资源
• 修改API
  游戏破解付费、伪造银行APP获取用户信息

8.3. 避免方式

8.3.1. Android Root检测

• 检查测试密钥
  检查build.prop是否包含指示开发人员构建或非官方ROM的行ro.build.tags = test-keys
• 检查OTA证书
  检查文件/etc/security/otacerts.zip是否存在
• 检查几个已知的rooted
  com.noshufou.android.su
com.thirdparty.superuser
eu.chainfire.supersu
com.koushikdutta.superuser
• 检查SU二进制文件
  /system/bin/su
/system/xbin/su
/sbin/su
/system/su
/system/bin/.ext/.su
• 直接尝试SU命令
  尝试运行命令su并检查当前用户的id，如果返回0则su命令成功

8.3.2. IOS 越狱检测

9. M- Reverse Engineering（逆向）

攻击者通常会从应用商店下载目标应用，并使用一套不同的工具在自己的本地环境中对其进行分析

9.1. 影响

• 显示有关后端服务器的信息
• 显示加密常量和密码
• 窃取知识产权
• 对后端系统进行攻击
• 修改代码并执行获得所需信息
• 知识产权盗窃
• 声誉损害
• 身份盗窃
• 后端系统的妥协？？？

9.2. 常见类型

如果代码存在以下问题，则表示应用是容易被逆向的：清楚地理解二进制字符串表的内容、准确地执行跨功能分析、从二进制文件中获得相当准确的源代码并重新创建
1、保留的符号表
使用file、readelf等系统工具对so文件进行分析：如果保留了符号表则不安全
2、反编译
使用反编译工具、反汇编软件对其反编译测试；若应用程序能够被反编译、关键代码没有被混淆则为高危风险；若应用程序将代码做了混淆保护，但关键代码仍然够被反编译并且逻辑可读，根据可读程度定为中/低危风险；应用不能被反编译为安全

9.3. 避免方式

1、混淆
2、加固

10. M- Extraneous Functionality（无关功能）

开发人员包括隐藏的后门功能或其他不打算发布到生产环境中的内部开发安全控件，此风险的定义特征是在应用程序中启用了不打算发布的功能
留存的测试组件

10.1. 影响

• 暴露后端系统的工作方式

10.2. 常见类型

• 开发人员可能会在混合应用程序中意外地将密码作为注释包含在内
• 测试期间禁用双因素身份验证
• 未经授权访问敏感功能
• 声誉损害
• 知识产权盗窃

10.3. 避免方式

防止此漏洞的最佳方法是使用此代码最知情的安全冠军或主题专家执行手动安全代码审查。他们应该做以下事情：

• 检查应用程序的配置设置以发现任何隐藏的开关
• 验证所有测试代码未包含在应用程序的最终生产版本中
• 检查移动应用程序访问的所有API端点，以验证这些端点是否已完整记录并可公开获取
• 检查所有日志语句，以确保没有对后端写入日志的过度描述