QueryString 的最佳替代方案是什么
我们听说了很多有关使用 QueryStrings 的漏洞和可能的攻击的信息。 除此之外，昨天，一个错误让我非常恼火，以至于我决定停止使用 QueryStrings，我传递了类似的内容：
Dim url As String = "pageName.aspx?type=3&st=34&am=87&m=9"
我尝试
Response.Write(url)
在重定向页面中，它打印“类型”为 3，然后我在目标页，它打印了 3,0...我知道这很容易处理，但为什么呢？ 我的意思是为什么我应该通过 3 并且必须在下一页的加载中检查 3.0 才能采取相应的操作？？？
那么我们应该使用什么呢？ 将变量、参数等传递到下一页的最安全方法是什么？
We heard a lot about the vulnerabilities of using QueryStrings and the possible attacks.
Aside from that, yesterday, an error irritated me so much that i just decide to stop using QueryStrings, i was passing something like:
Dim url As String = "pageName.aspx?type=3&st=34&am=87&m=9"
I tried to
Response.Write(url)
in the redirecting page, it printed the "type" as 3, then i tried it in the target page, it printed 3,0....i know this can be easily dealt with, but why? i mean why should i pass 3 and have to check for 3.0 in the next page's load to take my action accordingly???
So what should we use? what is the safest way to pass variables, parameters...etc to the next page?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您可以使用跨页面回发。
另请查看这篇文章：
You could use Cross-Page Postbacks.
Check also this article:
您可以使用许多选项，其中大多数需要您构建一个在页面之间传递变量的策略。
在大多数项目中，我使用此策略，我创建一个 formVariables 类来保存当前活动的项目。 它具有您需要通过查询字符串传递的属性。 我将这门课存储在会话中。 在我的基本页面中，我从会话中读取了它。 所以在每个页面中我都会获得该对象的值。 这种方法唯一的缺点是当你完成工作后要清理物品..
希望这会有所帮助。
There are many options you can use, most of them requires you to build a strategy to pass variables between pages.
In most projects I use this strategy, I create a formVariables class to hold currently active items. it has properties which you will need to pass by querystring. and I store this class at session. and in my base page I read it from session. so in every page I get values over this object. the only negative thing about this method is to clean up items when you finished your work on it..
hope this helps.
我建议您避免使用 Session 在页面之间传递变量，因为这会破坏网络的无状态模型。
如果您刚刚在会话中存储了与某个页面相关的一些值，那么用户使用浏览器的后退按钮返回到同一页面，该页面应该具有不同的状态，那么您将不会知道它。
它导致读取与用户当前正在查看的页面不相关的会话值的可能性 - 这可能会让最终用户感到非常困惑。
如果您过于依赖它，您还会遇到会话过期的问题。
我个人尽量避免使用会话，而优先选择隐藏表单值+可以在回发+导航上读取的查询字符串。
I would sugest you avoid using Session to pass variables between pages as this breaks the stateless model of the web.
if you have just stored some values in session that relate to a certain page then the user uses their browsers back button to go back to the same page whcih should have a different state then you are not going to know about it.
It leads to the possibility of reading session values that are not relevant to the page the user is currently viewing - Which is potentially very confusing for the end user.
You will also run into issues with session expiration if you rely on it too much.
I personally try to avoid using session where possible in preference of hidden form values + query strings that can be read on postback + navigation.
在页面之间传递信息的最佳/最安全的方法是使用会话。
您可以在会话中存储任何类型的对象，并且它存储在服务器端，因此用户无法像查询字符串、视图状态或隐藏字段那样操作它
The best / most secure way to pass info between pages is to use the session.
You can store any kind of object in the session and it is stored on the server side, so the user can't manipulate it like a query string, viewstate, or hidden field
你说：
“3,0”（三个逗号哦）和“3.0”（三个点哦）之间有区别。 您还说您正在“传递类似的东西”。
在查询字符串中，如果您在同一键中传递多个值，它们将用逗号分隔。
由于所有值都作为字符串传递，因此 int“3”不可能神奇地变成十进制“3.0”，除非您在请求时对其进行解析。
我会回去仔细检查您传递到 URL 的内容，如果它最终结果如下：
然后当您回读时，
您将得到“3,0”，作为该键中逗号分隔的值列表。
You said:
There's a difference between "3,0" (three comma oh) and "3.0" (three point oh). You also said that you were "passing something like".
In a query string, if you pass multiple values in the same key, they will be seperated with commas.
As all values are passed as strings there's no way that an int "3" is going to magically become decimal "3.0" unless you parse it as such when you request it.
I'd go back and double check what you are passing into your URL, if it ends up as something like:
Then when you read back
You'll get "3,0" back as the comma seperated list of values in that key.
首先，在 asp .net 中，您可以使用多种策略在页面之间传递值。 你也有viewstate，但是viewstate存储值并且使用在不同的场景中，你也可以使用它。 而是以会议形式进行，当然是以邮寄的形式。
如果您的问题是安全性，我建议您创建 2 个用户来访问数据。 一名具有只读访问权限的用户，用于访问页面（Sql Inyection 阻止）并验证数据抛出查询字符串。 以及一个对您的私人区域具有写入权限的人。
抱歉，我的英语难以阅读。
First, in asp .net you can use several strategys to pass values between pages. You have viewstate too, however the viewstate store the value and the use is in different scenarios , you can use it too. Sessions instead, and of course by post in a form.
If your problem is the security, I recommended you to create 2 users for accesing the data. One user with read only access, this for accessing the pages ( Sql Inyection prevent ) and validate the data throw the querystring. And One with write access for your private zone.
Sorry, for my unreadeable English.
我喜欢使用查询字符串，因为我希望用户能够为常见搜索等内容添加书签。 例如，如果一个页面可以独立工作，那么我希望它能够独立工作。
如果您需要从另一个页面进入您所在的页面才有意义，那么使用会话/跨页面回发很酷，但除此之外，我通常发现查询字符串是更好的解决方案。
请记住，查询字符串是未经验证的输入，并谨慎对待它们，就像对待任何未经验证的输入一样。
I like to use query string as I like users to be able to bookmark things like common searches and the like. E.g. if a page can work stand-alone then I like to it to be able to work stand-alone.
Using session/cross-page postbacks is cool if you needed to come from another page for the page you're on to make sense, but otherwise I generally find querystrings to be the better solution.
Just remember that query strings are unvalidated input and treat them with the caution you would treat any unvalidated input.
如果您对每个页面加载进行适当的安全检查，那么查询字符串就很好并且最灵活。
它们提供了最大的灵活性，因为页面的入口点并不像其他选项那样依赖于发送者。 您可以从自己的应用程序内的任何位置调用页面，或者根据需要通过查询字符串从外部调用页面。 它们还可以添加书签并手动修改以进行测试或直接操作。
同样，关键是向查询字符串添加适当的安全性和验证，而不是盲目地处理它。 请记住，安全性不仅仅具有编辑或读取访问权限，具体取决于数据和用户，在数据归特定用户所有且私有的情况下，他们可能根本无权访问这些数据。
我们尝试了各种方法，试图隐藏查询字符串，但最终还是回到了它，因为它更容易执行、调试和管理。
If you do proper security checks on each page load then the querystring is fine and most flexible IMHO.
They provide the most flexibility as the entry poitn to a page is not dependant on the sender as in some other options. You can call a page from any point within your own app or externally if needed via querystrings. They can also be bookmarked and manually modified for testing or direct manipulation.
Again the key is adding proper security and validation to the querystring, and not processing it blindly. Keep in mind that the seucirty goes beyond having edit or read access, depending on the data and user, they may not have access to the data with thos paranters at all, in cases where data is owned and private to specific users.
We have tried various methods, in an attempt to hide the querystring but in the end have gone back to it, as it is easier to do, debug, and manage.