PHP XSS 清理

发布于 2024-11-06 12:36:14 字数 1751 浏览 4 评论 0原文

问题:

避免 UTF8 编码页面 XSS 的最佳 safe1()、safe2()、safe3() 和 safe4() 函数是什么?它在所有浏览器(特别是 IE6)中也安全吗?

<body><?php echo safe1($xss)?></body>

<body id="<?php echo safe2($xss)?>"></body>

<script type="text/javascript">
  var a = "<?php echo safe3($xss)?>";
</script>

<style type="text/css">
  .myclass {width:<?php echo safe4($xss)?>}
</style>

许多人说,可以做的绝对最好的事情是:

// safe1 & safe2
$s = htmlentities($s, ENT_QUOTES, "UTF-8");

// But how would you compare the above to:
//    https://github.com/shadowhand/purifier
// OR http://kohanaframework.org/3.0/guide/api/Security#xss_clean
// OR is there an even better if not perfect solution?

// safe3
$s = mb_convert_encoding($s, "UTF-8", "UTF-8");
$s = htmlentities($s, ENT_QUOTES, "UTF-8");

// How would you compare this to using using mysql_real_escape_string($s)?
// (Yes, I know this is a DB function)
// Some other people also recommend calling json_encode() before passing to htmlentities
// What's the best solution?

有大量关于 PHP 和 XSS 的帖子。 大多数人只是说“使用 HTMLPurifier”或“使用 htmlspecialchars”,或者是错误的。 其他人说使用 OWASP —— 但它非常慢。 下面列出了我遇到的一些好帖子:

htmlspecialchars 和 mysql_real_escape_string 是否可以保护我的 PHP 代码免受注入?

XSS Me 警告 - 真正的 XSS 问题?

CodeIgniter - 为什么使用 xss_clean

Questions:

What are the best safe1(), safe2(), safe3(), and safe4() functions to avoid XSS for UTF8 encoded pages? Is it also safe in all browsers (specifically IE6)?

<body><?php echo safe1($xss)?></body>

<body id="<?php echo safe2($xss)?>"></body>

<script type="text/javascript">
  var a = "<?php echo safe3($xss)?>";
</script>

<style type="text/css">
  .myclass {width:<?php echo safe4($xss)?>}
</style>

.

Many people say the absolute best that can be done is:

// safe1 & safe2
$s = htmlentities($s, ENT_QUOTES, "UTF-8");

// But how would you compare the above to:
//    https://github.com/shadowhand/purifier
// OR http://kohanaframework.org/3.0/guide/api/Security#xss_clean
// OR is there an even better if not perfect solution?

.

// safe3
$s = mb_convert_encoding($s, "UTF-8", "UTF-8");
$s = htmlentities($s, ENT_QUOTES, "UTF-8");

// How would you compare this to using using mysql_real_escape_string($s)?
// (Yes, I know this is a DB function)
// Some other people also recommend calling json_encode() before passing to htmlentities
// What's the best solution?

.

There are a hell of a lot of posts about PHP and XSS.
Most just say "use HTMLPurifier" or "use htmlspecialchars", or are wrong.
Others say use OWASP -- but it is EXTREMELY slow.
Some of the good posts I came across are listed below:

Do htmlspecialchars and mysql_real_escape_string keep my PHP code safe from injection?

XSS Me Warnings - real XSS issues?

CodeIgniter - why use xss_clean

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

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

发布评论

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

评论(2

脸赞 2024-11-13 12:36:14

safe2() 显然是 htmlspecialchars()

代替safe1() 您确实应该使用 HTMLPurifier 清理完整的 HTML 块。它会去除不需要的属性、标签,特别是任何 javascript 风格的东西。是的,它很慢,但它涵盖了所有小的边缘情况(即使对于较旧的 IE 版本),从而允许安全地重用 HTML 用户片段。但请查看 http://htmlpurifier.org/comparison 寻找替代方案。 -- 如果您确实只想在那里显示原始用户文本(没有过滤的 html),那么 htmlspecialchars(strip_tags($src) )) 实际上可以正常工作。

safe3() 尖叫着正则表达式。在这里,您实际上只能将白名单应用于您真正想要的内容:

var a = "<?php echo preg_replace('/[^-\w\d .,]/', "", $xss)?>";

当然,您可以在此处使用json_encode来获得完全有效的JS语法和变量。但是,您只是将该字符串的可利用性延迟到了 JS 代码中,然后您必须在其中照顾它。


它在所有浏览器(特别是 IE6)中也安全吗?

如果您明确指定字符集,那么 IE 将不会执行其可怕的内容检测魔法,因此可以忽略 UTF7 漏洞。

safe2() is clearly htmlspecialchars()

In place of safe1() you should really be using HTMLPurifier to sanitize complete blobs of HTML. It strips unwanted attributes, tags and in particular anything javascriptish. Yes, it's slow, but it covers all the small edge cases (even for older IE versions) which allow for safe HTML user snippet reuse. But check out http://htmlpurifier.org/comparison for alternatives. -- If you really only want to display raw user text there (no filtered html), then htmlspecialchars(strip_tags($src)) would actually work fine.

safe3() screams regular expression. Here you can really only apply a whitelist to whatever you actually want:

var a = "<?php echo preg_replace('/[^-\w\d .,]/', "", $xss)?>";

You can of course use json_encode here to get a perfectly valid JS syntax and variable. But then you've just delayed the exploitability of that string into your JS code, where you then have to babysit it.


Is it also safe in all browsers (specifically IE6)?

If you specify the charset explicitly, then IE won't do its awful content detection magic, so UTF7 exploits can be ignored.

昵称有卵用 2024-11-13 12:36:14

http://php.net/htmlentities 请注意有关采用字符编码的可选第三个参数的部分。您应该使用它而不是 mv_convert_encoding。只要 php 文件本身使用 utf8 编码保存就应该可以工作。

htmlentities($s, ENT_COMPAT, 'UTF-8');

至于将变量直接注入 javascript,您可以考虑将内容放入页面其他位置的隐藏 html 元素中,并在需要时将内容从 dom 中拉出。

当您想要实际显示用户提交的 html(例如,允许浏览器实际呈现)时,会使用您提到的净化器。使用 htmlentities 将对所有内容进行编码,以便字符将显示在 ui 中,但浏览器不会解释任何实际代码。你打算做什么?

http://php.net/htmlentities note the section on the optional third parameter that takes a character encoding. You should use this instead of mv_convert_encoding. So long as the php file itself is saved with a utf8 encoding that should work.

htmlentities($s, ENT_COMPAT, 'UTF-8');

As for injecting the variable directly into javascript, you might consider putting the content into a hidden html element somewhere else in the page instead and pulling the content out of the dom when you need it.

The purifiers that you mention are used when you want to actually display html that a user submitted (as in, allow the browser to actually render). Using htmlentities will encode everything such that the characters will be displayed in the ui, but none of the actual code will be interpreted by the browser. Which are you aiming to do?

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