会话变量（$_SESSION）是否需要任何类型的清理答案

【问题标题】：Does a session variable($_SESSION) require any type of sanitiziation会话变量（$_SESSION）是否需要任何类型的清理
【发布时间】：2014-12-30 18:39:31
【问题描述】：

我有一个可以正常工作的注册表单，但最近有人向我指出这对 UX 来说是一个坏习惯，例如，如果一个帐户已经存在，我将用户重定向回注册页面，无需重新填写他填写的表格，仅显示错误消息。

所以我很快想出了一个很好的方法来解决这个问题，如果在初始注册数据签出并且相应电子邮件的帐户已经存在，我可以创建一个 $_SESSION 来存储 $_POST 数据，然后销毁重新填充用户的表单后。

现在我的问题是：$_SESSION 变量是否容易受到任何类型的攻击，或者我可以继续将原始输入数据存储在 $_SESSION 中，并在重新填充表单时使用 htmlspecialchars() 对其进行转义？

【问题讨论】：

您可以随时使用mysqli_real_escape_string() 进行一些基本的清理
值得注意的是，$_SESSION 变量通常保存在磁盘上，当然容易受到错误设置权限的影响。因此，最好不要记住密码等任何敏感信息。不要直接使用$_SESSION["foo"] = $_POST;，因为您可能会从恶意用户那里获得任意巨大的会话文件/变量。
@Anonymous.X 在将它们存储在数据库中之前，无需这样做。将该功能用于其他任何事情都超出了其预期目的。
@KevinMark，我实际上的意思是我只会存储 $_POST 数据的某些元素，不愿意使用$_SESSION['foo'] = $_POST;，正如你所说，我不想在其中保存任何敏感信息会议。
@Anonymous.X 清理数据始终是一种好习惯，但mysqli_real_escape_string() 只是清理将直接添加到 MySQL 查询的数据的正确方法。使用该功能对包括 HTML 在内的任何其他内容进行清理是不正确的。

标签： php session user-experience

【解决方案1】：

会话中的变量不易受到会话中的攻击。但是，在其他地方使用这些变量可能会打开漏洞。例如，仅仅因为您在会话中放置了一个 get/post 变量并不意味着它可以神奇地直接在查询中使用。它仍然可能导致 SQL 注入问题。在考虑这样的事情时，您必须考虑数据的来源。如果它从某种用户输入开始，则认为它很脏。

这可能是一个问题的唯一地方是如果发送的数据非常大并且您只是盲目地分配$_SESSION['POST'] = $_POST;。溢出或类似的东西不应该有问题。问题将更多的是 php 必须在请求开始时反序列化数据并在结束时重新序列化（通常仅在发生更改时）。这种反序列化/序列化需要时间（它可能很快，但仍然如此）。我建议只分配您要保存的值。

【讨论】：

我在将数据存储到会话之前对其进行过滤，因为我不想在表单提交时使用不会通过验证的数据重新填充列表。此外，我正在使用准备好的语句，并且我知道如何保护我的数据库，这只是我在问题中所说的 UX 的一点补充。在分配时，我只会分配某些 $_POST 数据值，而不是整个 $_POST 数组。
那么，只要您在将其吐回输入元素时执行htmlentities($value, ENT_QUOTES) 之类的操作，就不会成为问题。不希望有人在输入中提交带有"><script...>" 之类的表单，并让回显输入最终像<input type="text" name="whatever" value=""><script...>">
@ShowTime 即使您只分配了 $_POST 的一部分，它仍然可能非常大。也许尝试限制任何特定变量的长度。请记住，$_POST 值也可以是 PHP 数组，如果用户以这种方式格式化输入。请参阅 php.ini max_input_vars、max_input_nesting_level 和 post_max_size 选项。
我只是在过滤它们并确保它们有效之后将它们存储在 $_SESSION 中，因此“坏”的东西不可能真正存储在会话中。，

【解决方案2】：

很难说清楚。但我大约 100% 确定答案是否定的，他们并不真的很脆弱。那是假设您几乎可以立即销毁会话。在这种情况下，您将创建会话，将用户重定向回旧页面，检查会话变量，将变量设置在正确的位置（在这种情况下您可以只使用纯文本），然后销毁会话。会话只会持续大约 10 秒.. 最多一分钟？并且没有人真的有足够的时间从服务器中提取。如果他们已经在收听流量，那么您会遇到更大的麻烦。

因为篇幅太长，不得不搬过去回答……

但是，您可以在用户提交之前使用 ajax 检查用户名。那会更好。如果电子邮件已经存在，则不允许他们提交。只需根据keyup 或其他内容提交即可。

【讨论】：

确实，AJAX 方法值得考虑，但我的目标也是改善不支持 JavaScript 的人的体验，这就是为什么我想要一个同时满足两类用户的替代方案：JS和非 JS 的。此外，一旦我重新填充列表，我将拥有会话 unset()。
在这种情况下，两者都做。您永远不应该因为用户不想要它而排除 Javascript 或其他库。是的，抓住那些这样做的人，但对那些得到支持的人有额外的安全感，因为他们会更加感激。（很可能不会那么混乱。）

【解决方案3】：

不，会话变量通过多种选项存储在服务器上，例如保存到磁盘、通过 redis 或 memcached 存储共享等等。

即使这些数据被泄露，我也看不出卫生设施如何保护任何东西或减轻此类攻击的负面影响。

如果你真的担心这样的事情，你可以在使用完临时会话变量后销毁它。

【讨论】：