`安全`性：`SQL`注入、`XSS`和`CSRF`攻击的`预防`。

安全性：SQL 注入、XSS 和 CSRF 攻击的预防

各位同学，大家好！今天我们来探讨 Web 应用安全领域中三个最常见的威胁：SQL 注入 (SQL Injection)、跨站脚本 (Cross-Site Scripting, XSS) 和跨站请求伪造 (Cross-Site Request Forgery, CSRF)。我们将深入了解这些攻击的原理、危害以及如何有效地预防它们。

1. SQL 注入 (SQL Injection)

SQL 注入是指攻击者通过在应用程序的输入中注入恶意的 SQL 代码，从而干扰或篡改应用程序与数据库之间的交互。攻击者可能能够绕过身份验证、读取敏感数据、修改数据甚至执行管理操作。

1.1 原理

应用程序在构建 SQL 查询时，如果直接将用户提供的输入拼接到 SQL 语句中，而没有进行充分的验证和过滤，就可能导致 SQL 注入漏洞。

1.2 示例

假设我们有一个登录页面，使用以下 SQL 查询来验证用户名和密码：

SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

如果攻击者在 username 字段中输入 admin' --，在 password 字段中随意输入，最终的 SQL 查询将变为：

SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything';

-- 是 SQL 中的注释符号，后面的所有内容都会被忽略。因此，这个查询实际上变成了：

SELECT * FROM users WHERE username = 'admin';

这将返回 username 为 admin 的用户的所有信息，攻击者就成功绕过了身份验证。

1.3 预防措施

• 使用参数化查询 (Parameterized Queries) 或预编译语句 (Prepared Statements): 这是防止 SQL 注入最有效的方法。参数化查询允许将用户输入作为参数传递给 SQL 查询，而不是直接将其拼接到 SQL 语句中。数据库驱动程序会自动处理参数的转义，确保用户输入不会被解释为 SQL 代码。

  // Java 示例
  String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
  PreparedStatement preparedStatement = connection.prepareStatement(sql);
  preparedStatement.setString(1, username);
  preparedStatement.setString(2, password);
  ResultSet resultSet = preparedStatement.executeQuery();

  # Python (psycopg2) 示例
  sql = "SELECT * FROM users WHERE username = %s AND password = %s"
  cur.execute(sql, (username, password))

  // PHP (PDO) 示例
  $sql = "SELECT * FROM users WHERE username = :username AND password = :password";
  $stmt = $pdo->prepare($sql);
  $stmt->bindParam(':username', $username);
  $stmt->bindParam(':password', $password);
  $stmt->execute();

• 输入验证和清理: 即使使用参数化查询，仍然建议对用户输入进行验证和清理。验证输入是否符合预期格式，例如长度限制、字符类型等。清理输入可以移除不必要的字符或转义特殊字符。

  // Java 示例：输入验证
  if (username == null || username.length() > 50 || !username.matches("[a-zA-Z0-9]+")) {
      // 处理无效的 username
      throw new IllegalArgumentException("Invalid username");
  }

  # Python 示例：输入验证
  if not isinstance(username, str) or len(username) > 50 or not re.match(r"^[a-zA-Z0-9]+$", username):
      # 处理无效的 username
      raise ValueError("Invalid username")

  // PHP 示例：输入验证
  if (!is_string($username) || strlen($username) > 50 || !preg_match('/^[a-zA-Z0-9]+$/', $username)) {
      // 处理无效的 username
      throw new Exception("Invalid username");
  }

• 最小权限原则: 应用程序使用的数据库用户应该只拥有执行必要操作的最小权限。例如，如果应用程序只需要读取数据，则数据库用户不应该拥有写入或删除数据的权限。

• 错误处理: 不要在错误消息中暴露敏感信息，例如数据库结构或查询细节。自定义错误页面，向用户显示友好的错误信息，并将详细的错误信息记录到日志中。

• Web 应用防火墙 (WAF): WAF 可以检测和阻止 SQL 注入攻击。WAF 通过分析 HTTP 请求和响应，识别恶意 SQL 代码并阻止其到达数据库。

1.4 总结

SQL 注入是一种非常危险的攻击，但通过使用参数化查询、输入验证和最小权限原则等措施，可以有效地预防它。

2. 跨站脚本 (Cross-Site Scripting, XSS)

XSS 攻击是指攻击者将恶意脚本注入到受信任的网站中，当其他用户访问该网站时，这些脚本会在用户的浏览器中执行。攻击者可以利用 XSS 攻击窃取用户的 Cookie、会话信息，甚至重定向用户到恶意网站。

2.1 原理

XSS 攻击的发生通常是因为应用程序没有对用户提供的输入进行充分的编码或转义，导致恶意脚本被当作 HTML 代码执行。

2.2 类型

• 存储型 XSS (Stored XSS): 恶意脚本被存储在服务器上，例如数据库、文件系统等。当其他用户访问包含恶意脚本的页面时，脚本会被执行。

• 反射型 XSS (Reflected XSS): 恶意脚本通过 URL 参数、表单提交等方式传递给服务器，服务器再将恶意脚本返回给用户。攻击者通常需要诱骗用户点击包含恶意脚本的链接。

• DOM 型 XSS (DOM-based XSS): 恶意脚本不经过服务器，而是直接在用户的浏览器中执行。攻击者通过修改 DOM 结构来注入恶意脚本。

2.3 示例

假设我们有一个搜索页面，用户输入搜索关键词后，页面会显示搜索结果，并显示用户输入的关键词。

<p>您搜索的关键词是：<?php echo $_GET['keyword']; ?></p>

如果攻击者在 keyword 字段中输入 <script>alert('XSS')</script>，最终的 HTML 代码将变为：

<p>您搜索的关键词是：<script>alert('XSS')</script></p>

当用户访问这个页面时，浏览器会执行 <script>alert('XSS')</script>，弹出一个警告框。

2.4 预防措施

• 输出编码 (Output Encoding): 这是防止 XSS 攻击最有效的方法。在将用户提供的输入显示在 HTML 页面上之前，必须对其进行适当的编码。编码的目的是将特殊字符转换为 HTML 实体，例如将 < 转换为 <，将 > 转换为 >。

  • HTML 编码: 用于编码 HTML 元素的内容，例如文本、属性值等。
  • URL 编码: 用于编码 URL 中的参数。
  • JavaScript 编码: 用于编码 JavaScript 代码中的字符串。
  • CSS 编码: 用于编码 CSS 样式表中的字符串。

  // PHP 示例：HTML 编码
  echo htmlspecialchars($_GET['keyword'], ENT_QUOTES, 'UTF-8');

  # Python (Jinja2) 示例：HTML 编码 (Jinja2 默认进行 HTML 自动转义)
  {{ keyword|e }}

  // Java 示例：使用 Apache Commons Text 进行 HTML 编码
  String encodedKeyword = StringEscapeUtils.escapeHtml4(keyword);
  System.out.println(encodedKeyword);

• 输入验证和清理: 与 SQL 注入类似，对用户输入进行验证和清理也是必要的。验证输入是否符合预期格式，例如长度限制、字符类型等。清理输入可以移除不必要的字符或转义特殊字符。

• 内容安全策略 (Content Security Policy, CSP): CSP 是一种 HTTP 响应头，允许网站管理员控制浏览器可以加载哪些资源。通过配置 CSP，可以限制浏览器只能加载来自特定来源的脚本、样式表等，从而减少 XSS 攻击的风险。

  Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;

  这个 CSP 指令表示：

  • default-src 'self': 默认情况下，只允许加载来自相同来源的资源。
  • script-src 'self' https://example.com: 允许加载来自相同来源和 https://example.com 的脚本。
  • style-src 'self' https://example.com: 允许加载来自相同来源和 https://example.com 的样式表。
  • img-src 'self' data:: 允许加载来自相同来源的图片，以及使用 data URI 嵌入的图片。

• HTTPOnly Cookie: 将 Cookie 设置为 HTTPOnly，可以防止 JavaScript 访问 Cookie。这样可以减少 XSS 攻击窃取 Cookie 的风险。

  // PHP 示例：设置 HTTPOnly Cookie
  setcookie('session_id', $session_id, ['httponly' => true, 'secure' => true, 'samesite' => 'Strict']);

  // JavaScript (尝试访问 HTTPOnly Cookie，会失败)
  document.cookie //  只会显示非 HTTPOnly 的 Cookie

  • httponly => true: 设置 Cookie 为 HTTPOnly。
  • secure => true: 设置 Cookie 只能通过 HTTPS 连接传输。
  • samesite => 'Strict': 设置 Cookie 的 SameSite 属性为 Strict，进一步防止 CSRF 攻击。

• Web 应用防火墙 (WAF): WAF 可以检测和阻止 XSS 攻击。WAF 通过分析 HTTP 请求和响应，识别恶意脚本并阻止其执行。

2.5 总结

XSS 攻击是一种常见的 Web 应用安全威胁，但通过使用输出编码、输入验证、CSP 和 HTTPOnly Cookie 等措施，可以有效地预防它。

3. 跨站请求伪造 (Cross-Site Request Forgery, CSRF)

CSRF 攻击是指攻击者诱骗用户在不知情的情况下，以用户的身份执行恶意操作。攻击者通常通过构造恶意链接或表单，诱骗用户点击或提交，从而在用户的浏览器中发起恶意请求。

3.1 原理

CSRF 攻击利用了浏览器会自动发送 Cookie 的特性。当用户访问一个恶意网站时，如果用户已经登录了受信任的网站，恶意网站可以构造一个指向受信任网站的请求，并在用户的浏览器中发送该请求。由于浏览器会自动发送受信任网站的 Cookie，受信任网站会将该请求视为合法请求，并执行相应的操作。

3.2 示例

假设用户已经登录了银行网站，并且银行网站提供了一个转账功能。转账的 URL 如下：

https://bank.example.com/transfer?account=recipient&amount=100

如果攻击者构造一个恶意链接：

<img src="https://bank.example.com/transfer?account=attacker&amount=1000" width="0" height="0">

当用户访问包含这个恶意链接的网站时，用户的浏览器会自动向银行网站发送一个转账请求，将 1000 元转账给攻击者。由于用户的浏览器会自动发送银行网站的 Cookie，银行网站会将该请求视为合法请求，并执行转账操作。

3.3 预防措施

• 同步令牌 (Synchronizer Token Pattern, STP): 这是防止 CSRF 攻击最常用的方法。STP 的原理是在服务器端为每个用户的会话生成一个唯一的随机令牌 (CSRF token)，并将该令牌嵌入到 HTML 表单中。当用户提交表单时，服务器会验证表单中的 CSRF token 是否与会话中的 CSRF token 匹配。如果匹配，则认为该请求是合法的；否则，认为该请求是 CSRF 攻击。

  // PHP 示例：生成 CSRF token
  session_start();
  if (empty($_SESSION['csrf_token'])) {
      $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
  }
  
  // HTML 表单
  echo '<form action="/transfer" method="post">';
  echo '<input type="hidden" name="csrf_token" value="' . $_SESSION['csrf_token'] . '">';
  echo '<input type="text" name="account">';
  echo '<input type="text" name="amount">';
  echo '<button type="submit">Transfer</button>';
  echo '</form>';
  
  // 服务器端验证 CSRF token
  if ($_SERVER['REQUEST_METHOD'] === 'POST') {
      if (!empty($_POST['csrf_token']) && hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'])) {
          // 处理转账请求
      } else {
          // CSRF 攻击
          echo 'CSRF attack detected!';
      }
  }

  • session_start(): 启动会话。
  • $_SESSION['csrf_token']: 存储 CSRF token。
  • bin2hex(random_bytes(32)): 生成一个 32 字节的随机令牌，并将其转换为十六进制字符串。
  • hash_equals(): 安全地比较两个字符串，防止时序攻击。

• 双重 Cookie 验证 (Double Submit Cookie): 这种方法不需要服务器端存储 CSRF token。它的原理是将 CSRF token 同时存储在 Cookie 和表单中。当用户提交表单时，服务器会验证 Cookie 中的 CSRF token 是否与表单中的 CSRF token 匹配。

  // JavaScript 示例：生成 CSRF token 并存储到 Cookie 中
  function setCookie(name, value, days) {
      var expires = "";
      if (days) {
          var date = new Date();
          date.setTime(date.getTime() + (days * 24 * 60 * 60 * 1000));
          expires = "; expires=" + date.toUTCString();
      }
      document.cookie = name + "=" + (value || "") + expires + "; path=/";
  }
  
  function getCookie(name) {
      var nameEQ = name + "=";
      var ca = document.cookie.split(';');
      for (var i = 0; i < ca.length; i++) {
          var c = ca[i];
          while (c.charAt(0) == ' ') c = c.substring(1, c.length);
          if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length, c.length);
      }
      return null;
  }
  
  var csrfToken = btoa(Math.random().toString()).substr(0, 20);
  setCookie('csrf_token', csrfToken, 7);
  
  // HTML 表单
  // (使用模板引擎或其他方法将 csrfToken 动态插入到表单中)

  // PHP 示例：服务器端验证 CSRF token
  if ($_SERVER['REQUEST_METHOD'] === 'POST') {
      if (!empty($_COOKIE['csrf_token']) && !empty($_POST['csrf_token']) && hash_equals($_COOKIE['csrf_token'], $_POST['csrf_token'])) {
          // 处理转账请求
      } else {
          // CSRF 攻击
          echo 'CSRF attack detected!';
      }
  }

• SameSite Cookie: SameSite Cookie 是一种 HTTP Cookie 属性，用于限制 Cookie 的跨站使用。它可以设置为 Strict、Lax 或 None。

  • Strict: Cookie 只会在相同站点下发送。
  • Lax: Cookie 会在相同站点下发送，以及在一些跨站情况下发送，例如用户点击链接或提交表单。
  • None: Cookie 会在所有情况下发送，包括跨站请求。需要同时设置 Secure 属性，表示 Cookie 只能通过 HTTPS 连接传输。

  // PHP 示例：设置 SameSite Cookie
  setcookie('session_id', $session_id, ['samesite' => 'Strict', 'secure' => true, 'httponly' => true]);

• 用户交互: 对于敏感操作，例如修改密码、转账等，要求用户进行额外的身份验证，例如输入密码、验证码等。

• Referer 检查: 检查 HTTP Referer 头部，验证请求是否来自受信任的站点。但是，Referer 头部可能被篡改或缺失，因此不建议将其作为主要的防御手段。

3.4 总结

CSRF 攻击是一种利用用户身份执行恶意操作的攻击，但通过使用 STP、双重 Cookie 验证、SameSite Cookie 和用户交互等措施，可以有效地预防它。

表格总结

攻击类型	原理	预防措施
SQL 注入	将恶意 SQL 代码注入到应用程序的输入中，干扰或篡改数据库交互。	参数化查询/预编译语句、输入验证、最小权限原则、错误处理、Web 应用防火墙 (WAF)
XSS	将恶意脚本注入到受信任的网站中，在用户的浏览器中执行。	输出编码、输入验证、内容安全策略 (CSP)、HTTPOnly Cookie、Web 应用防火墙 (WAF)
CSRF	诱骗用户在不知情的情况下，以用户的身份执行恶意操作。	同步令牌 (STP)、双重 Cookie 验证、SameSite Cookie、用户交互、Referer 检查

提升安全意识，不断学习

Web 应用安全是一个复杂而不断发展的领域。我们需要不断学习新的技术和方法，提升安全意识，才能有效地保护我们的应用程序免受攻击。 今天的分享就到这里，希望对大家有所帮助。