了解 PHP 中的输入转义
一直让我困惑的一件事是输入转义以及是否受到保护以免受 SQL 注入等攻击。
假设我有一个表单，它使用 HTTP POST 将数据发送到 PHP 文件。 我在输入字段中键入以下内容并提交表单：
"Hello", said Jimmy O'Toole.
如果您在接收此 POST 数据的 PHP 页面上打印/回显输入，则结果为：
\"Hello\", said Jimmy O\'Toole.
这就是令人困惑的地方。 如果我将此输入字符串放入 (My)SQL 并执行它，它会很好地进入数据库（因为引号被转义），但这会阻止 SQL 注入吗？
如果我获取输入字符串并对其调用类似 mysqli real_escape_string 的内容，它的结果是这样的：
\\"Hello\\", said Jimmy O\\'Toole.
因此，当它通过 (My)SQL 进入数据库时，结果是：
\"Hello\", said Jimmy O\'Toole.
这显然有太多斜杠。
因此，如果输入是通过 HTTP POST 转义的，您是否必须再次转义以使其对 (My)SQL 安全？ 或者我只是在这里没有看到明显的东西？
预先感谢您的任何帮助。
One thing that's always confused me is input escaping and whether or not you're protected from attacks like SQL injection.
Say I have a form which sends data using HTTP POST to a PHP file. I type the following in an input field and submit the form:
"Hello", said Jimmy O'Toole.
If you print/echo the input on the PHP page that receives this POST data, it comes out as:
\"Hello\", said Jimmy O\'Toole.
This is the point where it gets confusing. If I put this input string into (My)SQL and execute it, it'll go into the database fine (since quotes are escaped), but would that stop SQL injection?
If I take the input string and call something like mysqli real_escape_string on it, it comes out like this:
\\"Hello\\", said Jimmy O\\'Toole.
So when it goes into the database via (My)SQL, it ends up as:
\"Hello\", said Jimmy O\'Toole.
This obviously has too many slashes.
So if the input comes through HTTP POST as escaped, do you have to escape it again to make it safe for (My)SQL? Or am I just not seeing something obvious here?
Thanks in advance for any help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
啊，神奇引用的奇迹。 它正在从您的 POST 表单中进行不必要的转义。 你应该禁用（或中和）它们，然后你的许多头痛就会消失。
以下是该主题的示例文章：http://www. sitepoint.com/blogs/2005/03/02/magic-quotes-headaches/
回顾：禁用魔术引号，使用
real_escape_string()。Ah, the wonders of magic quotes. It is making those unnecessary escapes from your POST forms. You should disable (or neutralize) them, and many of your headaches go away.
Here's an exemplary article of the subject: http://www.sitepoint.com/blogs/2005/03/02/magic-quotes-headaches/
Recap: disable magic quotes, use
real_escape_string().我不会依赖转义，而是使用参数化 SQL 查询，并让 mysql 驱动程序执行它需要的任何转义操作。
Instead of relying on escaping I would use parametrized SQL queries and let the mysql driver do whatever escaping it needs.
看起来您的 PHP 服务器启用了 Magic Quotes 功能 - 这就是您的第一组斜杠的位置来自。 从理论上讲，应该没有必要调用转义函数 - 但是当应用程序在禁用魔术引号的服务器上运行时，您突然对 SQL 注入敞开了大门，而实际上却认为自己不是。
正如 chakrit 所写，转义并不是保护自己的最佳方法 - 用户参数化查询要安全得多。
It looks like your PHP server has the Magic Quotes feature enabled - that's where your first set of slashes comes from. In theory, it should then be unnecessary to call the escape functions - but when the app runs on a server with magic quotes disabled, you're suddenly wide open to SQL injection while thinking you aren't.
As chakrit wrote, escaping is not the best way to protect yourself - It's much safer to user parameterized queries.
发生的事情是您在 PHP 配置中启用了 Magic Quotes 。
强烈建议您关闭魔术引号 - 事实上，它们已从 PHP 6 中完全删除。
禁用魔术引号后，您将看到发布的文本与您在表单中输入的内容完全相同：
“Hello”，Jimmy O'Toole 说道。现在很明显，您需要使用 mysql 转义函数，甚至更好的准备好的语句（使用准备好的语句，您不会忘记转义字符串，因为它已经为您完成了）。
What's going on is that you have Magic Quotes turned on in your PHP configuration.
It's highly recommended that youturn magic quotes off - in fact, they've been removed from PHP 6 completely.
Once you disable magic quotes, you'll see the POSTed text coming back exactly as you typed it in to the form:
"Hello", said Jimmy O'Toole.It's now obvious that you need to use the mysql escaping functions or even better, prepared statements (with prepared statements you can't forget to escape a string as it's done for you).
显而易见是黑客的关键词。
我认为正常情况下转义就足够了，但是仅仅防止引号可能还不够。
请参阅此 SQL 注入备忘单，这是您可以运行的测试的一个很好的列表看看太多的鞭打是否是一件好事。
并且不要忘记转义其他类型的值，即数字字段和日期时间字段都可以像字符串一样轻松注入。
Obvious is the keyword for a hacker.
I think escaping normally should be enough, but protecting against just the quotes might not be enough.
See this SQL Injection cheatsheet, it's a good list of test you can run and see if too many slahses is a good thing or not.
And don't forget to escape other kinds of values too, i.e. numeric fields and datetime fields can all be injected just as easily as strings.