asp:DropDownList可以成为安全威胁吗?

时间:2012-12-11 16:09:57

标签: c# asp.net security drop-down-menu postback

这个问题与安全威胁有关。我想知道以下用法可以在客户端更改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

3 个答案:

答案 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查询参数而不是像您一样创建查询。