在表单提交之间传递 base64_encoded 序列化数据
我正在创建一系列基于向导的表单来接受用户输入。该向导的要求之一是，在用户单击“保存”按钮之前，脚本（PHP）无法将输入保存到数据库（MySQL）中，因此我必须设计一种机制将用户输入以一种形式传输到另一种形式当用户单击“上一个”或“下一个”按钮时。我研究了使用各种方法，包括 cookie、会话、临时文件等，但我决定将 base64_encoded 序列化数据嵌入到存在于该系列所有表单中的隐藏字段中。该字段中的值将在表单提交时进行解码，并在插入当前表单中的其他值后重新编码以放入下一个表单中。
以下是隐藏字段外观的示例：
<input type="hidden" name="wizard:presave" value="YTo2OntzOjU6InRpdGxlIjtzOjEwOiJRdWVzdGlvbiAyIjtzOjQ6InRleHQiO3M6MTk6IlllcyBpdCdzIGEgcXVlc3Rpb24iO3M6NDoidHlwZSI7czo2OiJjaG9pY2UiO3M6NzoiY2hvaWNlcyI7YTowOnt9czo1OiJwb2ludCI7aToxO3M6Mjoib3AiO3M6MTM6ImVkaXRfZXhlcmNpc2UiO30=" />
所以问题是：
这被认为是好的/坏的做法吗？
HTMLform 中的隐藏字段有长度限制吗？
可能存在哪些安全问题？
还有更好的选择吗？ （有解释，最好不使用 javascript）
提前致谢！
I'm creating a wizard-based series of forms for taking user inputs. One of the requirements for that wizard is that the script (PHP) cannot save the inputs into the database (MySQL) until the user clicks the 'Save' button, so I have to device a mechanism to transport user inputs in one form to another when the user clicks 'Previous' or 'Next' buttons. I looked into using various methods including cookies, sessions, temporary files etc, but I settled for embedding base64_encoded serialize data in a hidden field that exists in all the forms in the series. The value in this field will be decoded on form submissions and re-encoded for putting in the next form after other values from the current form are inserted.
Here is a sample of how the hidden field looks:
<input type="hidden" name="wizard:presave" value="YTo2OntzOjU6InRpdGxlIjtzOjEwOiJRdWVzdGlvbiAyIjtzOjQ6InRleHQiO3M6MTk6IlllcyBpdCdzIGEgcXVlc3Rpb24iO3M6NDoidHlwZSI7czo2OiJjaG9pY2UiO3M6NzoiY2hvaWNlcyI7YTowOnt9czo1OiJwb2ludCI7aToxO3M6Mjoib3AiO3M6MTM6ImVkaXRfZXhlcmNpc2UiO30=" />
So the questions are:
Is it considered a good/bad practice?
Is there any length limit of hidden fields in HTMLform?
What are the possible security issues?
And are there better alternatives? (with explanations, preferably without using javascript)
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我在职业生涯中从未见过这种特殊的参数传递方法，所以我不能说它是好是坏。这当然不是“标准”。标准方法要么使用隐藏输入传递提交的方法（未编码/正常），要么存储在会话中。我认为你可能是在为自己工作，所以从这个意义上说它会倾向于“不理想”。
只要您对表单使用 POST，据我所知，HTTP 规范中就没有定义数据大小的限制。较旧的服务器可能有实际限制，但除非您正在执行一些极端的操作（例如媒体文件上传），否则不必担心。
可能的安全问题是常见的网络安全缺陷。您从用户处获取并重新输出到页面的任何内容都可能包含跨站点脚本漏洞，并且必须进行适当的清理（如果您对所有内容进行编码，则这有点没有实际意义）。用户可以制作自己的数据并根据需要提交。基本上，假设您处理的所有数据都不安全且受到污染。
会话在这里会工作得更好。用户提交的数据不必经过冗长的编码过程。同样，您只需验证一次。提交并验证后，您只需将其存储在服务器上的 $_SESSION 中，然后将其保留，直到单击最后一个按钮。否则，您必须担心在每一步中重新输出它、重新接收它并重新验证它。恶意用户可以提交一组数据，对其进行检查并重新输出为编码数据，然后通过取消编码、更改数据和重新编码来制作下一个表单提交。
我强烈建议您重新考虑会话，因为它将所有数据操作简化为“一次”场景。
I've never seen this particular method of parameter passing in my career, so I can't say whether it's good or bad. It's certainly not "standard". Standard methods would either be passing the submitted method along (unencoded/normally) using hidden inputs, or storing in session. I think you might be making work for yourself, so in that sense it would lean towards "not ideal".
As long as you are using POST for your forms, there is no defined limit for data sizes that I'm aware of in the HTTP specifications. Older servers may have practical limits, but unless you're doing something extreme such as media file uploads, they shouldn't be a worry.
Possible security issues are the normal web security flaws. Anything you take from a user and re-output to a page could contain cross-site scripting vulnerabilities and would have to be properly sanitized (this is somewhat moot if you're encoding everything). Users can craft their own data and submit it if they like. Basically, assume all the data you handle is unsafe and tainted.
Sessions would work much better here. The data the user submits wouldn't have to go through a lengthy encoding process. As well, you'd only have to validate it once. After it's been submitted and validated, you can simply store it on the server in $_SESSION and leave it alone until the final button is clicked. Otherwise, you have to worry about re-outputting it, re-receiving it, and re-validating it at each step. A malicious user could submit one set of data, have it checked and re-output as encoded data, but then craft the next form submission by unencoding, changing data, and re-encoding.
I would highly recommend that you reconsider sessions, as it simplifies all your data operations into a "do-once" scenario.
取决于目的。到目前为止，我只见过客户端 URL 哈希这样的构造，用于记住基于 ajax 的大型应用程序中的选择状态（以便它们可添加书签），然后通常还进行 Gzipped 以使其更短。在您的具体情况下，我会说：利用 HTTP 会话，并仅在隐藏字段中传递基于请求的标识符（也称为令牌），以便您可以从会话中获取关联信息。
在 GET 中，完整的查询字符串（所有参数名称、值和分隔符一起）通常限制为 2048 个字符，但您可以更好地遵守 256 个字符的官方限制。在 POST 中，它取决于服务器配置。通常默认值约为 2GB。
嗯，它显然是可以解码的。
您可以对其进行 Gzip 压缩以使其更短且不那么明显。或者，如前所述，将会话与基于请求的标识符结合使用。
Depends on the purpose. As far I've only seen such constructs as a client side URL hash to remember the state of the selections in large ajax-based applications (so that they are bookmarkable) and then often also Gzipped to make it shorter. In your speficic case I'd say: make use of the HTTP session and only pass a request based identifier (also called token) in the hidden field so that you can get the associated information from the session.
In GET the complete query string (all parameter names and values and separators together) is usually limited to 2048 characters, but you can better adhere an officious limit of 256 chars. In POST it is dependent on server configuration. Often this defaults around 2GB.
Well, it is obviously decode-able.
You could Gzip it to make it shorter and less obvious. Or, as already said, make use of the session in combination with a request based identifier.
那么，您可以通过序列化将其存储到会话中，或者只是按照每个步骤的方式存储它。当用户单击“保存”时，您将获取并验证会话中所有步骤的数据。
Well, you can store into the session either by serializing or just simply store it the way it is for each step. When the user clicks Save, you grab and validate the data from all the steps in the session.
tsk tsk :)
这被认为是好的/坏的做法吗？
主观上 - 不好的做法..您使用了错误的锤子来完成这项工作。
HTMLform 中的隐藏字段有长度限制吗？ - 不确定是否有限制。
可能存在哪些安全问题？ - 可能有很多，但您可以清理每个请求收到的数据。此外，数据很容易解码，并且可以在客户端轻松修改（我可以看到您正在使用它的某种 json :) ）
还有更好的替代方案吗？ （带有解释，最好不使用javascript） - 使用正确的工具..会话也许？
是的...您很可能会面临性能和可扩展性问题（如果您有大量用户负载），因为每个请求都需要运行所有清理、解析、格式化和安全代码。
tsk tsk :)
Is it considered a good/bad practice?
subjectively - bad practice..you're using the wrong hammer for the job.
Is there any length limit of hidden fields in HTMLform? - Not sure if there is a limit.
What are the possible security issues? - Possibly, quite a few, but you can sanitize the data received for every request. Besides, the data is pretty easy to decode and can be easily modified on the client side (I can see that its some sort of json that you are using :) )
And are there better alternatives? (with explanations, preferably without using javascript) - Use the right tool .. sessions perhaps?
And yes... You are most likely going to face performance and scalability issues (should you have a substantial user load) with all that sanitizing, parsing, formatting and security code running for every request.