我已经阅读了SQL注入，XSS和其他安全问题，并试图找出用于保护公司网站的内容。
我们即将使用textarea部署一个简单的“用户反馈”表单，以便用户可以告诉我们如何改进网站以增强用户体验。
当用户在表单上按“提交”时，我们会读取用户的textarea注释，然后以编程方式在该用户的子文件夹中创建文件名并将其注释保存到文件中。然后我们将文件名和路径添加到该用户的数据库记录中。
团队并不担心这里的安全问题，但我是。他们的想法是“我们根据任何用户输入创建文件名，它是0％，因为我们将这个'UserX comments'文件名和路径写入数据库而没有直接的用户影响 - 所以没有风险。”
我担心的不是数据库活动 - 因为它们是对的，用户在我们写入数据库记录的内容中没有任何作用，因为我们只是创建自己的文件名并将其存储在数据库记录中。
我关注的是文本文件！
所以我请求我们的小团队重写代码以使用安全性来读取然后将用户在textarea中的注释写入文本文件。
我担心的是 - 因为我们计划实际阅读用户的反馈并打开这些文本文件以便稍后阅读 - 在textarea中可能有不好的东西（除非我们清理它）可能会以某种方式伤害我们。 / p>
我坚持要使用strip_tags（），但我需要了解我们清理textarea输入的方式 - 我在想strip_tags（）是去这里的方法，但我是100％新的消毒用户输入。我查看了htmlspecialchars（），但只是转换某些字符，如'＆amp;'到＆amp; 等等。
在我们将其写入我们的网络服务器上的文件之前，还有其他方法可以将用户键入文本区域的任何文本进行santize / make安全吗？
答案 0 :(得分：3)
看起来strip_tags是一个很好的方法。我还建议在webroot之外编写文件，以便浏览器无法访问它。 另见：This Other Thread
答案 1 :(得分：3)
如果您不担心SQL注入，而且似乎您不是（因为您知道SQL已被清理或因为您正在保存到文本文件），那么另一个问题是可能的XSS攻击
很容易忽略这些，它们不会直接影响你。 XSS攻击是一种攻击，允许用户将客户端脚本注入网页。您的数据库工作正常，您的服务器文件未被修改，您的会话文件也未被修改。
此漏洞完全是客户端漏洞。就像我说的，它不会影响你的服务器。但是有人（即：我）会访问您的网站，并且在查看完全SFW，可信赖的网站时，会突然重定向到Warez网站。您失去了对用户的信任。抓取您网站的搜索引擎也会将您标记为可能有害。你失去了流量。你失去了收入。然后，你的服务器完全没问题。
您肯定需要清理用户输入，因为这样会将输出回。是的，strip_tags是一个解决方案，因此htmlspecialchars或htmlentities。
strip_tags限制性稍差，因为它允许您定义一些您希望用户能够在其帖子中插入的标记，例如粗体，{{ 3}}，或斜体。
总之，你坚持这种做法是绝对正确的。它不会直接影响您（即：您公司的服务器），但如果您想在万维网上建立可信任的存在，它会在某些时候影响您。
我知道这可能比其他人建议strip_tags更长的答案。他们是绝对正确的，这就是我赞成他们的原因。试着在那里给你一些“公司”的论点。 ：）
答案 2 :(得分：2)
这取决于您如何创建文件，以及阅读后您正在对文本做什么。
如果您使用PHP的本机函数来编写文件，那么remote code execution应该没有问题。
如果您在阅读后所做的一切都通过HTML显示给用户htmlentities()，这有效地使文本中的HTML标签无法正常显示给用户，应该足够了。
如果您将其用作对数据库的某些查询的一部分，则应在将其连接到SQL之前使用该数据库清理例程。 （即。mysql_real_escape_string()用于MySQL，或pg_escape_string()用于PostgreSQL）。
您可能还想查看the OWASP page上的一些信息。
编辑：我忘了提及，您还应该使用ENT_QUOTES和htmlentities来阻止单引号注入。
答案 3 :(得分：1)
只需使用mysql_real_escape_string（）来删除引号。 htmlentities（）如果你担心js文件。这应该和它到达那里一样好。
答案 4 :(得分：0)
清理输入只会通过删除某些字符来保护您免受sql注入。但是，这些字符不能在文本文件中以恶意方式起作用。我碰巧知道恶意软件，并相信我，你在这里没有风险。
修改
如果我通过漫无边际错过了这篇文章的重点，请告诉我，以便我可以更新我的答案。
答案 5 :(得分：0)
我的解决方案遵循您的开发团队意识形态的主流：
请勿在您的网站上使用任何用户授权，包括管理员。因此，没有XSS也会伤害你。