blocks|key|66000|text|您的数据有不同的上下文。将数据插入数据库的上下文需要与呈现html/xml或甚至电子邮件消息的上下文不同地进行转义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|66001|在所有新代码中，都应该弃用进入db的转义数据，而支持准备好的语句。任何人告诉你不是这样的，都是在给你带来极大的伤害。|66002|进入浏览器的转义数据需要以多种不同的方式进行转义，具体取决于目标。有时候htmlspecialchars就足够了，有时候你需要使用htmlentities。有时，您需要数字实体。这是一个你应该做一些研究的主题，以了解所有的细微差别。|66003|我赖以生存的一般规则是验证(不是过滤器，如果不正确则拒绝)输入和转义输出(基于上下文)。|66004|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

There are different contexts for your data. The context of inserting data into the database needs to be escaped differently than the context of rendering html/xml or even an email message.

Escaping data going into a db should be deprecated in all new code in favor of prepared statements. Anyone who tells you otherwise is doing you a great disservice.

Escaping data going to the browser needs to be escaped in a number of different ways depending on the target. Sometimes htmlspecialchars is enough, sometimes you need to use htmlentities. Sometimes you need numeric entities. It is a topic you should do some research on to know all of the nuances.

The general rule I live by is validate (not filter, reject if incorrect) input &amp; escape output (based on context).

blocks|key|2502907|text|它们是用于不同目的的不同工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2502908|mysqli_real_escape_string使得数据可以安全地插入到MySQL中(但参数化查询更好)。|2502909|Htmlentities使数据可以安全地输出到HTML文档中|2502910|地址斜杠使数据在其他几种情况下是安全的，但对于MySQL是不够的|2502911|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

They are different tools for different purposes.

mysqli_real_escape_string makes data safe for inserting into MySQL (but parametrized queries are better).

Htmlentities makes data safe for outputting into an HTML document

addslashes makes data safe for a few other situations, but is insufficient for MySQL

blocks|key|65919|text|如果您可能在服务器上使用PHP5，您也可以使用PDO+libs，它为您完成大部分转义操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|65920|在回显时，我个人更喜欢htmlspecialchars，但有人可能会纠正我|65921|entityMap|0|LINK|mutability|MUTABLE|url|http://php.net/manual/de/book.pdo.php^0|N|8|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

You could also use the <a href="http://php.net/manual/de/book.pdo.php" rel="nofollow noreferrer">PDO libs</a> which does most of the escaping for you, in case you may use PHP5 on the servers.

On echoing back I'd personally prefer htmlspecialchars, but one might correct me

blocks|key|1092823|text|是的，在所有用户输入上使用mysqli_real_escape_string或类似PDO的库。回显时，我使用ENT_QUOTES作为第二个参数的htmlentities，因为它将所有适用的字符转义到它们的html实体，包括引号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1092824|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

yes, use the mysqli_real_escape_string or a library like PDO on all user input. When echoing back, I use htmlentities with ENT_QUOTES as the second parameter, as it escapes all applicable characters to their html entities, including quotes.

blocks|key|2503078|text|注意:应该避免在UTF-8编码的文档中使用htmlentities()。请参见：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2503079|2503080|Interfacing+with+Systems+using+other+Charsets|unordered-list-item|offset|length|2503081|Common+Problem+Areas+with+UTF-8|2503082|2503083|注意(引用自phpwact.org)：|2503084|2503085|有了现代的网络浏览器和对UTF-8的宽屏支持，你不需要htmlentities，因为所有这些字符都可以直接用UTF-8表示。更重要的是，一般来说，只有浏览器支持HTML的特殊字符-例如，普通的文本编辑器无法识别HTML实体。根据您正在做的事情，使用htmlentities可能会降低其他系统“消费”您的内容的能力。|blockquote|2503086|2503087|此外(未经确认，但听起来合理-从这里的注释开始)，当文档作为application/xml%2Bxhtml+(除非您定义它们)时，字符实体(如»或-)不起作用。不过，您仍然可以使用数字表单。|2503088|entityMap|0|LINK|mutability|MUTABLE|url|http://www.phpwact.org/php/i18n/charsets#interfacing_with_systems_using_other_charsets|1|http://www.phpwact.org/php/i18n/charsets#common_problem_areas_with_utf-8|2|http://www.phpwact.org/^0|0|0|0|19|0|0|0|V|1|0|0|6|B|2|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|17|8|@]|9|@$F|18|G|19|1|1A]]|A|$]]|$1|H|3|I|5|E|7|1B|8|@]|9|@$F|1C|G|1D|1|1E]]|A|$]]|$1|J|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1G|8|@]|9|@$F|1H|G|1I|1|1J]]|A|$]]|$1|M|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1L|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1N|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]|11|$5|W|X|Y|A|$Z|12]]|13|$5|W|X|Y|A|$Z|14]]]]

Note: Using htmlentities() in an UTF-8 encoded document should be avoided. See: 

<ul>
<li><a href="http://www.phpwact.org/php/i18n/charsets#interfacing_with_systems_using_other_charsets" rel="nofollow noreferrer">Interfacing with Systems using other Charsets</a></li>
<li><a href="http://www.phpwact.org/php/i18n/charsets#common_problem_areas_with_utf-8" rel="nofollow noreferrer">Common Problem Areas with UTF-8</a></li>
</ul>

Pay attention to (quoted from <a href="http://www.phpwact.org/" rel="nofollow noreferrer">phpwact.org</a>):

<blockquote>
 With modern web browsers and widespead
 support for UTF-8, you don’t need
 htmlentities because all of these
 characters can be represented directly
 in UTF-8. More importantly, in
 general, only browsers support HTML‘s
 special characters - a normal text
 editor, for example, is unaware of
 HTML entities. Depending on what
 you’re doing, using htmlentities may
 reduce the ability of other systems to
 “consume” your content.
 
 Also (not confirmed but sounds
 reasonable - from anon comment here),
 character entities (stuff like » or —)
 do not work when a document is served
 as application/xml+xhtml (unless you
 define them). You can still get away
 with the numeric form though.
</blockquote>

blocks|key|1092968|text|PHP5.2及更高版本的另一个有趣的解决方案是使用filter扩展：http://www.php.net/manual/en/book.filter.php|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1092969|它允许您验证和清理用户输入。有许多内置的过滤器可用，它们可以与标志相结合来调整其行为。此外，这些过滤器还可以用于验证/清理int、浮点数、电子邮件和特定的正则表达式。|1092970|我个人已经开始在我的项目中使用它们来验证表单和输出用户输入的数据，我很高兴我这样做了。不过，当我在MySQL数据库中插入值时，我会使用准备好的查询来提高安全性。这些解决方案结合在一起可以帮助避免大多数SQL注入和XSS类型的攻击。|1092971|entityMap|0|LINK|mutability|MUTABLE|url|http://www.php.net/manual/en/book.filter.php^0|Y|18|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

Another interesting solution for PHP 5.2 and above is to use the filter extension: <a href="http://www.php.net/manual/en/book.filter.php" rel="nofollow noreferrer">http://www.php.net/manual/en/book.filter.php</a>

It allows you to validate and sanitize user inputs. There are many built-in filters available and they can be combined with flags to tweak their behaviour.
In addition hese filters can also be used to validate/sanitize ints, floats, emails, specific regular expressions.

I personally have started using them in my projects to validate forms and to output user-entered data, and I am very glad I did. Although, when I insert values in a MySQL database, I use prepared queries for added security. These solutions together can help avoid most SQL injections and XSS-type attacks.

blocks|key|66059|text|你不能只有一个“逸出”函数，并期望它一直都能工作。有不同的攻击需要特定的卫生例程。理解这个概念的唯一方法是编写一些易受攻击的代码，然后利用它。编写利用漏洞代码对于理解任何安全系统都是至关重要的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|66060|例如，以下查询容易受到Sql注入的攻击：|66061|$host=htmlspecialchars($_GET[host],ENT_QUOTES);
$name=htmlspecialchars($_GET[name],ENT_QUOTES);
mysql_query("select+*+from+user+where+Host='$host'+and+Name='$name'+");|code-block|syntax|javascript|66062|漏洞：http://localhost/sqli_test.php?host=\&name=%2520sleep(20)--%25201|offset|length|66063|mysql的最佳转义函数是mysqli_real_escape_string()，但这可能会失败：|66064|mysql_query("select+*+from+user+where+id=".mysqli_real_escape_string($_GET[id]));|66065|漏洞：http://localhost/sqli_test.php?id=1%2520or%2520sleep(20)|66066|实际上，处理sql注入的最好方法不是调用转义函数，而是使用ADODB的参数化quires来进行sql注入。对XSS使用htmlspecialcahrs($var，ENT_QUTOES)。请阅读OWASP+top+10，因为web应用程序安全方面存在的问题远不止这些。|66067|entityMap|0|LINK|mutability|MUTABLE|url|http://localhost/sqli_test.php?host=|1|http://localhost/sqli_test.php?id=1%2520or%2520sleep(20)|2|http://www.owasp.org/index.php/Top_10_2007^0|0|0|0|3|10|0|0|0|0|3|1G|1|0|2O|C|2|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|19|8|@]|9|@$K|1A|L|1B|1|1C]]|A|$]]|$1|M|3|N|5|6|7|1D|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1E|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@$K|1G|L|1H|1|1I]]|A|$]]|$1|S|3|T|5|6|7|1J|8|@]|9|@$K|1K|L|1L|1|1M]]|A|$]]|$1|U|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]|12|$5|X|Y|Z|A|$10|13]]|14|$5|X|Y|Z|A|$10|15]]]]

You can't have one "escape" function and expect it to work all of the time. There are different attacks that require specific sanitation routines. The only way to understand this concept is to write some vulnerable code and then exploit it. Writing exploit code is vital to the understanding of any security system. 

For instance this query is vulnerable to Sql injection:

<pre><code>$host=htmlspecialchars($_GET[host],ENT_QUOTES);
$name=htmlspecialchars($_GET[name],ENT_QUOTES);
mysql_query("select * from user where Host='$host' and Name='$name' ");
</code></pre>

Exploit:
<a href="http://localhost/sqli_test.php?host=" rel="nofollow noreferrer">http://localhost/sqli_test.php?host=</a>\&amp;name=%20sleep(20)--%201

The best escape function for mysql is mysqli_real_escape_string() but this can fail:

<pre><code>mysql_query("select * from user where id=".mysqli_real_escape_string($_GET[id]));
</code></pre>

exploit:
<a href="http://localhost/sqli_test.php?id=1%20or%20sleep(20)" rel="nofollow noreferrer">http://localhost/sqli_test.php?id=1%20or%20sleep(20)</a>

In fact the best way to take care of sql injection isn't calling an escape function, Its using ADODB's parametrized quires for sql injection. Use htmlspecialcahrs($var,ENT_QUTOES) for XSS. Read the <a href="http://www.owasp.org/index.php/Top_10_2007" rel="nofollow noreferrer">OWASP top 10</a> because there is a whole lot more than can go wrong with web application security.

I've been doing some reading on securing PHP applications, and it seems to me that <code>mysqli_real_escape_string</code> is the correct function to use when inserting data into MySQL tables because <code>addslashes</code> can cause some weird things to happen for a smart attacker. Right?

However, there is one thing that is confusing me. I seem to remember being advised <code>addslashes</code> is better than <code>htmlentities</code> when echoing user-entered data back to users to protect their data, but it seems like <code>addslashes</code> is the one with the vulnerability. Is this true, or am I remembering incorrectly?

Htmlentities vs addslashes vs mysqli_real_escape_string

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我读过一些关于保护PHP应用程序的文章，在我看来，在将数据插入到MySQL表中时，mysqli_real_escape_string是正确的函数，因为对于聪明的攻击者来说，addslashes可能会导致一些奇怪的事情发生。对吗？然而，有一件事让我感到困惑。我似乎记得有人建议在将用户输入的数据回显给用户以保护他们的数据时，addslashes比htmlentities更好，但似乎addslashes

问Htmlentities vs addslashes vs mysqli_real_escape_string
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Htmlentities vs addslashes vs mysqli_real_escape_stringEN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Htmlentities vs addslashes vs mysqli_real_escape_string
EN