Question

This question is about security threat. I wonder at the below usage can DropDownList selected value changed at client side and affect the server side ?

Here the usage (aspx definition)

  <asp:DropDownList AutoPostBack="true" ID="dropDownListDrawingArtists" CssClass="DropDownArtists"
                runat="server">
  </asp:DropDownList>

server side filling

    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());
        }
    }

And the final usage at postback

    if (dropDownListDrawingArtists.SelectedIndex > 0)
    {
        srFilterByDrawingArtist = " and DrawingArtist='" + dropDownListDrawingArtists.SelectedItem.ToString() + "'";
        Session["FilterByArtist"] = dropDownListDrawingArtists.SelectedIndex.ToString();
    }

As you can see i am directly using it at the SQL query. I tested myself at google chrome. Changed the values of dropDownListDrawingArtists and done a postback. the value at the server side was not effected. Just to be sure

thanks for answers

asp.net 4.0 C# 4.0

Answer 1

Whether it is currently possible or not is irrelevant. You should still be using parameterized queries instead of contencating the stgrings.

The reasoning for this is the same as the reasoning that OWASP defines character escaping as “weak” compared to parameterized queries and parameterized stored procedures, and why white listing is better than blacklisting.

From the OWASP cheat sheet to Preventing SQL Injection:

This third technique is to escape user input before putting it in a
query. If you are concerned that rewriting your dynamic queries as
prepared statements or stored procedures might break your application
or adversely affect performance, then this might be the best approach
for you. However, this methodology is frail compared to using
parameterized queries (emphasis mine) and we cannot guarantee it will prevent all SQL
Injection in all situations. This technique should only be used, with
caution, to retrofit legacy code in a cost effective way. Applications
built from scratch, or applications requiring low risk tolerance
should be built or re-written using parameterized queries.

The reason it’s frail is that someone is always working on a new way to exploit any potential hole. What works to prevent tampering today may be circumvented tomorrow.

---

That said, currently, the ViewState protection offers protection for this. If someone tampers with the list, they will generally get an automatically generated “Invalid Viewstate” error, and the code wont’ process.

http://msdn.microsoft.com/en-us/magazine/ff797918.aspx

But don’t rely on that behavior. It can be turned off, and I’ve seen a Jr. Developer turn it off to try to resolve errors. (Thank goodness for code reviews.)