ASP.Net 控件是否通过视图状态公开 SQL 查询?
作为默认 ASP.Net 控件集一部分的控件是否始终使用 viewstate 或 controlstate?
即,如果我将下面的代码放到一个全新的 Web 表单上,我的 SQL 字符串是否会放置在未加密的控制状态中?
<asp:SqlDataSource ID="mobileData" runat="server"
DataSourceMode="DataReader"
SelectCommand="SELECT * from ma.bob WHERE Vendor IS NOT NULL"
/>
我知道如何加密视图状态和控制状态,但对我来说,这个常见用例可能如此不安全,这似乎很疯狂。肯定可以通过修改控制状态来执行 SQL 注入攻击吗?
我认为大多数人都会考虑对敏感应用程序的控制状态进行加密,但实际上,如果我的假设是正确的 - 那么它应该始终完成 - 并且 Visual Studio 应该默认启用它?
我的想法是否正确,还是我的想法有误?
Do controls, that are part of the default ASP.Net control set - ALL use viewstate or controlstate all the time?
i.e. If I drop the code below onto a brand new web form, is my SQL string placed in unencrypted controlstate?
<asp:SqlDataSource ID="mobileData" runat="server"
DataSourceMode="DataReader"
SelectCommand="SELECT * from ma.bob WHERE Vendor IS NOT NULL"
/>
I'm aware of how to encrypt viewstate and controlstate, but it seems crazy to me that this common use case could be so horrendously insecure. Surely one could perform a SQL injection attack by modifying the controlstate?
I think most people think of encrypting controlstate for sensitive applications, but actually, if my assumption is true - then it should always be done - and visual studio should enable it by default?
Am I thinking about this correctly, or do I have the wrong end of the stick?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
回答你的问题,不。
来自 MSDN
To answer your question, no.
From MSDN
此信息永远不会存储在 ViewState 中。
并非所有属性都是像这里的 SelectCommand 一样创建的
,由 PageParser 在生成的 C#/Vb 类中分配。该类将包含一些类似的行
,并且每次请求页面时都会进行此分配。 ASP .Net 不需要将其保留在 ViewState 中。
但是,如果你做这样的事情,
这将进入 ViewState (我所说的关于解析器的内容在这里也是正确的,但是 setter 在这里实现了 ViewState 机制)
This info is never stored in the ViewState.
Not all properties are created like this
SelectCommand here is assigned in a generated C#/Vb class by the PageParser. That class will contain some line like
and this assignment is made every time the page is requested. There is no need for ASP .Net to keep this in ViewState.
However if you do something like
This will go the ViewState (what I said about the parser is true here also, but the setter implements here that ViewState mechanism)