¿Pueden mis usuarios inyectar mi sql dinámico?

Question

Soy un desarrollador de escritorio a escribir para los usuarios internos, así que no estoy preocupado por los hackers, pero me gustaría saber si hay algo que pudieran entrar al actualizar un valor que pudiera ejecutar SQL en el servidor.

El negocio define su esquema de contenido y tengo una aplicación CRUD para ellos que no tiene que cambiarse cuando cambia su esquema porque los detalles de validación son basados ​​en tablas y las actualizaciones son con SQL dinámico. Tengo que admitir comillas simples en su entrada de datos, así que cuando las ingresan, las doblo antes de que se ejecute SQL en el servidor. Por lo que he leído, sin embargo, esto no debería ser suficiente para detener una inyección.

Así que mi pregunta es, ¿qué texto podrían entran en un campo de texto de forma libre que podría cambiar algo en el servidor en lugar de ser almacenados como un valor literal?

Básicamente, estoy construyendo una instrucción SQL en tiempo de ejecución que sigue el patrón:

actualización de campo de tabla del set = valor donde pkField = pkVal

con este código VB.NET:

Friend Function updateVal(ByVal newVal As String) As Integer 
    Dim params As Collection 
    Dim SQL As String 
    Dim ret As Integer 

    SQL = _updateSQL(newVal) 
    params = New Collection 
    params.Add(SQLClientAccess.instance.sqlParam("@SQL", DbType.String, 0, SQL)) 
    Try 
     ret = SQLClientAccess.instance.execSP("usp_execSQL", params) 
    Catch ex As Exception 
     Throw New Exception(ex.Message) 
    End Try 
    Return ret 
End Function 

Private Function _updateSQL(ByVal newVal As String) As String 
    Dim SQL As String 
    Dim useDelimiter As Boolean = (_formatType = DisplaySet.formatTypes.text) 
    Dim position As Integer = InStr(newVal, "'") 
    Do Until position = 0 
     newVal = Left(newVal, position) + Mid(newVal, position)  ' double embedded single quotes ' 
     position = InStr(position + 2, newVal, "'") 
    Loop 
    If _formatType = DisplaySet.formatTypes.memo Then 
     SQL = "declare @ptrval binary(16)" 
     SQL = SQL & " select @ptrval = textptr(" & _fieldName & ")" 
     SQL = SQL & " from " & _updateTableName & _PKWhereClauses 
     SQL = SQL & " updatetext " & _updateTableName & "." & _fieldName & " @ptrval 0 null '" & newVal & "'" 
    Else 
     SQL = "Update " & _updateTableName & " set " & _fieldName & " = " 
     If useDelimiter Then 
      SQL = SQL & "'" 
     End If 
     SQL = SQL & newVal 
     If useDelimiter Then 
      SQL = SQL & "'" 
     End If 
     SQL = SQL & _PKWhereClauses 
    End If 
    Return SQL 
End Function 

cuando actualice un campo de texto con el valor

Redmond '; drop table OrdersTable--

que genera:

Update caseFile set notes = 'Redmond''; drop table OrdersTable--' where guardianshipID = '001168-3' 

y actualiza el valor al valor literal que entraron.

Qué otra cosa podían entrar en ese inyectaría SQL?

Una vez más, no estoy preocupado de que alguien quiere piratear el servidor en su trabajo, pero me gustaría saber cómo si accidentalmente podrían pegar texto desde otro lugar y romper algo.

Gracias.

Answer 1

Asumiendo que escapar de las cadenas literales (que a partir de lo que ha dicho que está haciendo), usted debe ser seguro. La única otra cosa en la que puedo pensar es si usa un juego de caracteres basado en Unicode para comunicarse con la base de datos, asegúrese de que las cadenas que envía son válidas en esa codificación.

Answer 2

Tan feo como su código de duplicación es (: p - Pruebe String.Replace en su lugar.) Estoy bastante seguro de que hará el trabajo.

Answer 3

La única segura supuesto es que si usted no está utilizando consultas con parámetros (y no estás, exclusivamente, aquí, ya que está concatenando la cadena de entrada en su SQL), entonces usted no está seguro .

Answer 4

Independientemente de cómo limpiar la entrada del usuario aumentando la superficie de ataque es el problema real con lo que está haciendo. Si mira hacia atrás en el historial de la inyección de SQL, notará que nuevas y aún más creativas formas de causar estragos a través de ellas han surgido con el tiempo. Si bien es posible que haya evitado lo conocido, siempre es lo que está al acecho a la vuelta de la esquina lo que hace que este tipo de código sea difícil de producir. Sería mejor simplemente usar un enfoque diferente.

Answer 5

Nunca jamás querrá construir una declaración de SQL usando la entrada del usuario que luego se ejecutará directamente. Esto lleva a ataques de inyección SQL, como has encontrado. Sería trivial para alguien dejar caer una tabla en su base de datos, como usted ha descrito.

Desea utilizar las consultas parametrizadas, donde crea una cadena SQL usando marcadores de posición para los valores, luego pasa los valores para esos parámetros.

utiliza VB que haría algo como:

'Define our sql query' 
Dim sSQL As String = "SELECT FirstName, LastName, Title " & _ 
        "FROM Employees " & _ 
        "WHERE ((EmployeeID > ? AND HireDate > ?) AND Country = ?)" 

'Populate Command Object' 
Dim oCmd As New OledbCommand(sSQL, oCnn) 

'Add up the parameter, associated it with its value' 
oCmd.Parameters.Add("EmployeeID", sEmpId) 
oCmd.Parameters.Add("HireDate", sHireDate) 
oCmd.Parameters.Add("Country", sCountry) 

(ejemplo tomado de here) (tampoco no soy un programador de VB por lo que esto podría no ser la sintaxis correcta, pero se vuelve el punto a través)

Answer 6

También puede evaluar una solución alternativa. Generación dinámica de SQL con parámetros. Algo como esto:

// snippet just for get the idea 
var parameters = new Dictionary<string, object>(); 
GetParametersFromUI(parameters); 


if (parameters.ContainsKey("@id")) { 
    whereBuilder.Append(" AND id = @id"); 
    cmd.Parameters.AddWithValue("@id", parameters["@id"]); 
} 
...