跨站点脚本 PHP 获取 URL 问题答案

【问题标题】：Cross-Site Scripting PHP Get URL issue跨站点脚本 PHP 获取 URL 问题
【发布时间】：2018-10-26 16:28:40
【问题描述】：

我的一个站点存在跨站点脚本 (XSS) 问题。现在我正在使用以下代码来获取每个页面的 URL：

$pageurl = $_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
  $pageurlencode = "http%3A%2F%2F".urlencode($pageurl);
  $pageurl = "http://".$pageurl;

但是，当我将 $pageurl 放入我的开放图形 url (og:url) 时，就会出现问题（因为人们可以在那里注入代码）。

<meta property="og:url" content="<?php echo $pageurl; ?>" />

所以，我的问题是，如何修改我的 $pageurl 以防止添加恶意代码？

我在 StackOverflow 上搜索了类似问题，但找不到任何解决此特定问题的内容（有很多 XSS，但没有一个指向修复 get URL 调用）。因此，如果您确实看到了副本，请告诉我您在哪里看到的。谢谢。

【问题讨论】：

你遇到什么样的注射？通过$_SERVER 变量传递的任何内容都应该已经过清理。 See this related question.
有人使用该 URL 在我的网站上进行了测试。他们说，当他们在浏览器中输入example.com/?"><svg/onload=confirm(1)> 时，检查代码显示 og:url 为 example.com/?"><svg/onload=confirm(1)" /> ...如果这是真的，他们可以放置代码来窃取我的 cookie。
奇怪...当我输入相同的网址时，我检查代码并看到example.com/?%22%3E%3Csvg/onload=confirm(1)%3E ...这是安全的。你能告诉我如何向他解释没有问题吗？为什么他对代码的看法可能不同？

标签： php xss facebook-opengraph

【解决方案1】：

并且始终在输出上使用 htmlspecialchars() 将动态值（用户输入）转换为 HTML 源值。

【讨论】：

所以，只需在我上面的代码末尾添加一行并说.... $pageurl = htmlspecialchars($pageurl);对吗？
这样：<meta property="og:url" content="<?= htmlspecialchars($pageurl, ENT_COMPAT, "UTF-8"); ?>" /> 如果你使用另一个字符集然后 UTF-8 然后设置它而不是它。
或者您在上面描述过，但请记住，如果您在其他地方使用该变量的值，而不是 HTML 输出，您会更改它的值。 htmlspecialchars() 仅用于连接交换到（！）HTML。
htmlspecialchars() 远非万能的解决方案。您需要将其与通用逻辑配对，因为即使经过净化的用户输入也可能是恶意的，例如 javascript: URI 方案和一系列应该从不包含用户输入的元素。

【解决方案2】：

您最后的评论是正确的。

查询字符串——以及任何特殊字符，总是被编码。进行这种注入的唯一可能方法是 1) 如果 < > " 等是 valid URL characters 或 2) 甚至是 valid filename characters。请注意，这两个集合都排除了任何 HTML 字符。您唯一需要担心注入的情况是，如果您在 PHP 中使用 $_GET 或 $_POST 变量并直接输出它们——因为它们被解码为纯文本。然后，您将使用 htmlentities 正确清理它们。 See this broader discussion on text injection.

由于您直接访问有效的 URL 字符串（通过 $_SERVER['REQUEST_URI']），因此您永远不会得到无效的（符合规范的）URL。

浏览器应在将其发送到服务器之前自动处理此编码，否则，服务器应防范任何格式错误的 URL。无论哪种方式，您的脚本都无需担心如何处理。

编辑

您似乎可以在 Mac/Linux 上的文件名中包含诸如 < > 之类的字符，但是这些字符永远不会被服务器正确加载，因为它们不遵循 URL 准则。

编辑 2

我刚刚在 Node.JS 服务器上对此进行了测试，看来它确实可以提供带有特殊字符的文件。为了安全起见，请始终按照此页面上的建议使用 htmlentities 或 htmlspecialchars 进行编码，但是，我永远无法想象有人拥有带有特殊 HTML 字符的文件名——这基本上是对自己进行 XSS 攻击——但要注意这一点是件好事的。

编辑 3

好奇心战胜了我，我将一个名为 "<test.php 的文件部署到了我在 Linux VM 上运行的 NGINX 服务器。这是print_r($_SERVER)的部分输出：

 [DOCUMENT_URI] => /"<test.php
 [REQUEST_URI] => /%22%3Ctest.php
 [SCRIPT_NAME] => /"<test.php

注意REQUEST_URI 仍在被编码，即使服务器正确解析路径。因此，假设您坚持使用REQUEST_URI，您可以忽略我的最后一次编辑。重申一下，文件不应该用特殊字符命名，所以这不会是一个问题。

【讨论】：