Skip to main content

安全

sql 注入​

攻击者在 web 应用的输入参数中注入恶意 SQL 代码，从而执行未授权的数据库操作，比如，访问、删除、修改数据。
防御方法：

  • 参数化查询，输入验证。
    • 移除或转义特殊字符，比如单引号。
    • 校验输入。
    • 不拼接 SQL，比如使用 ORM 框架的参数化查询。
  • 限制数据库权限
    • 不能使用 root 用户。为数据库用户分配最小的必要权限。
  • 定期进行安全审计和漏洞扫描。

XSS​

Cross-Site Scripting (XSS) 是一种注入类攻击，指攻击者通过在网页中注入恶意脚本，当用户浏览网页时，恶意脚本执行，控制用户浏览器行为的一种攻击方式。

主要分类：​

反射型，Reflected XSS Attacks​

攻击者诱导用户访问一个带有恶意代码的 URL 后，服务器端接收数据后处理，然后把带有恶意代码的数据发送到浏览器端，浏览器端解析这段带有 XSS 代码的数据后当做脚本执行，最终完成 XSS 攻击。 因为这个过程就像一次反射，故称为 反射型 XSS 。

攻击步骤

  1. 攻击构造出特殊的 URL ，其中包含恶意代码。
  2. 用户被诱导打开带有恶意代码的 URL ，服务器端将恶意代码从 URL 中取出当做参数处理，然后返回给用户带有恶意代码的数据。
  3. 用户浏览器接收到响应解析执行，混在其中的恶意代码也被执行。
  4. 恶意代码窃取用户敏感数据发送给攻击者，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

存储型，Stored XSS Attacks​

当浏览器请求数据时，脚本从服务器传回并执行。它是最危险的一种跨站脚本，比 反射性XSS和 DOM型XSS 都更有隐蔽性，因为它不需要用户手动触发。任何允许用户存储数据的 Web 程序都可能存在存储型 XSS 漏洞。若某个页面遭受存储型 XSS 攻击，所有访问该页面的用户都会被 XSS 攻击 。

存储型 XSS 跟 反射型 XSS 的区别是：

  • 存储型 XSS 的恶意代码存在服务器上， 反射型 XSS 的恶意代码存在 URL 里。
  • 存储型 XSS 攻击时恶意脚本会存储在目标服务器上。

攻击步骤

  1. 攻击者把恶意代码提交到目标网站的服务器中。
  2. 用户打开目标网站，网站服务器端把带有恶意代码的数据取出，当做正常数据返回给用户。
  3. 用户浏览器接收到响应解析执行，混在其中的恶意代码也被执行。
  4. 恶意代码窃取用户敏感数据发送给攻击者，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

DOM 型，DOM Based XSS。​

DOM 型 XSS 形成原因是通过修改页面的 DOM 节点形成的 XSS。 DOM 型 XSS 攻击中，取出和执行恶意代码都由浏览器端完成，属于前端自身的安全漏洞。

攻击步骤

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。
  2. 用户被诱导打开带有恶意代码的 URL。
  3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

防范​

Content Security Policy​

严格的 CSP 在 XSS 的防范中可以起到以下的作用：

  • 禁止加载外域代码，防止复杂的攻击逻辑。
  • 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
  • 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。
  • 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。
  • 合理使用上报可以及时发现 XSS，利于尽快修复问题。

输入检查​

不要相信用户的任何输入。 对于用户的任何输入要进行检查、过滤和转义。

  • 建立可信任的字符和 HTML 标签白名单，对于不在白名单之列的字符或者标签进行过滤或编码。
  • 在 XSS 防御中，输入检查一般是检查用户输入的数据中是否包含 <，> 等特殊字符，如果存在，则对特殊字符进行过滤或编码，这种方式也称为 XSS Filter。
const decodingMap = {
  '<': '<',
  '>': '>',
  '"': '"',
  '&': '&',
  ' ': '\n'
}

输出检查​

用户的输入会存在问题，服务端的输出也会存在问题。一般来说，除富文本的输出外，在变量输出到 HTML 页面时，可以使用编码或转义的方式来防御 XSS 攻击。例如利用 sanitize-html对输出内容进行有规则的过滤之后再输出到页面中。