验证用户输入？
我对某事感到非常困惑，想知道是否有人可以解释。
在 PHP 中，我验证用户输入，因此 htmlentitiies、mysql_real_escape_string 在插入数据库之前使用，而不是在所有内容上使用，因为我更喜欢尽可能使用正则表达式，尽管我发现它们很难使用。现在显然我将使用 mysql_real_escape_string 因为数据正在进入数据库，但不确定我是否应该仅在从数据库获取数据并将其显示在网页上时使用 htmlentities() ，因为事先这样做会改变一个人输入的数据不保留它的原始形式，如果我想稍后将该数据用于其他用途，这可能会导致问题。
例如，我有一本留言簿，其中包含 3 个字段：名称、主题和消息。现在显然这些字段可以包含任何东西，比如js标签中的恶意代码，基本上任何东西，现在让我困惑的是，假设我是一个恶意的人，我决定使用js标签和一些恶意js代码并提交表单，现在基本上我有恶意我的数据库中无用的数据。现在，通过在将恶意代码输出到网页（留言簿）时使用 htmlentities，这不是问题，因为 htmlentities 已将其转换为安全的等效项，但同时我在数据库中有无用的恶意代码，而我不想拥有这些代码。
所以说完这一切之后，我的问题是我是否应该接受这样一个事实：数据库中的某些数据可能是恶意的、无用的数据，只要我在输出上使用 htmlentities，一切都会好的，还是我也应该做其他事情？
我读了很多书，说在接收数据时过滤数据，在输出数据时转义数据，以便保留原始形式，但他们只给出了一些例子，例如使用已内置于 php 的函数确保字段只是一个 int 等，但我从未找到过关于确保像留言簿这样的内容，您希望用户输入他们想要的任何内容，以及如何过滤除 mysql_real_escape_string() 之外的此类数据，以确保它不会破坏数据库查询？
有人可以最终为我消除这种困惑，并告诉我我应该做什么以及最佳实践是什么吗？
感谢任何可以解释的人。
干杯!
I am very confused over something and was wondering if someone could explain.
In PHP i validate user input so htmlentitiies, mysql_real_escape_string is used before inserting into database, not on everything as i do prefer to use regular expressions when i can although i find them hard to work with. Now obviously i will use mysql_real_escape_string as the data is going into the database but not sure should i be using htmlentities() only when getting data from database and displaying it on a webpage as doing so before hand is altering the data entered by a person which is not keeping it's original form which may cause problems if i want to use that data later on for use for something else.
So for example, i have a guestbook with 3 fields name, subject and message. Now obviously the fields can contain anything like malicious code in js tags basically anything, now what confuses me is let say i am a malicious person and i decided to use js tags and some malicous js code and submit the form, now basically i have malicious useless data in my database. Now by using htmlentities when outputting the malicious code to the webpage (guestbook) that is not a problem because htmlentities has converted it to it's safe equivalent but then at the same time i have useless malicious code in the database that i would rather not have.
So after saying all this my question is should i accept the fact that some data in the database maybe malicious, useless data and as long as i use htmlentities on output everything will be ok or should i be doing something else aswell?.
I read so many books saying about filtering data on receiving it and escaping it on outputting it so the original form is kept but they only ever give examples like ensuring a field is only an int using functions already built into php etc but i have never found anything in regards ensuring something like a guestbook where you want users to type anything they want but also how you would filter such data apart from mysql_real_escape_string() to ensure it does not break the DB query?
Could someone please finally close this confusion for me and tell me what i should be doing and what is best practice?
Thanks to anyone who can explain.
Cheers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
mysql_real_escape_string()就是数据库操作所需的全部内容。它将确保恶意用户无法将某些内容嵌入到数据中，从而“破坏”您的查询。当您向客户端/浏览器发送内容时，
htmlentities()和htmlspecialchars()就会发挥作用。如果你想清理潜在的恶意 HTML，你最好使用 HTMLPurifier，它会将数据剥离到基岩并用漂白剂将其冲洗并正确重建。mysql_real_escape_string()is all you need for the database operations. It'll ensure that a malicious user can't embed something into data that'll "break" your queries.htmlentities()andhtmlspecialchars()come into play when you're working with sending stuff to the client/browser. If you want to clean up potentially hostile HTML, you'd be better off using HTMLPurifier, which will strip the data to the bedrock and hose it down with bleach and rebuild it properly.如果您在 HTML 出现时对其进行转义，则无需担心数据库中存在恶意 JavaScript 代码。只要确保您始终转义来自数据库的任何内容即可。
There's no reason to worry about having malicious JavaScript code in the database if you're escaping the HTML when it comes out. Just make sure you always do escape anything that comes out of the DB.
这是一个很长的问题，但我认为您实际上要问的问题可以归结为：
“我应该在将 HTML 插入数据库之前或在显示它时对其进行转义吗？”
这个问题的普遍接受的答案是，当您向用户显示 HTML 时，您应该转义 HTML（通过
htmlspecialchars），而在将其放入数据库之前不 。原因是这样的：数据库存储数据。您输入的内容就是用户输入的内容。当您调用 mysql_real_escape_string 时，它不会改变插入数据库的内容；它只是避免将用户的输入解释为 SQL 语句。
htmlspecialchars对 HTML 做同样的事情；当您打印用户的输入时，它将避免将其解释为 HTML。如果您在插入之前调用htmlspecialchars，那么您就不再忠实。您应该始终努力获得可以获得的最大保真度表示。由于将“恶意”代码存储在数据库中不会造成任何损害（事实上，它可以为您节省一些空间，因为转义的 HTML 比未转义的 HTML 更长！），并且您将来可能想要该 HTML (如果您对用户评论使用 XML 解析器，或者有一天让受信任的用户在他们的评论中包含 HTML 子集，或者类似的东西，会怎么样？），为什么不顺其自然呢？
您还询问了一些有关其他类型的输入验证（整数约束等）的问题。您的数据库模式应该强制执行这些，并且也可以在应用程序层检查它们（最好通过 JS 输入，然后再次在服务器端检查）。
另一方面，使用 PHP 进行数据库转义的最佳方法可能是使用 PDO，而不是直接调用 mysql_real_escape_string。 PDO 具有更高级的功能，包括类型检查。
This is a long question, but I think what you're actually asking boils down to:
"Should I escape HTML before inserting it into my database, or when I go to display it?"
The generally accepted answer to this question is that you should escape the HTML (via
htmlspecialchars) when you go to display it to the user, and not before putting it into the database.The reason is this: a database stores data. What you are putting into it is what the user typed. When you call
mysql_real_escape_string, it does not alter what is inserted into the database; it merely avoids interpreting the user's input as SQL statements.htmlspecialcharsdoes the same thing for HTML; when you print the user's input, it will avoid having it interpreted as HTML. If you were to callhtmlspecialcharsbefore the insert, you are no longer being faithful.You should always strive to have the maximum-fidelity representation you can get. Since storing the "malicious" code in your database does no harm (in fact, it saves you some space, since escaped HTML is longer than unescaped!), and you might in the future want that HTML (what if you use an XML parser on user comments, or some day let trusted users have a subset of HTML in their comments, or some such?), why not let it be?
You also ask a bit about other types of input validation (integer constraints, etc). Your database schema should enforce these, and they can also be checked at the application layer (preferably on input via JS and then again server side).
On another note, the best way to do database escaping with PHP is probably to use PDO, rather than calling
mysql_real_escape_stringdirectly. PDO has more advanced functionality, including type checking.