详解网站攻击原理

详解网站攻击原理

公共后缀 (Public Suffix)

公共后缀是指能够被 Internet 上任何人注册为域名的部分。例如，在 www.example.com 中，com 是一个公共后缀。公共后缀列表 (Public Suffix List, PSL) 是一个由社区维护的列表，它定义了哪些域可以被公众注册。这个列表对于处理 Cookie、文档隔离等有重要作用。

站点域 (Site Domain)

站点域通常指分配给特定网站的唯一域名。在处理跨域资源共享（CORS）和设置 Cookie 时，了解当前的站点域以及如何与其他域进行交互是很重要的。

跨站 (Cross-Site)

跨站请求指的是从一个域向另一个域发送的请求。这在 Web 应用中很常见，特别是在使用第三方服务（如 CDN、API等）时。跨站请求需要注意安全策略，如 CORS 和 Cookie 的 SameSite 属性，以保护用户数据不受跨站脚本攻击（XSS）和跨站请求伪造（CSRF）等安全威胁。

SameSite 限制策略

SameSite 是一个 Set-Cookie 响应头的属性，用来限制第三方 Cookie 的发送，以减少 CSRF 攻击的风险。SameSite 可以设置为以下几个值：

• Strict：Cookie 只会在同一站点请求中被发送，即当前网页 URL 与请求目标 URL 完全一致。
• Lax：在一些第三方请求中 Cookie 会被发送，例如，从另一个站点通过链接访问时。但在 API 请求中不会发送。
• None：即使是跨站请求，Cookie 也会被发送。如果设置为 None，必须同时设置 Secure 属性，表示只有在加密的 HTTPS 连接上，Cookie 才会被发送。

Set-Cookie

Set-Cookie 是一个 HTTP 响应头，由服务器发送给客户端（浏览器），用于创建一个 Cookie。例如：

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; SameSite=Lax

在安全敏感的应用中正确设置 SameSite 属性非常关键，它可以帮助防止 CSRF 攻击，保护用户数据安全。

总之，了解和合理应用这些概念和策略，对开发安全、用户友好的 Web 应用至关重要。

跨站请求伪造（CSRF）是一种攻击方式，它利用了用户已登录的Web应用的身份来执行非授权的操作。这种攻击发生在攻击者诱导用户（通常是通过点击链接）访问一个恶意网站，而这个恶意网站上的代码则会利用用户在另一个网站上的登录态（比如银行网站）来发起请求。

CSRF 攻击的例子

假设 Alice 登录了她的银行账户 bank.com，并在该网站上保持登录状态。这时，Alice 收到了一封电子邮件，里面包含了一个链接，这个链接指向攻击者控制的网站 evil.com。Alice 点击了这个链接。

在 evil.com 的页面中，包含了一段恶意代码，如下：

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

这行代码试图通过一个看不见的图片请求来执行一个转账操作，将 1000 单位的货币从 Alice 的账户转到攻击者指定的账户上。

因为 Alice 在 bank.com 上还保持着登录状态，所以她的浏览器会自动包含她的登录凭证（如 Cookies）在请求中。如果 bank.com 没有适当地防御 CSRF 攻击，那么这个转账操作就会像是由 Alice 亲自发起的一样被执行。

这就是 CSRF 攻击的典型过程。攻击者利用了用户对 bank.com 的信任和用户在该站点上的登录态，无需获取用户的登录凭证就能代表用户执行操作。

如何防御 CSRF 攻击

1. 使用 CSRF 令牌（Token）：服务器为每个用户的会话生成一个唯一的、随机的令牌，并在表单提交时要求客户端提交这个令牌。因为攻击者无法获知这个令牌，所以无法伪造请求。

2. 检查请求的来源：通过验证 HTTP Referer 头或 Origin 头来确定请求是否来自合法的来源。

3. 使用 SameSite Cookie 属性：将 Cookie 的 SameSite 属性设置为 Strict 或 Lax，可以限制 Cookie 在跨站请求中的发送，从而帮助防御 CSRF 攻击。

4. 要求重新认证：对于敏感操作，要求用户重新输入密码或进行二次验证。

通过这些措施，网站可以有效地减少 CSRF 攻击的风险。

让我们通过一个在线银行应用的例子来说明如何实现这些防御 CSRF 攻击的策略。

场景

---

Alice 使用她的在线银行应用 bank.com 来进行日常的银行交易。这个应用允许她转账、支付账单等。为了提高安全性，bank.com 实施了上述的 CSRF 防御策略。

使用 CSRF 令牌

当 Alice 登录到 bank.com 并尝试进行转账时，服务器会为这个转账表单生成一个唯一的 CSRF 令牌，并将其作为隐藏字段包含在表单中。当 Alice 提交表单时，服务器会验证表单中的 CSRF 令牌是否有效且与用户的会话匹配。因为攻击者无法访问到这个令牌，所以他们无法伪造一个有效的转账请求。

检查请求的来源

同时，bank.com 的服务器配置了检查 HTTP Referer 和 Origin 头的逻辑。这意味着，如果一个转账请求来自非法来源（例如，攻击者的网站 evil.com），即使攻击者某种方式获得了 CSRF 令牌，请求也会因来源不匹配而被服务器拒绝。

使用 SameSite Cookie 属性

bank.com 将所有设置在用户浏览器上的 Cookie 的 SameSite 属性设置为 Strict。这样，即使 Alice 不小心点击了一个来自 evil.com 的恶意链接，浏览器也不会在向 bank.com 发起请求时携带 Cookie，有效防止了 CSRF 攻击。

要求重新认证

对于转账等敏感操作，bank.com 要求 Alice 重新输入她的密码或发送一个一次性验证码到她的手机上，需要她进行确认。这一步增加了额外的安全层次，即使攻击者能够绕过其他防御措施，没有 Alice 的第二因素认证，他们也无法完成转账操作。

结论

通过上述措施的组合应用，bank.com 能够有效地防御 CSRF 攻击，保护 Alice 和其他用户的账户安全。尽管没有任何安全措施是绝对安全的，但是通过层层防护，可以显著降低攻击的风险和成功率。

---

让我们以一个在线投票平台 vote.com 为例，详细模拟如何通过上述四种措施防御 CSRF 攻击。

场景背景

假设 vote.com 允许注册用户在线投票决定各种议题。恶意攻击者意图通过 CSRF 攻击操纵投票结果，试图在用户不知情的情况下代表他们投票。

使用 CSRF 令牌（Token）

• 实施细节：当用户登录 vote.com 并准备投票时，服务器为该用户会话生成一个唯一的 CSRF 令牌，并将此令牌以隐藏字段的形式嵌入到投票表单中。每当用户提交投票表单时，服务器都会验证表单中的令牌是否与用户的会话令牌匹配。

• 攻击者难点：攻击者创建了一个恶意网站，试图诱导用户点击一个链接，该链接自动提交一个指向 vote.com 的投票请求。但是，因为攻击者无法获知 CSRF 令牌，他们的请求缺少有效的令牌，服务器因此拒绝该请求。

检查请求的来源

• 实施细节：vote.com 在处理投票请求时，会检查 HTTP Referer 或 Origin 头部，确保请求是从 vote.com 自身或信任的站点发起的。

• 攻击者难点：即使攻击者成功诱导用户点击恶意链接，由于请求的来源不是 vote.com，请求会被服务器识别为非法来源，从而被拒绝。

使用 SameSite Cookie 属性

• 实施细节：vote.com 设置所有用户认证 Cookie 的 SameSite 属性为 Strict。这意味着仅当用户直接在 vote.com 上发起请求时，Cookie 才会被发送。

• 攻击者难点：这阻止了恶意网站发起的请求携带 vote.com 的认证 Cookie，因此即使用户在 vote.com 上有有效的登录会话，恶意请求也无法利用这一点。

要求重新认证

• 实施细节：对于更改用户投票或敏感操作，vote.com 要求用户重新输入密码，或者发送一个一次性验证码到用户注册的手机上，以完成二次验证。

• 攻击者难点：这一措施确保即使攻击者通过某种方式绕过前面的防护措施，他们也无法在没有用户明确授权的情况下完成投票操作，因为他们无法通过二次验证。

结论

通过综合使用 CSRF 令牌、检查请求的来源、使用 SameSite Cookie 属性以及要求重新认证等多种措施，vote.com 构建了一个多层次的防御体系，显著提高了 CSRF 攻击的难度，并保护了用户和平台的安全。这种综合防御策略是保护 Web 应用免受 CSRF 攻击的最佳实践。

跨站脚本攻击（XSS）示例

假设有一个论坛网站，用户可以提交评论，并且这些评论会被直接显示在网页上。如果网站没有对用户输入进行适当的过滤或转义，攻击者就可以提交包含恶意 JavaScript 代码的评论。例如，攻击者提交了以下评论：

<script>alert('XSS Attack!');</script>

当其他用户浏览包含这条评论的网页时，嵌入其中的 JavaScript 代码会被浏览器执行。在这个简单的例子中，它会显示一个警告框，但实际攻击可能会涉及窃取 Cookie、会话劫持或其他恶意行为。

解决办法

1. 输入过滤：在接收用户输入时，严格过滤掉或转义输入字符串中的特殊字符，尤其是 <、>、"、' 等，这些字符可以用于构造 HTML 或 JavaScript 代码。使用库如 OWASP 的 AntiSamy 或 Java 的 Jsoup 对输入内容进行清洁是个好选择。

2. 输出编码：在将用户输入的数据回显到页面上时，对数据进行 HTML 编码，确保浏览器将其作为文本内容而非可执行的 HTML 或 JavaScript。许多现代 Web 框架（如 React、Vue 和 Angular）默认就执行这样的编码操作。

3. 内容安全策略（CSP）：通过设置合适的 CSP 策略，可以为浏览器提供一组规则，明确指示哪些资源可以被加载和执行。例如，你可以禁止加载所有外部脚本，只允许执行从同一源（same-origin）加载的脚本。

4. 使用 HTTPOnly Cookie：设置 Cookie 的 HttpOnly 属性可以阻止 JavaScript 通过 document.cookie 访问用户的 Cookie。虽然这不是防止 XSS 攻击的直接方法，但它可以减少攻击成功时的潜在损害。

5. 验证和更新第三方库：确保应用中使用的所有第三方库都是最新的，并来自可信的来源。过时的库可能包含安全漏洞，增加 XSS 攻击的风险。

通过这些措施，可以显著降低 XSS 攻击的风险，保护网站和用户的安全。

实施上述 XSS 攻击防御措施的具体方法涉及到前端和后端的多个环节。以下是一些具体实施方法和考虑事项：

1. 输入过滤

• 后端处理：在服务器端接收到用户输入后，使用一些库（如 Java 的 Jsoup 或 PHP 的 HTML Purifier）来清理 HTML 内容，去除或转义有潜在危险的字符和标签。
• 前端验证：在提交表单之前，使用 JavaScript 对用户输入进行初步的验证和清理，但不要仅依赖前端验证，因为攻击者可以绕过前端。

2. 输出编码

• 模板引擎：在 Web 应用中使用模板引擎（如 React, Vue, Angular）时，确保在输出数据到 HTML 时使用框架提供的自动转义功能。
• 手动编码：对于不自动转义的场景，手动对输出的数据进行 HTML 编码，尤其是在插入用户控制的数据到 HTML、JavaScript、CSS、URL 中时。

3. 内容安全策略（CSP）

• 配置 Web 服务器：在 Web 服务器（如 Apache、Nginx）配置中添加 CSP 规则，例如 Content-Security-Policy: script-src 'self'; 仅允许执行同源脚本。
• 使用元标签：在 HTML 的 <head> 部分使用 <meta> 标签来设置 CSP。这种方法适用于不能直接控制 HTTP 响应头的场景。

4. 使用 HTTPOnly Cookie

• 设置 Cookie 属性：在设置 Cookie 时，加上 HttpOnly 标志，如 Set-Cookie: sessionId=abc123; HttpOnly。这可以在大多数后端框架中通过简单的配置实现。

5. 验证和更新第三方库

• 定期检查：使用工具如 npm audit 或 Snyk 来检测项目依赖中的已知漏洞，并按提示更新到安全的版本。
• 自动更新服务：考虑使用 Dependabot 等自动依赖更新服务，这些服务可以自动创建拉取请求来更新有安全问题的库。

总结

实施 XSS 防御措施需要前端和后端的共同努力。确保输入的过滤和清理、输出的正确编码以及使用安全的 HTTP 头部设置，都是保护 Web 应用不受 XSS 攻击的重要步骤。同时，保持对项目依赖的持续审查和更新，可以减少因第三方库漏洞带来的安全风险。