【问题标题】:How to prevent XSS in attributes如何防止属性中的 XSS
【发布时间】:2011-10-26 23:56:42
【问题描述】:

所以我有一个网站,用户可以使用他们选择的用户名进行注册,并且可以提交大块文本并添加 cmets。目前,为了避免 XSS,我在输入到数据库的数据上使用 strip_tags,并且我只在正文中输出数据,而不是在属性中。 我目前正在对该站点进行更改,其中之一是创建一个用户页面,当有人单击用户名(链接)时加载该页面。这看起来像:

<a href="example.com/user/<?php echo $username; ?>">...</a>

我担心对于 $username 变量,有人可能会插入

<a href="example.com/user/user" onClick="javascript:alert('XSS');">...</a>

我已经阅读了很多关于此的其他 SO 帖子,但没有一个给出非黑即白的答案。如果我在输出上的所有文本上使用以下内容,除了输入上的 strip_tags:

echo htmlspecialchars($string, ENT_QUOTES, 'UTF-8');

这是否足以阻止所有 XSS 攻击,包括那些使用内联 javascript: 语法的攻击?

另外,有什么方法可以在不删除“我>你”之类的内容的情况下删除实际的 html 标签?

谢谢!

【问题讨论】:

  • +1 关心安全!

标签: php html xss htmlspecialchars strip-tags


【解决方案1】:

根据 PHP5 认证学习指南,关于安全性有两条黄金法则:

  1. 过滤输入
  2. 转义输出

目前您只关注问题的一方面。

但我更喜欢 htmlentities。

【讨论】:

  • 为什么使用 htmlentities 与 htmlspecialchars?
  • "这个函数在所有方面都与 htmlspecialchars() 相同,除了 htmlentities(),所有具有 HTML 字符实体等效项的字符都被转换为这些实体。"这些也是 Zend 首选的转义方法。根据上述学习指南。
  • 我理解其中的区别,我的意思是有什么真正的理由使用一个而不是另一个?
  • 没有,我真的经历过。但在我看来,有时候听听别人的建议很有用。
【解决方案2】:

转义取决于上下文。如果是 URL,请使用 URL 编码 (%xx),但还要检查完整的 URL 是否不以“javascript:”开头。您的 onclick-attribute 语法不是必需的。 Onclick 是一个 javascript 事件处理程序,因此其中的任何 javascript 都会运行。

请参阅 OWASP XSS 预防备忘单,了解如何针对不同的上下文进行转义。

【讨论】:

猜你喜欢
  • 2014-11-14
  • 2013-02-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-02-18
  • 1970-01-01
  • 2014-07-24
相关资源
最近更新 更多