TableAdapter/DataSet 是否可以免受 SQL 注入攻击?
在我的 ASP.NET(3.5) 项目中,我使用内置的 TableAdapters/Dataset 进行所有数据访问。它是否提供与 SQLDataSource 在 SQL 注入中提供的相同的安全性?我使用的参数如下。
Dim myDAL As New ABCTableAdapters.XYZTableAdapter
Label1.Text = myDAL.getDatafromDB(myParameter)
更新 1:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim myParameter As String = getSafeURL(Request.QueryString("MS_Code")) 'getsafeurl encodes querystring using HttpUtility.UrlEncode
Dim myDAL As New ABCTableAdapters.XYZTableAdapter
Label1.Text = myDAL.getDatafromDB(myParameter)
End Sub
getDatafromDB 对应于 app_code/DAL.xsd 中存在的以下查询
SELECT sometable where fieldname = @parameter
更新 2: 如果我“查看 XSD 代码”,我可以看到以下内容
<SelectCommand>
<DbCommand CommandType="Text" ModifiedByUser="true">
<CommandText>SELECT pageContent FROM [content] where name = @name</CommandText>
<Parameters>
<Parameter AllowDbNull="true" AutogeneratedName="name" ColumnName="name" DataSourceName="iseac.dbo.[content]" DataTypeServer="nchar(100)" DbType="String" Direction="Input" ParameterName="@name" Precision="0" ProviderType="NChar" Scale="0" Size="100" SourceColumn="name" SourceColumnNullMapping="false" SourceVersion="Current" />
</Parameters>
</DbCommand>
</SelectCommand>
In my ASP.NET(3.5) project, I am using inbuilt TableAdapters/Dataset for all Data Access. Does it provide the same security as SQLDataSource does from SQL injection? I am using parameters as follows.
Dim myDAL As New ABCTableAdapters.XYZTableAdapter
Label1.Text = myDAL.getDatafromDB(myParameter)
Update 1:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim myParameter As String = getSafeURL(Request.QueryString("MS_Code")) 'getsafeurl encodes querystring using HttpUtility.UrlEncode
Dim myDAL As New ABCTableAdapters.XYZTableAdapter
Label1.Text = myDAL.getDatafromDB(myParameter)
End Sub
getDatafromDB corresponds to following query present in app_code/DAL.xsd
SELECT something FROM sometable where fieldname = @parameter
Update 2:
If I 'View Code' of XSD I am able to see following
<SelectCommand>
<DbCommand CommandType="Text" ModifiedByUser="true">
<CommandText>SELECT pageContent FROM [content] where name = @name</CommandText>
<Parameters>
<Parameter AllowDbNull="true" AutogeneratedName="name" ColumnName="name" DataSourceName="iseac.dbo.[content]" DataTypeServer="nchar(100)" DbType="String" Direction="Input" ParameterName="@name" Precision="0" ProviderType="NChar" Scale="0" Size="100" SourceColumn="name" SourceColumnNullMapping="false" SourceVersion="Current" />
</Parameters>
</DbCommand>
</SelectCommand>
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这取决于。
如果你错误地使用 tableAdapters,你可能会受到 SQL 注入。
最重要的是对从用户收集的所有数据使用 SqlParameters。
您能展示一些数据访问代码吗?
请参阅此处如何:防止 ASP.NET 中的 SQL 注入
这里重要的部分是用户输入的数据(来自网络请求的数据)被传递到数据库参数(如@au_id)内的数据库。在这种情况下,您就可以免受 SQL 注入的侵害。
不好的方法是这样的(不要使用这个):
这样用户可以操纵发送到数据库的内容,如果您与数据库的连接有足够的权限,它可以删除表或数据库。或者它可以默默地修改您的数据,这甚至更糟糕。
因此,始终使用数据库参数。
另外,如果你这样做,你会获得性能上的提升,因为数据库会缓存执行计划,如果你稍后使用不同的参数值执行相同的SQL,数据库已经有了执行计划,不需要再次解析sql。
It depends.
You could get SQL injection if you badly use tableAdapters.
The main thing is to use SqlParameters for all data that is gathered from users.
Can you show some of your data access code ?
Look up here How To: Protect From SQL Injection in ASP.NET
The important part here is that user entered data (what comes in from web request) is passed to DB inside database parameters like @au_id. In that case you are protected from SQL injection.
BAD WAY would be this (DON'T USE THIS):
This way user can manipulate what is send to DB and if your connection to DB has enough privileges it can drop tables or database. Or it can silently modify your data and that is even worse.
So, always use database parameters.
Additionally if you do you gain in performance, because DB will cache execution plan and if you later execute same SQL with only different values for parameters, DB already have execution plan and it doesn't need to parse sql again.