我会尝试做这样的事情：

http://www.example.com/somepage.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E TEST TEXT %3C/html%3E

开始。然后，如果您看到 2 个不同的响应，其中一个是 200，并且如果您看到文本，那么您可以尝试任何带有 cookie 的东西。

从上面的“屏幕截图”中不可能说出来，但我会说你不是在位置之后返回 0x0D 0x0A，而是你发送的高字节（0x8A 0x8D），包括你的 Set-Cookie。

而且您也没有将返回的高字节解释为 CRLF，因此您的用户代理将 Set-Cookie 解释为 URL 的非主机部分。

尝试切换 CR 和 LF 的顺序，并查看来自 Web 服务器的响应的十六进制转储。

我认为您应该发送 %E5%98%8D%E5%98%8A，而不是 %E5%98%8A%E5%98%8D。否则，两个标记都会被扩展，你可能会得到一个额外的换行符。

另一方面，额外的换行符显然根本没有被解释，所以我想知道您的漏洞利用是否确实有效，或者您是否看到自己的有效负载无害地回显给您，然后被解释为虚假的换行符。

即，您发送

location=(...omitted...)%E5%98%8A%E5%98%8D(...)cookie%20test

并且服务器回显一行

Location: (same as above)

这就是您的浏览器发送该 GET 的原因。您似乎在回复中看到了换行符，因为上面的单行被您的终端解释为两行。

我已经努力解决您正在谈论的同一种错误。但我面临的同样问题是，您可以轻松注入 cookie 或 Set-Cookie，但无法进一步利用 XSS、内容注入等。您可以在 302 重定向页面上注入 HTML 内容，但它不会有意义，因为接下来您将被重定向到页面。

在这种情况下，只有 %E5%98%8D%E5%98%8A 可以用于注入 cookie。同样，我猜您不能将响应标头拆分为两个有效的响应标头。