PHP 有权威的反 XSS 库吗?

发布于 2024-09-28 09:15:06 字数 128 浏览 4 评论 0原文

我已经知道 XSS 是如何工作的,但找出注入恶意输入的所有不同方法并不是一种选择。

我在那里看到了几个库,但其中大多数都非常不完整、效率低下,或者是 GPL 许可的(你们什么时候才能知道 GPL 不适合共享小库!使用 MIT)

I already know how XSS works, but finding out all the many different ways to inject malicious input is not an option.

I saw a couple libraries out there, but most of them are very incomplete, ineficient, or GPL licensed (when will you guys learn that GPL is not good to share little libraries! Use MIT)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

永不分离 2024-10-05 09:15:06

OWASP 提供了一个编码库,在该库上花费了时间来处理各种情况。

已过时: http://www.owasp.org/index.php/Category:OWASP_Encoding_Project

现在位于 http://code.google.com/p/reform/
OWASP 的 antiXSS 特定库位于:http://code.google.com/p/php-反SSS/

OWASP offers an encoding library, on which time has been spent to handle the various cases.

Obsolete: http://www.owasp.org/index.php/Category:OWASP_Encoding_Project

Now at http://code.google.com/p/reform/
and OWASP's antiXSS specific library is at: http://code.google.com/p/php-antixss/

昵称有卵用 2024-10-05 09:15:06

htmlspecialchars() 是您唯一应该了解的函数。

htmlspecialchars() is the only function you should know about.

小鸟爱天空丶 2024-10-05 09:15:06

HTMLPurifier 无疑是清理 HTML 输入的最佳选择,并且 htmlspecialchars 应该应用于其他任何内容。

但是 XSS 漏洞不应该被清除,因为任何此类提交的内容都是垃圾。而是让您的应用程序保释并写入日志条目。实现 XSS 检测的最佳过滤器集位于 mod_security 核心规则中。

我在 new input(),参见_xss方法。

HTMLPurifier is the undenied best option for cleansing HTML input, and htmlspecialchars should be applied to anything else.

But XSS vulnerabilities should not be cleaned out, because any such submissions are garbage anyway. Rather make your application bail and write a log entry. The best filter set to achieve XSS detection is in the mod_security core rules.

I'm using an inconspicious but quite thorough attribute detection here in new input(), see _xss method.

小霸王臭丫头 2024-10-05 09:15:06

编辑:感谢@mario指出这一切都取决于上下文。确实没有超级方法可以在所有情况下防止这一切。你必须做出相应的调整。


编辑:我的立场是正确的,并且非常感谢@bobince 和@Rook 在这个问题上的支持。现在我很清楚 strip_tags 不会以任何方式阻止 XSS 攻击

在回答之前我已经扫描了我的所有代码,看看我是否以任何方式暴露,一切都很好,因为我主要使用 htmlentities($a, ENT_QUOTES) 来应对 W3C 。

也就是说,我已经更新了下面的函数,以某种程度模仿我使用的函数。我仍然发现 strip_tags 放在 htmlentities 之前很好,这样当用户尝试输入标签时,它们就不会污染最终结果。假设用户输入:ok! 将其显示为 ok! 比打印出转换后的全文 htmlentities 要好得多。

非常感谢你们花时间回复和解释。


如果它来自互联网用户:

// the text should not carry tags in the first place
function clean_up($text) {
    return htmlentities(strip_tags($text), ENT_QUOTES, 'UTF-8');
}

如果它来自后台……不要。

公司中的某个人可能需要 JavaScript 来处理这个或那个页面,这是有充分理由的。能够记录和责备比关闭用户要好得多。

Edit: Thank you @mario for pointing that it all depends on the context. There really is no super way to prevent it all on all occasions. You have to adjust accordingly.


Edit: I stand corrected and very appreciative for both @bobince and @Rook's support on this issue. It's pretty much clear to me now that strip_tags will not prevent XSS attacks in any way.

I've scanned all my code prior to answering to see if I was in any way exposed and all is good because of the htmlentities($a, ENT_QUOTES) I've been using mainly to cope with W3C.

That said I've updated the function bellow to somewhat mimic the one I use. I still find strip_tags nice to have before htmlentities so that when a user does try to enter tags they will not pollute the final outcome. Say user entered: <b>ok!</b> it's much nicer to show it as ok! than printing out the full text htmlentities converted.

Thank you both very much for taking the time to reply and explain.


If it's coming from internet user:

// the text should not carry tags in the first place
function clean_up($text) {
    return htmlentities(strip_tags($text), ENT_QUOTES, 'UTF-8');
}

If it's coming from the backoffice... don't.

There are perfectly valid reasons why someone at the company may need javascript for this or that page. It's much better to be able to log and blame than to shut down your uers.

↙厌世 2024-10-05 09:15:06

我很喜欢 htmlpurifier ,但我发现它效率很低,因为它相当大。另外,它是 LGPL,我不知道它是否属于你们的 GPL 禁令。

I like htmlpurifier fine, but I see how it could be inefficient, since it's fairly large. Also, it's LGPL, and I don't know if that falls under your GPL ban.

囍孤女 2024-10-05 09:15:06

除了 zerkms 的回答,如果您发现需要接受用户提交的 HTML(例如,从所见即所得编辑器),您将需要使用 HTML 解析器来确定可以提交和不能提交的内容。

我使用并推荐 HTML Purifier

注意:甚至不要尝试使用正则表达式:)

In addition to zerkms's answer, if you find you need to accept user submitted HTML (from a WYSIWYG editor, for example), you will need to use a HTML parser to determine what can and can't be submitted.

I use and recommend HTML Purifier.

Note: Don't even try to use regex :)

放低过去 2024-10-05 09:15:06

我很惊讶这里没有提到它,但与 htmlPurifier 相比,我更喜欢 htmlAwed。它是最新的、获得良好许可、非常小并且速度非常快。

I'm surprised it's not been mentioned here, but I prefer htmlAwed to htmlPurifier. It's up-to-date, nicely licensed, very small and really fast.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文