防止常见的Web攻击开发方法

概述

讨论一些应用程序常见漏洞类别：

建议

• Clickjacking
  发生在攻击者使用 iframe 诱使使用者在打算点选页面时、按钮或连结时，使使用者在只有使用者有权存取的页面上执行敏感操作。

  • 问题范例
    攻击者现在可以在其网站上包含一个隐藏的 iframe：

      <iframe src = "https://hide" style = "opacity：100"></iframe>
    

  • 修正方法
    设置以下 HTTP 回应标头(Request Header)：

      X-Frame-Options：DENY
    

  • 参考资料
    https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

• HTTP 安全标头
  浏览器正在尝试帮助解决Web应用程序中常见的安全问题。
  并考虑向後兼容性，因为Internet上仍有一些既有格式的网站可能有相容性的问题。
  使用HTTP安全标头可以选择启用浏览器中的一些新安全功能，以充分利用现代浏览器的安全性。

  • 问题范例
    几乎所有的Web应用程序都从 HTTP->HTTPS 重定向，从而使使用者在存取您的网站时不必在URL的开头键入 https：//。
    但如果使用者已经在站点上取得了 Session，则浏览器可能会在重定向前的第一个HTTP请求上发送一些敏感讯息。
  • 修正方法
    在专案的早期阶段添加标题，并确保选择对内容安全策略友好的现代前端技术。
  • 风险等级
    添加安全标头是基本的安全措施，Mozilla等组织要求其所有应用程序都必须实现它们。
  • 参考资料
    Mozilla在这里有一个很好的Web安全指南参考，其中包括许多有关安全标头的讯息：
    https://infosec.mozilla.org/guidelines/web_security

• 防止XSS
  XSS或跨站点Script是常见的Web应用程序漏洞。
  该漏洞使攻击者可以通过向应用程序中注入JavaScript或HTML来修改应用程序的前端行为，从而更改恶意行为的预期行为。
  XSS漏洞可能它们可用於窃取敏感讯息，例如凭证，Session Token或信用卡资料。
  它可以用来绕过防火墙并存取内部网路，例如办公网路，因为它允许攻击者的程序码在受害者的浏览器中运行，而该浏览器很可能在办公室的计算机上运行或通过VPN连接。
  或通过注入浏览器利用程序码直接攻击浏览器，或者如最近所看到的那样，通过加密货币挖掘程序码注入到无辜的网站中来窃取计算能力来挖掘加密货币。

  • 问题范例
    通常，问题是由页面中包含的输入字段或URL参数引起的，例如：

      https://www.application.com/newuser?name=<script>alert(1)</script>
    

    如果该参数最终被应用程序视为HTML，则会弹出一个警告框，以证明我们可以注入JavaScript。

  • 修正方法
    预防XSS是一个范围很大的主题：
    - 选择预设情况下支持输出程序码的前端框架。
    - 清理来自使用者和其他应用程序的所有输入，并拒绝意外的输入。
    - 实施不允许使用JavaScript的内容安全策略。
    解决此问题的第一个也是最好的方法是使用预设情况下输出程序码及转义资料的前端框架，这使任何开发人员都很难犯不处理恶意输入的错误。
    有更多的框架具有很好的预设XSS预防功能，使用了这两个框架，它们已得到Google和Facebook等大公司的支持和使用。
    可选的前端框架很多，因为考虑到这些缺陷，在设计XSS漏洞时将更加困难：
    - https://angular.io/guide/security#xss
    - https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks
    请确保您的应用程序清理了所有传入的资料。
    这需要在服务器上完成才能使其生效。
    资料可以来自许多来源，包括但不限於使用者直接输入或来自其他应用程序的资料。
    例如，如果您希望输入电话号码，请确保程序验证应用程序仅接受预期的资料，例如数字，破折号和国家程序码的+。

    有一些函式库可以提供帮助，例如Active Record Validation等。
    我们可以实现一种针对所有现代浏览器都支持的XSS问题的保护机制。
    内容安全策略可以有效地限制XSS漏洞的影响，即使这些漏洞在您的应用程序中发生，即使在您输出程序码资料并清理输入後也是如此。

    通过精心设计CSP，我们可以告诉浏览器哪些Script可以运行，哪些Script不允许运行。
    我们可以限制允许应用程序从中载入JavaScript资源的位置，并且我们可以禁止任何行内JavaScript。
    通过利用XSS漏洞注入的恶意JavaScript通常最终会内嵌在HTML文档中，而不是在外部.js文件中，因此，如果我们指示浏览器不允许使用行内JavaScript，则可以避免许多常见的XSS漏洞。

    仅允许应用程序所在域中的Script文件的策略范例如下所示：
    Content-Security-Policy:："script-src'self'"

  • 风险等级
    XSS漏洞非常普遍，根据情况和应用情况，其构成中等到高风险。
    这是一个漏洞类别，需要应用程序安全团队提供大量资源来处理，除非该应用程序设计良好，并且我们想在应用程序中消除该漏洞类别。

  • 参考资料

    • https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
    • https://csp.withgoogle.com/

• 防止SQL注入
  SQL注入是一个古老的漏洞类别，它使攻击者能够更改应用程序的SQL查询，以执行开发人员未计划的其他操作。
  出现此问题是由於资料和程序码之间缺乏分隔，使攻击者无法输入资料r查询的逻辑。
  即使在现代Web应用程序中，仍然存在SQL注入漏洞，这会导致资料丢失，身份验证绕过和服务器受损。

  发现甚至不使用传统关系资料库的应用程序也容易受到SQL注入的攻击。
  如果使用使用者输入来构建资料库查询，则攻击者可能会更改正在进行的查询并绕过身份验证，从而意外存取资料或执行远程程序码。

  保护资料免受攻击者对於任何资料驱动的公司而言都是至关重要的，保护我们的Web应用程序免受SQL注入是防止资料被盗的非常重要的部分。
  多年来发现的许多漏洞是由Web应用程序中的SQL注入引起的，从而导致服务器受到完全破坏或对资料库中所有资料的存取。

  • 问题范例
    该漏洞都使我们能够存取和提取应用程序资料库的所有内容。
  • 修正方法

    • 关联资料库(PostgreSQL等)
      所有SQL查询都应该是参数化查询，具体语法会根据所使用的技术堆叠而有所不同：
      SELECT * FROM users where username like '%'
      限制资料库使用者的权限。
      永远不应以资料库管理员或root/admin使用者身份运行应用程序SQL查询。
      使用对象关系映射器(ORM)可以帮助您安全地构建查询，还可以减轻编写原始SQL查询的麻烦。

    • NoSQL资料库(MongoDB，CouchDB等)

      几乎相同的原理适用於保护应用程序免受noSQL注入：

      清理查询中使用的使用者输入。
      根据正则表达式或白名单检查输入的类型(字串，位元组等)以及所需的格式。
      将资料库使用者的权限限制到最小。

  • 风险等级
    SQL注入漏洞的严重性从高到严重不等，具体取决於应用程序和上下文。例如，身份验证提供程序中的SQL注入将是一个严重漏洞，因为它可能导致所有使用者资料受到损害，并有可能绕过存取控制。
  • 参考资料
    • https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
    • https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html

• 防止跨站请求伪造
  跨站点请求伪造攻击使攻击者可以在经过身份验证的使用者的上下文中在应用程序中执行操作。
  通过滥用cookie的工作方式，如果应用程序的身份验证是基於cookie的(例如，Session Cookie被储存并随每个请求一起发送)，则攻击者可以设置一个网站，例如通过iframe，图像或通过自动发布一些表单资料，浏览器将发送使用者的Cookie。
  此攻击是从www.malicious.com到不同来源进行的，因此，由於“同源规则"，攻击者将无法读取跨域请求的回应。
  但是，如果应用程序仅需要Session Cookie，并且不验证请求是否来自预期域，则成功攻击就没有必要了。

  当使用者浏览有趣的猫图片而没有任何怀疑时，攻击可能会在恶意网站的後台发生。
  可利用的行为可以是应用程序允许的任何事情，例如更改密码，更改收货地址，删除使用者或可能用於攻击者利益的其他任何事情。

  攻击通常针对单个使用者帐户，但是如果该使用者帐户是应用程序的管理员，则业务後果可能非常严重。

  • 问题范例

    我们用於网路团队进行部署的内部遗留系统过去很容易受到跨站点请求伪造的攻击。由於两个缺陷的结合，网路外部的攻击者有可能触发部署，甚至在服务器上获得程序码执行。

  • 修正方法

    有几种解决此问题的策略，这在某种程度上取决於应用程序的体系结构。
    以下是最常用的主要策略，被视为解决此问题的标准方法：

    • 通过HTTP标头进行身份验证
      一些身份验证API使用“身份验证：承载<Token到此处>"标头进行身份验证。需要身份验证标头才能成功的请求不容易受到CSRF攻击。

    • CSRF Token
      这是最常见和公认的保护机制。它通过要求每个表单提交和执行操作的请求来在提交的资料中包含随机CSRF Token的方式工作。由於此Token是由服务器设置和储存的，并且与使用者的Session相关联，因此攻击者将无法存取或猜测它。这样可以防止CSRF攻击成功，因为服务器应拒绝任何没有有效Token的请求。
      首先要确保您的应用程序正确使用了HTTP GET和POST动词，请参阅http://guides.rubyonrails.org/security.html#csrf-countermeasures

      接下来，您应该查看您的Web应用程序框架，以了解它们是否支持CSRF Token。大多数框架，例如上面提到的Ruby on Rails，都将具有内置支持以轻松添加CSRF Token或支持实现它的库。以下是NodeJS和Golang的两个流行选项：
      - https://github.com/expressjs/csurf
      - https://github.com/utrack/gin-csrf

    • 检查来源/引荐标头_

      这是可以用来防止CSRF攻击的另一种方法。此方法依赖於检查请求的"Origin"标头，以确保该请求标头来自承载应用程序的来源，而不是恶意域。
      只允许浏览器设置"Origin"标头，以防止恶意应用程序对其进行欺骗。
      它不像使用CSRF Token那样，因为浏览器不必(但可以)设置RFC-6454中指定的原始标头。

      通常将此检查与检查请求的"referer"标头结合在一起。
      "引荐来源"标头还由浏览器专门设置，并且包含请求所源自的URL或域。
      应用程序可以检查此标头是否设置为正确的域，以确保请求来自使用者Session，而不是来自恶意域。

    • Samesite Cookies
      这是防止CSRF的机制。
      它是一种新的浏览器功能，允许使用标记来标记cookie，该标记控制从第三方站点发起的请求是否将包含cookie。

      有两种模式：严格和宽松。
      严格模式可防止浏览器针对任何请求发送cookie跨域。在登录使用者点选连结返回到应用程序中经过身份验证的页面的情况下，这可能会带来负面影响，因为将不会发送Cookie，并且使用者需要重新进行身份验证。
      松散模式可防止这种情况，并允许GET请求与cookie一起发送。使用任何其他HTTP动词的请求都不会随Cookie一起发送。如果应用程序适当地使用了HTTP动词，那麽通常就足以防止CSRF攻击，因为该应用程序不应使用GET请求在应用程序中执行任何操作。

        -设置宽松模式：`Set-Cookie：CookieName = CookieValue; SameSite = Lax;`
        -设置严格模式：`Set-Cookie：CookieName = CookieValue; SameSite =严格;`
      

  • 风险等级
    上例显示了严重的CSRF漏洞。
    根据应用程序的不同，CSRF漏洞的影响范围可能从低到严重。
    CSRF攻击通常是针对性的，需要针对特定应用进行定制，但是在常用函式库和框架中也存在CSRF漏洞，攻击者可以利用这些漏洞同时将多个站点作为目标。

  • 参考

    • https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
    • https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/

• 凭证泄漏
  应用程序开发需要与越来越多的服务整合。
  这要求开发人员处理许多机密讯息：资料库凭证，API Token，oauth机密讯息等。
  这些讯息应具有高熵，每个服务和每个环境都是唯一的，从而导致需要管理大量机密讯息。
  这些通常最终储存在配置文件中，然後意外地将其检入可公开存取的云托管资料库中您喜欢的版本控制系统，并因此将其检入攻击者的手中。

  机密是出於某种原因而机密的，通常可以提供对许多资料，计算资源或特权帐户的存取。
  因此，至关重要的是我们要处理e的机密很好，并且使意外泄漏的可能性尽可能小。

  • 问题范例

    到Github的凭证泄漏是业内常见且麻烦的问题。
    这可以使恶意行为者存取内部系统，资料，API等。

    • 修正方法
      开发应用程序时，最佳做法是从环境变量中载入机密。
      • 将凭证储存在运行程序的记忆体位置中，这意味着服务器上的其他没有权限的使用者帐户将无法存取凭证。
      • 将机密与您的应用程序常规配置文件分开，这些文件经常被检入版本控制系统中。
        开发应用程序时，在本地运行应用程序之前，使用.env文件储存机密并将其载入到环境中。
      • 将机密集中储存在安全的地方。
      • 应用程序安全团队拥有监视原始码资料库中机密的工具，但该机制仅应作为最後一道防线，为避免凭证泄漏。
      • 凭证泄漏很关键，因为它们通常会授予系统的高级别存取权限，并可能导致资料和系统受损。