只是想了解这里的想法,并找到一个正确和公认的方法来解决这个问题.对于上下文,这是在Web环境中,我们正在讨论转义到数据库的输入.

我理解了在获取用户输入并将其存储到数据库中时无法逃避输入的许多原因.您可能希望以各种不同的方式使用该输入(如JSON,SMS等),您也可能希望以原始形式向用户显示该输入.

在将任何内容放入数据库之前,我们确保没有SQL注入攻击来保护数据库.

但是,按照此处和此处列出的原则,他们建议按原样保存用户输入.此用户输入可能不是SQL注入攻击,但可能是其他恶意代码.在这些情况下,可以将基于Javascript的XSS攻击存储到数据库中吗？

我只是想知道我的假设是否正确,只要恶意代码不直接影响数据库,我们是否都可以将恶意代码存储在数据库中？它是不是数据库问题的情况,它可以保存这个恶意代码及其输出设备,以避免恶意代码的陷阱？

或者我们是否应该在输入上进行更多的转移而不是这些原则所建议的 - 安全性问题是否出现在输出转义的概念之前？我们应该采取没有恶意代码进入数据库的方法吗？为什么我们要存储恶意代码呢？

[为了这个目的,我忽略了任何特别允许在它们上共享代码的网站,我正在考虑"正常"输入,例如名称,注释和描述字段.

1> Ben Walther..：

定义:我使用术语"清理"而不是过滤或转义,因为有第三种选择:拒绝无效输入.例如,向用户返回错误,说"字符‽可能不会在标题中使用",因此可以防止必须完全存储它.

按原样保存用户输入

"纵深防御"的安全原则表明,您应该尽早并尽可能地清除任何潜在的恶意输入.白名单仅列出对您的应用程序有用的值和字符串.但即使你这样做,你也必须编码/转义这些值.

为什么我们要存储恶意代码呢？

有时精确度比偏执狂更重要.例如:用户反馈可能需要包含可能具有破坏性的代码.我可以想象编写用户反馈,说"每次我使用类型%00作为维基标题的一部分,应用程序崩溃." 即使维基标题不需要%00字符,评论仍应准确传输它们.如果未在评论中允许此操作,则操作员无法了解严重问题.请参阅:Null Byte Injection

直到输出设备,以避免恶意代码的陷阱

如果您需要存储任意数据,则在切换到任何其他编码类型时,正确的方法是转义.请注意,您必须解码(unescape)然后编码(转义); 没有非编码数据 - 甚至二进制文件至少是Big-Endian或Small-Endian.大多数人使用语言内置的字符串作为"解码最多"的格式,但是在考虑Unicode与ASCII时,即使这样也会变得不稳定.Web应用程序中的用户输入将根据"Content-Type"标头进行URLE编码,HTTP编码或编码.见:http://www.ietf.org/rfc/rfc2616.txt

现在,大多数系统都会为您执行此操作,作为模板化或参数化查询的一部分.例如,参数化查询函数Query("INSERT INTO table VALUES (?)", name)会阻止需要转义单引号或名称中的任何其他内容.如果您没有这样的便利,则有助于创建跟踪每种编码类型的数据的对象,例如HTMLString使用类似NewHTMLString(string)和构造的Decode()函数.

我们应该采取没有恶意代码进入数据库的方法吗？

由于数据库无法确定所有未来可能的编码,因此无法对所有可能的注入进行消毒.例如,SQL和HTML可能不关心反引号,但Javascript和bash可以.