OWASP Top 10 （二）

[PyxYuYu]

There is more to life than increasing its speed.

0x01 OWASP Top 10

---

• 敏感信息泄漏
  • 威胁代理：考虑谁可以访问您的敏感数据和这些数据的备份，这包括静态数据、传输中的数据甚至是客户浏览器中的数据
  • 攻击向量： 攻击者通常不直接攻击加密系统，他们往往通过诸如窃取密钥、发起中间人攻击或从服务器窃取明文数据等方式对传输中的或者客户浏览器中的数据进行破解
  • 安全漏洞：在这个领域中最常见的漏洞是应该加密的数据没有进行加密，在使用加密的情况下，常见的问题是不安全的密钥生成和管理和使用弱算法，特别是弱的哈希算法来保护密码，浏览器的漏洞也很普遍，且可以很容易的检测到，但是很难大规模的利用，外部攻击者因访问的局限性很难探测这种漏洞，并且难以利用
  • 技术影响：这个领域的错误频繁影响那些本应该加密的数据，通常包括很多敏感数据，比如医疗记录、认证凭证、个人隐私数据、信用卡信息等
  • 漏洞检测
    • 首先需要确认哪些数据是敏感数据而需要被加密，例如：密码、信用卡、医疗记录、个人信息
    • 当这些数据被长期存储时，无论存储在哪里，它们是否都被加密、特别是对这些数据的备份
    • 无论内部数据还是外部数据，传输时是否是明文传输，在互联网中传输明文数据是非常危险的
    • 是否还在使用任何旧的或脆弱的加密算法
    • 加密密钥的生成是否是脆弱的，或者缺少恰当的密钥管理或缺少密钥回转
    • 当浏览器接收或发送敏感数据时，是否有浏览器安全指令或头文件丢失
  • 漏洞防护
    • 对于一些需要加密的敏感数据，应该起码做到以下几点：
      • 预测一些威胁（比如内部攻击和外部用户），加密这些数据的存储以确保免受这些威胁
      • 对于没必要存放的、重要的敏感数据，应当尽快清楚
      • 确保使用了合适的强大的标准算法和强大的密匙，并且密匙管理到位
      • 确保使用密码专用算法存储密码
      • 禁用自动完成防止敏感数据收集，禁用包含敏感数据的缓存页面
• 功能级访问控制缺失
  • 威胁代理：任何具有网络访问权限的人都可以向你的应用程序发送一个请求，匿名用户是否可以访问私人网页，普通用户是否可以访问有特权的网页
  • 攻击向量：攻击者是被授权的系统用户，很容易把网址更改成享有特权的网页，这样的访问是否会被允许，匿名用户是否可以访问未受保护的私人网页
  • 安全漏洞：应用程序并不总是能正确地保护页面请求，有时功能级的防护是通过配置来管理的，而系统的配置是错误的，开发人员必须做相应的代码检查，然而，有时他们忘记了，检测这些漏洞是很容易的，最难的是确定应用程序存在哪些可被攻击的网页或者链接（URL）
  • 技术影响：这种漏洞允许攻击者访问未经授权的功能，管理性的功能是这类攻击的主要目标
  • 漏洞检测
    • 检查应用程序是否正确的限制了功能级的访问的最好方法是验证每一个应用程序的功能
      • 用户界面是否存在未授权功能的导航
      • 服务器端的身份认证或授权功能是否完善
      • 服务器端的检查是否仅仅依赖于攻击者提供的信息
    • 开启代理的情况下，先以特权用户身份浏览一遍您的功能，然后以普通用户身份再次访问受限页面，如果服务器的响应很类似，您的应用很可能容易受到攻击，一些测试代理直接支持此种类型的分析
    • 也可以检查代码中的访问控制的实现，试着以一个单一的特权请求贯穿代码并验证授权模式，然后搜索代码库中没有遵循该模式的地方，自动化工具不太可能发现这些问题
  • 漏洞防护
    • 应用程序应该使用一致的和易于分析的授权模块，并能在所有的业务功能中调用该模块，通常是，由一个或多个外部组件向应用代码内部提供这种保护
      • 考虑一下管理权利的过程并确保能容易的进行升级和审计，切忌硬编码
      • 执行机制在缺省情况下，应该拒绝所有访问，对于每个功能的访问，需要明确授予特定角色的访问权限
      • 如果某功能参与了工作流程，检查并确保当前的条件是授权访问此功能的合适状态
    • 多数 Web 应用并不显示未授权功能的链接和按钮，可是这种 展现层访问控制 实际上并不提供防护，必须还要实现控制或业务逻辑层面的检查
• 跨站请求伪造（CSRF）
  • 威胁代理：考虑可能将内容载入你用户的浏览器并迫使他们向你的网站提交请求的任何人，你的用户所访问的任何网站或 HTML 源（feed）都可以这样做
  • 攻击向量：攻击者创建伪造 HTTP 请求并通过图片标签、跨站脚本或许多其他技术诱使受害用户提交这些请求，如果受害用户已经经过身份认证，那么攻击就能成功
  • 安全漏洞：CSRF 是利用某些 Web 应用程序允许攻击者预测一个特定操作的所有细节这一特点。由于浏览器自动发生会话 cookie 等认证凭证，攻击者能创建恶意 Web 页面产生伪造请求，这些伪造请求很难与合法请求区分开，跨站请求伪造漏洞可以很容易通过渗透测试或代码分析检测到
  • 技术影响：攻击者能欺骗受害用户完成该受害者所允许的任意状态改变的操作，比如：更新帐号细节，完成购物，注销甚至登录等操作
  • 漏洞检测
    • 检测应用程序是否存在该漏洞的方法是查看是否每个链接和表单都提供了不可预测的 CSRF 令牌，没有这样的令牌，攻击者就能伪造恶意请求
    • 另一种防御的方法是要求用户证明他们要提交请求，可以通过重新认证的方式或者其他能够证明他们是真实用户的方法（比如：CAPTCHA）
    • 重点关注那些调用能够改变状态功能的链接和表格，因为他们是跨站请求伪造攻击的最重要的目标
    • 由于多步交易并不具备内在的防攻击能力，因此我们需要检测这些交易，攻击者能轻易使用多个标签或 JavaScript 伪造一系列请求
    • 注意：会话 cookie、源 IP 地址和其他浏览器自动发送的信息不能作为防攻击令牌，因为这些信息已经包含在伪造的请求中
  • 漏洞防护
    • 防止跨站请求伪造，通常需要在每个 HTTP 请求中添加一个不可预测的令牌，这种令牌至少应该对每一个用户会话来说是唯一的
      • 最好的方法是将独有的令牌包含在一个隐藏字段中，这将使得该令牌通过 HTTP 请求体发送，避免其包含在 URL 中从而被暴露出来
      • 该独有令牌同样可以包含在 URL 中或作为一个 URL 参数，但是这种方法的巨大风险在于： URL 会暴露给攻击者，这样秘密令牌也会被泄漏
      • 要求用户重新认证或者证明他们是一个真实的用户
• 使用含有已知漏洞的组件
  • 威胁代理：一些含有漏洞的组件（如：框架库）可以被自动化工具发现和利用，这是的威胁代理部分引入了混乱的角色，而不仅仅是攻击者了
  • 攻击向量：攻击者通过扫描或手动分析识别问题组件，然后根据需要定制攻击代码并实施攻击，在应用中使用组件越深入，实施攻击的难度越大
  • 安全漏洞：事实上，大多数的应用都存在这些问题，因为大多数的开发团队并不会及时更新组件/库作为他们的工作重心，在很多情况下，开发者都不了解他们所使用的全部组件，更不用说组件的版本了，组件的依赖性使情况更加糟糕
  • 技术影响：可能是由低到高全系列的漏洞，包括注入，破损的访问控制，跨站脚本等，受影响范围也从最低的受损到主机被完全接管和数据的泄漏
  • 漏洞防护
    • 使用最新版的组件
• 未验证的重定向和转发
  • 威胁代理：考虑所有能诱使你的用户向你的网站递交请求的人，你的用户使用的任何网站或其他 HTML 源（feed）都可以这样做
  • 攻击向量：攻击者链接到未验证的重定向并诱使受害者去点击，由于链接到有效的网站，受害者很有可能去点击，攻击者利用不安全的转发绕过安全检测
  • 安全漏洞：应用程序经常将用户重定向到其他网页，或以类似的方式进行内部转发。有时，目标网页是通过一个未验证的参数来指定的，这就允许攻击者选择目标页面。检测未经验证的重定向很容易，只需寻找那些允许你指定整个 URL 的重定向，但检测未经验证的转发困难些，因为它们的目标是内部网页
  • 技术影响：这种重定向可能试图安装恶意软件或者诱使受害者泄漏密码或其他敏感信息，不安全的转发可能允许绕过访问控制
  • 漏洞检测
    • 审查所有使用重定向或转发（在 .NET 中称为转移）的代码，每一次使用，都应验证目标 URL 是否被包含在任何参数值中，如果是，且目标 URL 并不在经过验证的白名单中，那么就是存在漏洞的
    • 抓取网站内容查看是否能产生重定向（HTTP 响应代码从300到307，通常是302），检查重定向之前提供的参数是否是目标 URL 或其一部分，如果是的话，更改 URL 的目的地，并观察网站是否重定向到新的目标
    • 如果没有代码，检查所有的参数以辨别它们是否看起来像一个重定向或转发目的地网址的一部分，对那些看起来像的参数进行测试
  • 漏洞防护
    • 避免使用重定向和转发
    • 如果使用了重定向和转发，则不要在计算目标时涉及到用户参数
    • 如果使用目标参数无法避免，应确保其所提供的值对于当前用户是有效的，并已经授权，建议把这种目标的参数做成一个映射值，而不是真的 URL 或其中一部分，然后由服务器端代码将映射值转化成目标 URL。应用程序可以使用 ESAPI 重写 sendRedirect() 方法来确保所有重定向的目的地是安全的