这个问题与安全威胁有关。我想知道以下用法可以在客户端更改DropDownList选择值并影响服务器端吗?
这里的用法(aspx定义)
<asp:DropDownList AutoPostBack="true" ID="dropDownListDrawingArtists" CssClass="DropDownArtists"
runat="server">
</asp:DropDownList>
服务器端填写
if (IsPostBack == false)
{
if (srLang == "tr")
{
dropDownListDrawingArtists.Items.Add("Çizen Artist Filtresi: Bütün Çizen Artistler");
}
else
{
dropDownListDrawingArtists.Items.Add("Drawing Artist Filter: All Drawing Artists");
}
DataSet dsDrawingArtists = DbConnection.db_Select_Query("select DrawingArtist,COUNT(PokemonId) as Pokecount from tblPokedex group by DrawingArtist order by Pokecount desc,DrawingArtist asc");
for (int i = 0; i < dsDrawingArtists.Tables[0].Rows.Count; i++)
{
dropDownListDrawingArtists.Items.Add(dsDrawingArtists.Tables[0].Rows[i]["DrawingArtist"].ToString());
}
if (Session["FilterByArtist"] != null)
{
dropDownListDrawingArtists.SelectedIndex = Convert.ToInt32(Session["FilterByArtist"].ToString());
}
}
回发的最终用法
if (dropDownListDrawingArtists.SelectedIndex > 0)
{
srFilterByDrawingArtist = " and DrawingArtist='" + dropDownListDrawingArtists.SelectedItem.ToString() + "'";
Session["FilterByArtist"] = dropDownListDrawingArtists.SelectedIndex.ToString();
}
正如您所看到的,我在SQL查询中直接使用它。我在google chrome上测试了自己。更改了dropDownListDrawingArtists的值并完成了回发。服务器端的值没有受到影响。只是为了确定
感谢答案
asp.net 4.0 C#4.0
答案 0 :(得分:2)
目前是否可能是无关紧要的。您仍然应该使用parameterized queries而不是使用stgrings。
对此的推理与OWASP将字符转义定义为&#34; weak&#34;的原因相同。与参数化查询和参数化存储过程相比较,以及为什么white listing is better than blacklisting。
来自OWASP cheat sheet to Preventing SQL Injection:
第三种技术是在将用户输入放入之前将其转义 查询。如果您担心将动态查询重写为 准备好的语句或存储过程可能会破坏您的应用 或者对性能产生不利影响,那么这可能是最好的方法 为了你。 然而,与使用相比,这种方法很脆弱 参数化查询(强调我的)我们无法保证它会阻止所有SQL 在所有情况下注射。这种技术只能用于 谨慎,以经济有效的方式改进遗留代码。应用 从头开始构建,或需要低风险容忍度的应用程序 应使用参数化查询构建或重写。
原因 它的体弱是有人总是在开发一种新方法来利用任何潜在的漏洞。今天有效防止篡改的行为可能会在明天被规避。
也就是说,目前,ViewState保护为此提供了保护。如果有人篡改了列表,他们通常会自动生成&#34;无效的查看状态&#34;错误,代码不会&#39;过程
http://msdn.microsoft.com/en-us/magazine/ff797918.aspx
但不要依赖这种行为。它可以关闭,我已经看到Jr. Developer将其关闭以尝试解决错误。 (感谢您好好进行代码审查。)
答案 1 :(得分:1)
从它的外观来看,你对SQL注入攻击非常开放。永远不应该使用字符串连接来与数据库通信。您如何知道用户没有使用程序与您的站点/应用程序进行通信?可以有各种各样的操作。
如果你打开门,各种各样的东西都会通过它。
答案 2 :(得分:0)
是的,任何时候你接受任何类型的用户输入并将其直接修补到SQL查询中,都存在风险。
首先,您应该验证所有需要采用特定格式或多个已知值的输入。
其次,使用SQL查询参数而不是像您一样创建查询。