Call Us: US - +1 845 478 5244 | UK - +44 20 7193 7850 | AUS - +61 2 8005 4826

SQL injection on loss

Avoiding SQL injection is simple. Developers need to either:

  1. Stop writing dynamic queries and/or
  2. Prevent user-supplied input, which contains malicious SQL that can affect the logic of the executed query

Below is the preferred way of writing a dynamic SQL query using “SqlCommand” parameters:

  public bool Login(string username, string password)
            SqlConnection dbConn = new SqlConnection(connectionString);
            SqlCommand cmd = dbConn.CreateCommand();
            cmd.CommandText = "SELECT UserId FROM UserDetails WHERE username = @username AND Password = @password";
            cmd.Parameters.Add(new SqlParameter("@username", SqlDbType.VarChar, 100)).Value = username;
            cmd.Parameters.Add(new SqlParameter("@password", SqlDbType.VarChar, 20)).Value = password;
            cmd.CommandType = CommandType.Text;
            return Convert.ToBoolean(cmd.ExecuteNonQuery());

One thing to keep in mind is that stored procedures are also prone to SQL injection if the SQL queries are executed as a string concatenated with user-supplied data.

More information on SQL injection can be obtained here.

Another critical type of injection is known as XPath Injection. XPath is a standard language used to query the parts of an XML document. Similar to SQL queries, the XPath queries are also prone to an injection attack when a user-supplied value is used to construct an XPath query. This vulnerability may result in enabling an attacker in achieving information disclosure or privilege escalation. Since most of the modern web services are exchanging data in an XML format, the XPath injection may impact your web service severely.

Consider the following XPath query, which validates the supplied user credentials against the values available in an XML document:

XPathExpression expr = navigator.Compile(“//users/user[@name='" + name + "' and @password='" + password + "']");

Similar to a SQL injection attack, an attacker may supply a username of “administrator” and a password value as “xyz’ or ‘a’=’a”. This input will cause a bypass to password check because the “where” condition will always evaluate to true. Fixing an XPath injection is not as easy as a SQL injection because XPath doesn’t support parameterized queries. Therefore, it becomes the programmer’s responsibility to sanitize the user-supplied values by implementing strict input validation or by not accepting values supplied by a user at all.

You can find more information on XPath injection here and here.

This concludes the first part of this multipart blog series on software vulnerability. In the next part, we will discuss cross-site scripting (XSS) attacks and cross-site request forgery (CSRF)