这些隐藏字段的使用不安全吗？
我正在增强一个遗留系统（我没有帮助构建），并且想从其他人那里了解我注意到的某些事情是否是合法的安全问题。
首先，应用程序通过登录来保护安全。然而，一旦用户登录，整个应用程序中有 11 个页面，其中隐藏字段存储文件名值以及下载路径。
JavaScript 用于自动提交表单，然后用户下载文件并将其保存到他或她的计算机上。我认为这个值可能会被更改，并且用户会在不知不觉中下载恶意文件。
此外，有许多页面将引用页面保存在隐藏字段中，以便用户在保存表单时可以返回到上一页。如果这些都是合法问题，那又如何呢？如果可能的话，他们将如何受到攻击？风险或潜在影响的级别是多少？我问这个问题的原因是我可以提出需要修复该应用程序的情况（如果是这样）。仅仅说“这不是最佳实践”并不是一个足够好的理由。
感谢您的反馈！
I'm enhancing a legacy system (which I didn't help to build) and would like to find out from other people if some things that I've noticed are legitimate security issues or not.
First of all, the application is secured via a login. However, once a user is logged in, throughout the application there are 11 pages in which a hidden field stores the value of a file name as well as the path to download.
Javascript is used to automatically submit the form and the user then downloads and saves the file to his or her computer. I'm thinking that this value could be changed and the user would unknowingly download a malicious file.
Also, there's numerous pages that have the referring page saved in a hidden field so that the user can return to the previous page when a form is saved. If these are legitimate issues, how so? How would they be attacked, if that were possible? What's the level of risk or potential impact? The reason I ask is so that I can put forward the case that the application would need to be fixed, if so. Just saying that "this isn't a best practice" is just not a good enough reason.
Thanks for your feedback!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
很可能缺乏安全感。隐藏表单字段是一种实现细节。
具体来说，您不能依赖回传到服务器的表单字段的值与原始 HTML 呈现它的值相同。
如果服务器实施了对策，例如输入、校验和的清理，散列、加密等，使用起来可能会更安全一些。例如，ASP.NET 使用 ViewState 来实现这一点。
也就是说……
想看看它有多不安全吗？使用 Chrome 或 Firefox 开发人员工具将隐藏字段的输入类型属性之一从“隐藏”更改为“文本”，然后观察文本字段的显示（您可以在其中更改它并提交您喜欢的任何值）。
我还强烈建议阅读马特在回答中关于潜在风险分析的观点。
Very likely insecure. Hidden form fields are an implementation nicety.
Specifically, you cannot rely on the value of a form field being posted back to the server with the same value that the original HTML rendered it with.
If the server implements countermeasures such as sanitization of inputs, checksums, hashing, encryption, etc., the usage may be somewhat more secure. ASP.NET does this with ViewState, for instance.
That said...
Want to see how insecure it is? Change one of the hidden field's input type attribute from "hidden" to "text" using Chrome or Firefox developer tools, and watch the text field appear (where you can change it and submit whatever value you like).
I'd also highly recommend reading Matt's points on potential risk analysis in his answer.
隐藏字段只是一个 GUI 问题 - 您在屏幕上看不到它们，但它们仍然存在。这使得它们与任何其他（可见）领域一样脆弱。这就是为什么它们不被认为是“最佳实践”的原因。
Hidden fields are just a GUI issue - you don't see them on the screen, but they are still there. This makes them just as vunerable as any other (visible) field. THAT is why they aren't considered "best practice".
除了 Chris Shain 所说的之外：
风险或潜在影响的程度如何？
根据服务器端脚本所做的假设，影响可能非常严重。例如，如果隐藏字段包含
user_id或username并且假定该信息是合法的，那么任何人都可以代表其他人执行操作，只需更改正如 Chris Shain 所解释的那样，表单字段。In addition to what Chris Shain has said:
What's the level of risk or potential impact?
Depending on the assumptions made by the server-side script the implications could be pretty serious. If the hidden field contained, say, a
user_idorusernameand it was assumed that this information was legitimate then anyone could perform actions on behalf of anyone else, just by altering the form fields as Chris Shain explained.