我正在开发一个使用 Wordpress 作为 CMS 的应用程序。
我有一个包含很多输入字段的表单,需要在存储到数据库之前对其进行清理。
我想防止 SQL 注入、注入 javascript 和 PHP 代码以及其他有害代码。
目前我正在使用自己的方法来清理数据,但我觉得使用 WP 使用的功能可能会更好。
我已经查看了 WordPress 中的数据验证,但我不确定应该使用多少这些功能,以及按什么顺序。谁能告诉我WP的哪些功能最好用?
目前,我正在通过执行以下操作“清理”我的输入:
-
因为带有重音符号(é、ô、æ、ø、å)的字符以一种有趣的方式存储在数据库中(即使我的表设置为 < code>ENGINE=InnoDB、DEFAULT CHARSET=utf8
和 COLLATE=utf8_danish_ci
),我现在正在使用 htmlentities() 转换可以有重音符号的输入字段。
-
当创建SQL字符串来输入数据时,我使用mysql_real_escape_string()
。
但我认为这不足以防止攻击。因此,非常感谢提出改进建议。
I'm developing an application using Wordpress as a CMS.
I have a form with a lot of input fields which needs to be sanitized before stored in the database.
I want to prevent SQL injection, having javascript and PHP code injected and other harmful code.
Currently I'm using my own methods to sanitize data, but I feel that it might be better to use the functions which WP uses.
I have looked at Data Validation in Wordpress, but I'm unsure on how much of these functions I should use, and in what order. Can anyone tell what WP functions are best to use?
Currently I'm "sanitizing" my input by doing the following:
-
Because characters with accents (é, ô, æ, ø, å) got stored in a funny way in the Database (even though my tables are set to ENGINE=InnoDB
, DEFAULT CHARSET=utf8
and COLLATE=utf8_danish_ci
), I'm now converting input fields that can have accents, using htmlentities().
-
When creating the SQL string to input the data, I use mysql_real_escape_string()
.
I don't think this is enough to prevent attacks though. So suggestions to improvement is greatly appreciated.
发布评论
评论(1)
输入的“消毒”是假的。
您不应该尝试通过过滤(*)或转义输入来保护自己免受注入问题,您应该使用原始字符串,直到将它们放入另一个上下文中为止。此时,您需要针对该上下文的正确转义函数,即用于 MySQL 查询的
mysql_real_escape_string
和用于 HTML 输出的htmlspecialchars
。(WordPress 添加了自己的转义函数,例如
esc_html
,这些函数原则上没有什么不同。)(*:好吧,除了特定于应用程序的要求,例如检查电子邮件地址是否确实是电子邮件 )地址,确保密码合理,等等。还有一个合理的论据可以在输入阶段过滤掉控制字符,尽管实际上很少这样做。)
我强烈建议不要这样做。您的数据库应包含原始文本;如果您将其编码为 HTML,那么对列进行数据库操作就会变得更加困难。您也会将
<
和"
等字符与非 ASCII 字符同时转义。当您从数据库获取数据并出于其他原因使用它时 页面时遇到问题,那么在将文本写入页面的最后一刻之前,不要进行 HTML 转义,而不是将其复制到页面中。如果您在将非 ASCII 字符写入 数据库,这是一个不同的问题,您应该首先解决它,而不是寻求不可持续的解决方法,例如存储 HTML 编码的数据。这里有很多关于让 PHP 和数据库正确使用 UTF-8 的帖子,但最重要的是。确保您的 HTML 输出页面本身使用
Content-Type
header/meta 正确地作为 UTF-8 提供,然后检查您的 MySQL 连接是否设置为 UTF-8,例如使用mysql_set_charset()
。是的,这是正确的。只要你这样做,你就不会受到 SQL 注入的攻击。如果您在数据库端而不是模板输出端进行 HTML 转义,您可能容易受到 HTML 注入(导致 XSS)。因为任何未经过数据库的字符串(例如直接从
$_GET
获取)都不会被 HTML 转义。Input “sanitisation” is bogus.
You shouldn't attempt to protect yourself from injection woes by filtering(*) or escaping input, you should work with raw strings until the time you put them into another context. At that point you need the correct escaping function for that context, which is
mysql_real_escape_string
for MySQL queries andhtmlspecialchars
for HTML output.(WordPress adds its own escaping functions like
esc_html
, which are in principle no different.)(*: well, except for application-specific requirements, like checking an e-mail address is really an e-mail address, ensuring a password is reasonable, and so on. There's also a reasonable argument for filtering out control characters at the input stage, though this is rarely actually done.)
I strongly advise not doing that. Your database should contain raw text; you make it much harder to do database operations on the columns if you've encoded it as HTML. You're escaping characters such as
<
and"
at the same time as non-ASCII characters too. When you get data from the database and use it for some other reason than copying it into the page, you've now got spurious HTML-escapes in the data. Don't HTML-escape until the final moment you're writing text to the page.If you are having trouble getting non-ASCII characters into the database, that's a different problem which you should solve first instead of going for unsustainable workarounds like storing HTML-encoded data. There are a number of posts here all about getting PHP and databases to talk proper UTF-8, but the main thing is to make sure your HTML output pages themselves are correctly served as UTF-8 using the
Content-Type
header/meta. Then check your MySQL connection is set to UTF-8, eg usingmysql_set_charset()
.Yes, that's correct. As long as you do this you are not vulnerable to SQL injection. You might be vulnerabile to HTML-injection (causing XSS) if you are HTML-escaping at the database end instead of the template output end. Because any string that hasn't gone through the database (eg. fetched directly from
$_GET
) won't have been HTML-escaped.