什么是最好的,转义然后存储还是存储然后转义输出?

发布于 2024-08-27 02:25:14 字数 161 浏览 8 评论 0原文

在 stackoverflow 上进行了长时间的搜索后,我没有找到任何人谈论这个,即使这是一个很大的选择,问题是为了防止 XSS 和 SQL 注入,最好的方法是什么,转义数据然后将其存储在数据库中或者按原样存储并在输出时转义?

注意:如果可能的话,最好给出一些实践示例。

谢谢

After doing a long search on stackoverflow i didn't find any one talked about this even if it's a big choice, the Question is what's the best in order to prevent both of XSS and SQL injection, Escaping the data then store it in the DB or Store it as it is and escape when output it?

Note: it is better if you give some examples of practics if possible.

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

情深如许 2024-09-03 02:25:14

数据必须经过正确的 SQL 转义(或按照其他人的建议与 SQL 分开发送)以进行存储, HTML 转义以供显示。

The data must be properly SQL-escaped (or sent separately from the SQL, as others suggest) for storage, and HTML-escaped for display.

自我难过 2024-09-03 02:25:14

按顺序,您应该执行以下操作 -

  1. 验证输入以查看其是否符合您的期望。如果没有,则拒绝输入并停止。如果满足,请继续执行下一步,不更改输入。

  2. 将输入绑定到参数化查询,或在形成查询时转义输入。请注意,转义输入不会改变输入。数据库将始终包含用户输入的确切字符串。

  3. 向用户显示时,必须根据上下文进行转义。大约有 5 种不同的方法可以对同一字符串进行转义 - 取决于您是将其显示在 HTML 元素、HTML 属性、Javascript、CSS 还是 URL 中。请参阅http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting %29_Prevention_Cheat_Sheet。再次记住,转义不会改变字符串。用户必须始终看到他输入的确切字符串。

您可能想将修改后的字符串存储在数据库中 - 但请不要这样做。如果在 HTML 中对其进行转义,则永远无法在 javascript 中使用该字符串。如果您必须进行后端处理,则必须对字符串进行转义。你很快就会到达一个无法再做正确事情的阶段。

请记住,转义只是将数据从一层传输到另一层的一种方法。在静止状态(数据库或屏幕),数据应该看起来与用户输入的方式完全相同。

In order, you should do the following -

  1. Validate the input to see if it meets your expectation. If it doesn't, reject the input and stop. If it meets, continue to next step without altering the input.

  2. Bind the input to a parameterized query, or escape the input as you are forming the query. Note that escaping the input does not alter the input. The database will always contain the exact string the user entered.

  3. When displaying to the user, you have to escape it according to the context. There are around 5 distinct ways in which the same string can be escaped - depending on whether you are displaying it in HTML element, HTML attribute, Javascript, CSS, or as a URL. See http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet. Again, remember that escaping doesn't alter the string. The user must always see the exact string he had entered.

You may be tempted to store a modified string in the database - but please don't do so. If you escape it for HTML, you can never use the string in javascript. If you have to do back-end processing, you'd have to de-escape the string. You will soon reach a stage where you can't do the right thing anymore.

Remember that escaping is just a way to transport data from one layer to another. At rest (database or screen), the data should look exactly the way the user entered it.

再浓的妆也掩不了殇 2024-09-03 02:25:14

您的问题没有多大意义,因为尝试存储包含 SQL 注入的数据的行为正是导致 SQL 注入的原因。

无论哪种方式,您都应该使用参数化查询来防止 SQL 注入。

对于 XSS/HTML 转义,我个人宁愿在插入时执行此操作,因为这样您只需执行一次处理,而不是每次显示时执行该处理。一个小的优化,但是很简单。

Your question doesn't make much sense, because the very act of trying to store data containing an SQL injection is what causes the SQL injection.

Either way, you should be using Parameterized queries to prevent SQL injection.

For XSS/HTML escaping, I'd personally rather do it at insertion-time, because then you only have to do that processing once, instead of every time it's displayed. A small optimization, but an easy one.

飞烟轻若梦 2024-09-03 02:25:14

转义输入,存储,然后转义输出。


如果您在存储时不进行转义,则很容易受到 SQL 注入的攻击。

示例:您有一个查询:

mysql_query("SELECT * FROM `table` WHERE `abc`= '{$_POST['def']}';

假设 $_POST['def'] 等于

blah'; DROP TABLE `table`; SELECT * FROM `table` WHERE 'abc' = '123

如果未转义,这将导致您的表被删除。


如果你不转义就输出,你就很容易受到 XSS 的攻击。

否则,用户可以将有害的 Javascript 注入其他用户可以查看的页面中。

Escape input, store, then escape output.


If you store without escaping, you're vulnerable to SQL injection.

Example: You have a query:

mysql_query("SELECT * FROM `table` WHERE `abc`= '{$_POST['def']}';

Let's say that $_POST['def'] is equal to

blah'; DROP TABLE `table`; SELECT * FROM `table` WHERE 'abc' = '123

That will cause your table to be dropped if it's not escaped.


If you output without escaping, you're vulnerable to XSS.

Otherwise, users can inject harmful Javascript into pages other users can view.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文