Threats and Attacks

什么是XSS(跨站脚本)?

跨站脚本(XSS)是一种网站安全漏洞,允许攻击者向网页添加有害脚本。这些脚本大多数是用JavaScript编写的。

什么是 XSS(跨站脚本攻击)?

跨站脚本攻击,或称 XSS,是网站中的一种安全漏洞,允许攻击者向网页添加有害脚本。这些脚本大多数是用 JavaScript 编写的。

如果有人访问了受 XSS 影响的页面,他们的浏览器会运行攻击者的脚本。这可能导致 cookie 被窃取、会话被劫持或在未经用户许可的情况下执行操作。

XSS 与 SQL 注入一样,常常被列在 OWASP Top 10 中,作为最常见的 Web 应用程序漏洞之一。

plexicus-xss-attack-ilustration

XSS 如何工作?

XSS 通常针对未正确检查和清理用户输入的 Web 应用程序。

例如,如果评论框允许原始 HTML 或 JavaScript 而没有任何过滤,攻击者可以添加如下代码:

<script>alert('Hacked!');</script>

当受害者查看页面时,恶意代码会在他们的浏览器中运行。

为什么 XSS 在网络安全中很重要

XSS 可能导致更大的安全漏洞:

  • 账户接管(窃取会话 cookie 以冒充用户)
  • 数据盗窃(捕获表单输入如密码或信用卡)
  • 钓鱼攻击(注入伪造的登录表单)
  • 恶意软件传播(将用户重定向到恶意网站)

XSS 的类型

  1. 基于DOM的XSS
  2. 攻击完全发生在浏览器中,通过操纵文档对象模型(DOM)而不涉及服务器。
  3. 存储型XSS
  4. 恶意脚本永久存储在服务器上,例如数据库、个人资料页面。
  5. 反射型XSS
  6. 脚本从网络服务器反射(例如,在URL或错误消息中),当受害者点击攻击者精心制作的链接时,脚本将被执行。

如何防止XSS

  • 输入清理和输出编码:始终在处理用户输入数据之前进行清理,将用户输入转换为安全格式
  • 使用内容安全策略(CSP):限制浏览器中可以执行的脚本。
  • 避免使用eval()和内联JavaScript:以减少注入风险。
  • 安全测试(DAST/IAST):运行安全测试以及早检测漏洞

真实案例中的例子 - Samy蠕虫(MySpace,2005)

发生了什么: Samy Kamkar 发布了一个包含存储型XSS负载的MySpace个人资料。当其他用户查看该个人资料时,负载在他们的浏览器中运行,它(a)将Samy添加为朋友,(b)在他们的个人资料中附加短语“Samy是我的英雄”,并且(c)将自身复制到这些用户的个人资料页面。

影响: 蠕虫在大约20小时内自我传播到约100万用户,迫使MySpace暂时下线。

为何有效: MySpace允许在个人资料字段中使用未转义的HTML/属性,从而在访问者的浏览器中启用存储脚本执行。

课程/修复: 正确的输出编码、输入清理、删除个人资料字段中的HTML,以及快速修补。Samy后来面临法律后果,而MySpace部署了过滤器。

相关术语

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)