我是网络编程的新手，一直在探索与网络安全相关的问题。
我有一个表单，用户可以发布两种类型的数据 - 让我们称之为“安全”和“不安全”（从sql的角度来看）。
大多数地方建议在清理“不安全”部分后将数据的两部分存储在数据库中（以使其“安全”）。
我想知道一种不同的方法 - 将“安全”数据存储在数据库中，将“不安全”数据存储在文件中（数据库外）。当然，这种方法会产生一系列与维护文件和数据库条目之间关联有关的问题。但这种方法还有其他重大问题，特别是与安全性有关吗？
更新：感谢您的回复！抱怨我不清楚自己是什么 考虑到“安全”，所以要做一些澄清。我正在使用Django和表单 我正在考虑“安全”的数据是通过表单的“cleaning_data”访问的 执行所有必要逃脱的词典。
出于这个问题的目的，让我们考虑一个维基页面。的标题 维基页面不需要附加任何样式。所以，这可以访问 通过表单的“cleaning_data”字典将用户输入转换为 “安全”格式。但是因为我希望为用户提供任意风格的能力 他们的内容，我无法使用“cleaning_data”字典访问内容部分。
文件方法是否解决了此问题的安全方面？或者还有其他 我忽视的安全问题？
答案 0 :(得分：1)
您知道您正在谈论的“安全”数据吗？事实并非如此。它所有不安全，你应该这样对待它。不是通过将其存储在文件中，而是通过正确构建SQL语句。
正如其他人所提到的那样，使用准备好的陈述或模拟它们的库是可行的方法，例如
$db->Execute("insert into foo(x,y,z) values (?,?,?)", array($one, $two, $three));
答案 1 :(得分：0)
您认为“安全”和“不安全”是什么？您是否正在考虑使用斜线转义为“安全”的数据？如果是这样，请不要。
将绑定变量与SQL占位符一起使用。它是防止SQL注入的唯一合理方法。
答案 2 :(得分：0)
拆分数据不会保护您免受SQL注入，它只会限制可以通过它暴露的数据，但这不是攻击的唯一风险。他们还可以删除数据，添加虚假数据等。
我认为没有理由使用您的方法，特别是考虑到使用预准备语句（在许多（如果不是全部）开发平台和数据库中都支持）。
即使进入噩梦，你的方法最终也会成为现实。
最后，如果你不相信它，你为什么要使用数据库呢？如果你愿意，只需使用普通文件，混合是禁止的。
答案 3 :(得分：0)
SQL注入不仅可以针对整个数据库用户，而且是查询（中毒查询）的问题，所以对我来说，避免SQL注入攻击的最佳方法（如果不是唯一的）是控制你的查询，保护它免受注入恶意字符而不是分割存储的可能性。