如何清理和存储 WordPress 中包含 HTML 正则表达式模式的用户输入
How sanitize and store user input, that contains HTML regex pattern in WordPress
我正在开发一些 WordPress 插件，其功能之一是能够将用户输入的 HTML 正则表达式模式存储到数据库，然后在设置页面上显示。
我的方法确实有效，但我想知道该代码是否足够安全：
这是用户输入的模式：
<div(.+?)class='sharedaddy sd-sharing-enabled'(.*?)>(.+?)<\div><\div><\div>
这就是我在数据库中存储 HTML 模式的方式：
$print_options['custom_exclude_pattern'] = htmlentities(stripslashes($_POST['custom_exclude_pattern']),ENT_QUOTES,"UTF-8");
这就是它在 WordPress 数据库中的实际存储方式：
s:22:"custom_exclude_pattern";s:109:"<div(.+?)class="sharedaddy sd-sharing-enabled"(.*?)>(.+?)<\div><\div><\div>";
这就是输出在设置页面上的显示方式：
<input type="text" name="custom_exclude_pattern" value="<?php echo str_replace('"',"'",html_entity_decode($print_options['custom_exclude_pattern'])); ?>" size="30" />
感谢您的帮助:)
我希望我明白了，如果没有，请纠正我：您正在尝试根据存储在数据库中的相同模式为输入字段动态插入模式，对吗？
好吧，我个人认为模式对可用性有很好的帮助，因为用户知道他的输入格式不正确而无需每次都提交和刷新。
模式的大问题是，HTML 代码可以在客户端修改。我相信唯一安全的解决方案是检查服务器端输入的正确性...客户端程序不可能比服务器端程序更安全！
好吧，如果你想让你的用户输入一个正则表达式，你可以做一些像准备好的语句 + htmlentities($input, ENT_COMPAT, "UTF-I"); 来清理输入，然后做相反的事情，即 html_entity_decode($dataFromDb, ENT_COMPAT, " UTF-8"); .准备好的语句是必须的，所有其他解决恶意输入的方法都可以以多种不同的方式组合！
从评论来看，您似乎担心两个不同的问题（并且可能没有意识到我将在一分钟内提到的第三个问题）并且正在为这两个问题寻找一个解决方案：SQL 注入 和 跨站脚本。你必须分别对待每一个。我恳求你 read this article by Defuse Security.
如何预防SQL注射
这 answered before on Whosebug with respect to PHP applications in general. WordPress's $wpdb 支持准备好的语句，因此您不必弄清楚如何使用 PDO 或 MySQLi。 （但是，其驱动程序中的任何漏洞 都会 影响您的插件。请确保您通读 $wpdb 文档。
You should not escape the parameters 在将它们传递给准备好的语句之前。您最终只会得到经过处理的数据。
跨站脚本
截至撰写本文时（2015 年 6 月），您需要考虑两种一般情况：
- 用户应该不被允许向该输入提交任何HTML、CSS等。
- 允许用户向此输入提交一些 HTML、CSS 等，但我们不希望他们通过这样做来破解我们。
第一个问题很简单，可以解决：
echo htmlentities($dbresult['field'], ENT_QUOTES | ENT_HTML5, 'UTF-8');
第二个问题有点棘手。它涉及仅允许某些标记，同时不会意外地允许可以利用的其他标记在用户浏览器中获取 Javascript 到 运行。目前 XSS 防御的黄金标准同时允许一些 HTML 是 HTML Purifier.
重要！
无论您有什么要求，您都应该始终在输出上应用 XSS 防御，而不是在将内容插入数据库之前。最近，Wordpress 核心有一个 stored cross-site scripting vulnerability，这是由于决定在存储之前转义而不是在呈现之前转义。通过提供足够长的注释，攻击者可以在转义文本上触发 MySQL t运行cation 错误，从而绕过防御。
奖励：PHP 来自 unserialize()
的对象注入
That's how it's actually stored in WordPress DB:
s:22:"custom_exclude_pattern";s:109:"<div(.+?)class="sharedaddy sd-sharing-enabled"(.*?)>(.+?)<\div><\div><\div>";
您似乎在存储此数据时使用了 serialize()，并且可能在检索数据时使用了 unserialize()。 小心unserialize()；如果您让用户对字符串有任何控制权，他们可以 inject PHP objects 进入您的代码，这也可能导致远程代码执行。
远程代码执行，为了记录，意味着他们可以接管您的整个网站，并可能接管托管您博客的服务器。如果用户有任何机会可以直接更改此记录，我强烈建议改用 json_encode() 和 json_decode()。
我正在开发一些 WordPress 插件，其功能之一是能够将用户输入的 HTML 正则表达式模式存储到数据库，然后在设置页面上显示。
我的方法确实有效，但我想知道该代码是否足够安全：
这是用户输入的模式：
<div(.+?)class='sharedaddy sd-sharing-enabled'(.*?)>(.+?)<\div><\div><\div>
这就是我在数据库中存储 HTML 模式的方式：
$print_options['custom_exclude_pattern'] = htmlentities(stripslashes($_POST['custom_exclude_pattern']),ENT_QUOTES,"UTF-8");
这就是它在 WordPress 数据库中的实际存储方式：
s:22:"custom_exclude_pattern";s:109:"<div(.+?)class="sharedaddy sd-sharing-enabled"(.*?)>(.+?)<\div><\div><\div>";
这就是输出在设置页面上的显示方式：
<input type="text" name="custom_exclude_pattern" value="<?php echo str_replace('"',"'",html_entity_decode($print_options['custom_exclude_pattern'])); ?>" size="30" />
感谢您的帮助:)
我希望我明白了，如果没有，请纠正我：您正在尝试根据存储在数据库中的相同模式为输入字段动态插入模式，对吗？ 好吧，我个人认为模式对可用性有很好的帮助，因为用户知道他的输入格式不正确而无需每次都提交和刷新。 模式的大问题是，HTML 代码可以在客户端修改。我相信唯一安全的解决方案是检查服务器端输入的正确性...客户端程序不可能比服务器端程序更安全！
好吧，如果你想让你的用户输入一个正则表达式，你可以做一些像准备好的语句 + htmlentities($input, ENT_COMPAT, "UTF-I"); 来清理输入，然后做相反的事情，即 html_entity_decode($dataFromDb, ENT_COMPAT, " UTF-8"); .准备好的语句是必须的，所有其他解决恶意输入的方法都可以以多种不同的方式组合！
从评论来看，您似乎担心两个不同的问题（并且可能没有意识到我将在一分钟内提到的第三个问题）并且正在为这两个问题寻找一个解决方案：SQL 注入 和 跨站脚本。你必须分别对待每一个。我恳求你 read this article by Defuse Security.
如何预防SQL注射
这 answered before on Whosebug with respect to PHP applications in general. WordPress's $wpdb 支持准备好的语句，因此您不必弄清楚如何使用 PDO 或 MySQLi。 （但是，其驱动程序中的任何漏洞 都会 影响您的插件。请确保您通读 $wpdb 文档。
You should not escape the parameters 在将它们传递给准备好的语句之前。您最终只会得到经过处理的数据。
跨站脚本
截至撰写本文时（2015 年 6 月），您需要考虑两种一般情况：
- 用户应该不被允许向该输入提交任何HTML、CSS等。
- 允许用户向此输入提交一些 HTML、CSS 等，但我们不希望他们通过这样做来破解我们。
第一个问题很简单，可以解决：
echo htmlentities($dbresult['field'], ENT_QUOTES | ENT_HTML5, 'UTF-8');
第二个问题有点棘手。它涉及仅允许某些标记，同时不会意外地允许可以利用的其他标记在用户浏览器中获取 Javascript 到 运行。目前 XSS 防御的黄金标准同时允许一些 HTML 是 HTML Purifier.
重要！
无论您有什么要求，您都应该始终在输出上应用 XSS 防御，而不是在将内容插入数据库之前。最近，Wordpress 核心有一个 stored cross-site scripting vulnerability，这是由于决定在存储之前转义而不是在呈现之前转义。通过提供足够长的注释，攻击者可以在转义文本上触发 MySQL t运行cation 错误，从而绕过防御。
奖励：PHP 来自 unserialize()
的对象注入
That's how it's actually stored in WordPress DB:
s:22:"custom_exclude_pattern";s:109:"<div(.+?)class="sharedaddy sd-sharing-enabled"(.*?)>(.+?)<\div><\div><\div>";
您似乎在存储此数据时使用了 serialize()，并且可能在检索数据时使用了 unserialize()。 小心unserialize()；如果您让用户对字符串有任何控制权，他们可以 inject PHP objects 进入您的代码，这也可能导致远程代码执行。
远程代码执行，为了记录，意味着他们可以接管您的整个网站，并可能接管托管您博客的服务器。如果用户有任何机会可以直接更改此记录，我强烈建议改用 json_encode() 和 json_decode()。