可能有危险的文本输入处理

Posted 2023-05-07

【中文标题】可能有危险的文本输入处理

【英文标题】：possibly dangerous text input handling

【发布时间】：2012-03-27 11:13:08

【问题描述】：

我已经阅读了有关 SQL 注入、XSS 和其他安全问题的信息，并且正在尝试找出使用什么来保护公司的网站。

我们即将部署一个带有文本区域的简单“用户反馈”表单，以便用户告诉我们如何改进网站以增强他们的用户体验。

当用户在表单上按下“提交”时，我们从用户那里读取 textarea cmets，然后以编程方式在该用户的子文件夹中创建一个文件名并将他们的 cmets 保存到一个文件中。然后我们将文件名和路径添加到该用户的数据库记录中。

团队并不担心这里的安全问题，但我担心。他们的想法是“我们创建文件名，它是基于任何用户输入的 0%，并且由于我们将这个 'UserX cmets' 文件名和数据库路径写入数据库，而没有直接的用户影响 - 没有风险。”

我关心的不是数据库活动——因为他们是对的，因为我们只是创建自己的文件名并将其存储在他们的数据库记录中，所以用户对我们写入他们的数据库记录的内容没有任何作用。

我关心的是文本文件！

所以我请求我们的小团队重写代码以使用安全读取然后将用户在 textarea 中的 cmets 写入文本文件。

我担心的是——因为我们计划实际阅读用户的反馈并打开这些文本文件以便稍后阅读——文本区域中可能有一些不好的东西（除非我们清理它）可能会以某种方式伤害我们。

我坚持我们使用 strip_tags() 但我需要了解我们清理 textarea 输入的方式——我认为 strip_tags() 是这里的方法，但我是 100% 新的清理用户输入。我查看了 htmlspecialchars() 但这只是将某些字符（如 '&' 转换为 & 等等。

在我们将用户输入到 textarea 中的任何文本写入我们的网络服务器上的文件之前，是否有其他方法可以净化/确保其安全？

【问题讨论】：

htmlspecialchars 还将< 和> 转换为< 和>，这足以防止显示任意html 使用输入。

我认为这引出了一个问题：为什么将这些存储在文本文件而不是数据库中？

AM -- 好问题 -- 因为这是一个 100% 的新功能，我们不知道它会被使用多少，所以现在我们不添加代码和数据库模块来处理安全性问题等，但如果在推出后它被证明是该网站不经常使用的功能，那么将其存储在数据库中可能会更好。

阅读用户提供的数据的“安全性”完全取决于您打算如何阅读它。如果您只是要将文件转储到打印机，那么建议 html 清理完全没用，并且它具有导致打印机着火的嵌入式 PCL 或 EPS。

上校。弹片，您将句柄更改为“您的常识”-您是这个精美论坛上的巨魔，我只是标记您让站点管理员查看是否需要防止您在这些帖子中自欺欺人。通过成为一个磨蚀性的大洞来寻求关注是愚蠢的。问问自己这个问题：“我是否像其他优秀且有用的回复一样提供了有价值的反馈？或者我是一个粗暴的、寻求关注的空洞巨魔？”不管你的反省和当之无愧的自我谴责，我已经标记你要求管理员见证一个粗暴的巨魔。

【参考方案1】：

看起来 strip_tags 是一个不错的选择。我还建议在 webroot 之外编写文件，以便浏览器无法访问它。 另见：This Other Thread

【讨论】：

+1 在“webroot 之外”——dagnabbit 是个好建议——谢谢。

【参考方案2】：

如果您不担心 SQL 注入，而您似乎并不担心（因为您知道 SQL 已经过清理，或者因为您正在保存到文本文件），那么另一个问题是可能的 XSS 攻击.

很容易忽略这些，它们不会直接影响您。 XSS 攻击是一种允许将客户端脚本注入网页的攻击。您的数据库工作正常，您的服务器文件没有被修改，您的会话文件也没有被修改。

这个漏洞完全是客户端的。就像我说的，它不会影响您的服务器。但是随后有人（即：我）访问了您的网站，突然间被重定向到 Warez 网站，同时查看了一个完全 SFW、受信任的网站。您失去了用户的信任。抓取您网站的搜索引擎也会将您标记为可能有害。你会失去流量。你会失去收入。再说一次，您的服务器非常好。

因此，您肯定需要清理输出回给用户的用户输入。是的，strip_tags 是一个解决方案，htmlspecialchars 或 htmlentities 也是。

strip_tags 的限制要少一些，因为它允许您定义一些您希望用户能够在他们的帖子中插入的标签，例如 bold、links、或斜体。

总之，你坚持这种做法是绝对正确的。它不会直接影响您（即：您公司的服务器），但如果您希望在万维网上获得可信赖的存在，它会在某些时候影响您。

我知道这可能比其他应该只建议strip_tags 的人更长的答案。他们是绝对正确的，这就是为什么我赞成他们。只是想在那里给你一些“公司”的论据。 :)

【讨论】：

+1 那里 - 哇客户端脚本注入（听起来有点像 XSS）。我要仔细阅读它。在某些时候，正如上面的几个人所建议的那样，该项目将像任何网站一样发展，最终这个“用户反馈”输入可能在“提交”后变得用户可查看和可编辑，并可能保存到数据库中 - - 客户端脚本注入，伙计。 “因此，您肯定需要清理输出给用户的用户输入。”感谢您的澄清。

【参考方案3】：

这取决于您如何创建文件，以及您在阅读文本后对文本做了什么。

如果你是使用php的原生函数来写文件，那么remote code execution应该没有问题。

如果您在阅读后所做的只是通过 HTML 向用户显示，htmlentities()，它有效地使文本中的 HTML 标记无能为力，同时仍然正确地向用户显示，就足够了。

如果您将它用作对数据库的某些查询的一部分，则应在将其连接到 SQL 之前使用该数据库清理例程。 （例如，mysql_real_escape_string() 用于 MySQL，pg_escape_string() 用于 PostgreSQL）。

您可能还想查看the OWASP page 上的一些信息。

编辑：我忘了说，您还应该使用 ENT_QUOTES 和 htmlentities 来防止单引号注入。

【讨论】：

是的，它基本上是将 textarea 的“值”读入 javascript 变量，然后使用 PHP 文件函数将其保存到基于文本光盘的文件中。最初，团队的一项轮换任务是阅读所有反馈并向我们所有人进行演示，并优先考虑“必须拥有”的东西（很多用户想要/抱怨的东西）。

我应该说，用户在按下“提交”后看不到他们的 cmets——他们的 cmets 只是被保存到光盘文件中，并且团队成员会读取它们。我们网站上没有供用户阅读或编辑他们之前提交的 cmets 的 UI。

+1 Nathan 感谢伟大的链接——尤其是 OWASP 站点——这个站点的安全性是一个很大的范围。我们目前的网站有一些工作要做。

@wantTheBest 如果实际上您所做的只是将文件保存到磁盘，那么您唯一关心的应该是如何保存它。使用诸如 file_put_contents 或 fwrite 之类的函数不会带来安全风险。此外，如果使用文本编辑器读取文件，那么您甚至不必担心 HTML 过滤。尽管在保存针对 XSS 等最常见问题之前对其进行过滤仍然是一种好习惯，即使您现在不打算使用它，也许以后有人会使用它，但他们可能不知道这些问题。

+1 Nathan，确切地说，我认为未来意味着这个用户反馈实际上将存储在数据库中，现在过滤它意味着它会“成长为它的鞋子”——因为网站发展了我们对团队的集体态度，以加强对清理输入的需求，现在我正在推动它，在此的帮助下，我正在学习我需要知道的东西——谢谢。

【参考方案4】：

只需使用 mysql_real_escape_string() 即可摆脱引号。 htmlentities() 如果您担心 js 文件。这应该和它到达那里一样好。

【讨论】：

这里还有一个 +1 可以添加到你的另一个上——没想到要使用 real_escape_string()——谢谢。

+1???? @wantTheBest 引号一般有什么问题，特别是 mysql_real_escape_string() 会对它们做什么？！

【参考方案5】：

清理输入仅通过删除某些字符来保护您免受 sql 注入。但是，这些字符不能在文本文件中以恶意方式进行操作。我碰巧对恶意软件有相当多的了解，相信我，你在这里没有风险。

编辑：

如果我在漫无目的的过程中错过了这篇文章的重点，请告诉我，以便我更新我的答案。

【讨论】：

+1 感谢您的启发，让您松了一口气。我想我只是喜欢在创建文件之前知道我不会将任何潜在危险的东西写入磁盘的感觉。

没问题，你肯定不是。您必须将文件保存为可执行文件，而且仍然有足够的数据通过以执行恶意脚本的可能性很小。

【参考方案6】：

我有一个符合你们开发团队主流意识形态的解决方案： 不要在您的网站上使用任何用户授权，包括管理员。因此，也没有 XSS 会伤害您。