可能危险的文本输入处理

我已经阅读了SQL注入，XSS和其他安全问题，并试图找出如何使用来保护公司的网站。可能危险的文本输入处理

我们即将有一个textarea部署一个简单的“用户反馈”的形式，使用户可以告诉我们如何改善网站以提高他们的用户体验。

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

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

我关注的不是数据库活动 - 因为他们是对的，用户有什么，我们写信给他们的数据库记录，因为我们刚刚创建自己的文件名并将其存储在自己的数据库记录没有任何作用。

我的问题是文本文件！

所以我上访我们的小团队重写代码使用安全textarea的文本文件读取然后写入用户的评论。

我担心的是 - 因为我们打算实际阅读我们用户的反馈并打开这些文本文件以供以后阅读 - textarea中可能有坏东西（除非我们清理它）会以某种方式伤害我们。

我坚持我们使用strip_tags（），但我需要听取关于我们清理textarea输入的方式的消息 - 我在想strip_tags（）是这里的路，但我100％新的消毒用户输入。我查看了htmlspecialchars（），但它只是将某些字符（如'&'）转换为& 等等。

是否有其他方式来santize /安全做出的任何文本的用户类型为textarea的我们写出来给我们的Web服务器上的文件之前？

来源

2012-03-10 wantTheBest

'htmlspecialchars'也将'<' and '>'转换为'<'和'>'，这足以防止显示使用输入的任意html。 – kirilloid 2012-03-10 03:23:08

我认为这引发了一个问题：为什么你将这些存储在文本文件而不是数据库中？ – 2012-03-10 03:24:59

上午 - 很好的问题 - 因为这是一个100％的新功能，我们不知道它将使用多少，所以现在我们不添加代码和数据库模块来处理安全问题等，但如果在部署它变成一个不常使用的功能，然后将它存储在数据库中可能会更好。 – wantTheBest 2012-03-10 03:29:18

看起来像strip_tags是一个好方法。我还建议在webroot之外编写文件，以便浏览器无法访问它。另请参阅：This Other Thread

来源

2012-03-10 03:20:32 TecBrat

+1在'webroot之外' - dagnabbit是很好的建议 - 谢谢。 – wantTheBest 2012-03-10 03:49:45

只需使用mysql_real_escape_string（）来摆脱引号。 htmlentities（）如果你担心js文件。这应该和它一样好。

来源

2012-03-10 03:19:33

这里有另一个添加到你的其他 - 没有想过使用real_escape_string（） - 谢谢。 – wantTheBest 2012-03-10 03:50:38

+1 ???? @wantTheBest一般的引号出了什么问题，以及mysql_real_escape_string（）会对他们做些什么？ – 2012-03-10 04:31:08

清理输入只能通过删除某些字符来防止sql注入。但是，这些字符不能从文本文件中以恶意方式进行操作。我碰巧知道很多关于恶意软件的信息，相信我，你在这里没有风险。

编辑：

如果我种种原因错过了这个职位通过我的散漫的点，不要让我知道这样我就可以更新我的答案。

来源

2012-03-10 03:21:31

+1感谢一丝解脱的灵感。我想我只是想知道在创建一个文件之前知道我没有在磁盘上写入任何有潜在危险的东西。 – wantTheBest 2012-03-10 03:52:09

不是问题，你肯定不是。您必须将该文件保存为可执行文件，并且STILL，执行恶意脚本所需的足够数据的机会将很少。 – 2012-03-10 04:15:18

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

如果您使用PHP的本地函数来编写文件，那么您应该没有remote code execution问题。

如果您在阅读完所有内容后都会通过HTML htmlentities()向用户显示，这会使文本中的HTML标签无法正常显示，但仍能正确显示给用户，这应该足够了。

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

您可能还想看看关于the OWASP page的一些信息。

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

来源

2012-03-10 03:23:56 Nathan

是的，它基本上是将textarea的'value'读入一个javascript变量，然后使用PHP文件函数将其保存到基于文本光盘的文件中。最初，团队中的任务是阅读所有反馈并向我们所有人进行演示，并优先确定“必须拥有”的东西（许多用户想要/抱怨的东西）。 – wantTheBest 2012-03-10 03:33:35

我应该说用户在推送'提交'后看不到他们的评论 - 他们的评论只是保存到光盘文件中，并且团队成员阅读它们。我们的网站上没有UI，用户可以阅读或编辑他们之前提交的评论。 – wantTheBest 2012-03-10 03:39:50

+1 Nathan感谢伟大的链接 - 特别是OWASP网站 - man这个网站的安全性是一个很大的范围。我们现在有一些工作要处理我们的网站。 – wantTheBest 2012-03-10 03:57:11

如果您不担心SQL注入，并且看起来不是（因为您知道SQL已经过消毒或因为您正在保存到文本文件中），那么另一个问题是可能的XSS攻击。

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

此漏洞完全是客户端。就像我说的，它不会影响你的服务器。但是随后有人（即：我）会进入您的网站，并突然将其重定向到Warez站点，同时查看完全SFW的可信网站。你失去了用户的信任。抓取您网站的搜索引擎也会将您标记为可能有害。你失去了交通。你失去了收入。然后，你的服务器再好不过了。

您肯定需要消毒是输出回，因为这个用户的用户输入。是的，strip_tags是一个解决方案，所以htmlspecialchars或htmlentities。

strip_tags是少一点限制然而，因为它允许你定义一些您希望用户能够在自己的岗位插入，像大胆，links，或斜体标签。

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

我知道这可能比其他谁应该建议只有strip_tags更长的答案。他们是完全正确的，这就是为什么我提高了他们的原因。试图给你一些“公司”的论据。 :)

来源

2012-03-10 03:49:37 netcoder

+1那里 - 哇客户端脚本注入（听起来像XSS一点）。我会阅读它。在某些时候，当这种情况发生时，如同上面提到的几个人一样，项目会像任何网站一样发展，最终这个'用户反馈'输入可能会在用户提交后可以被用户查看和编辑，并且可以保存到数据库中 - - 客户端脚本注入，man。 “你肯定需要清理因此输出回用户的用户输入。”谢谢你的澄清。 – wantTheBest 2012-03-10 04:04:36

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

来源

2012-03-10 04:38:06

可能危险的文本输入处理

回答

相关问题