Si mal no recuerdo, creo que Jeff ha mencionado en el podcast Stack Overflow una posible debilidad en las declaraciones SQL preparadas. Me pregunto a qué tipo (s) de debilidad (s) se refirió? ¿Fue posiblemente inappropriate usage o algo más siniestro?¿Inyecciones SQL con declaraciones preparadas?
El podcast, que yo recuerde, no profundizó en el tema, fue solo un comentario de pasada.
No he escuchado el podcast, pero en mi experiencia solo lo bueno proviene de declaraciones preparadas. A menudo mejora el rendimiento de la aplicación y evita la inyección de SQL (si se utiliza correctamente, no como el segundo ejemplo en su enlace).
Si la declaración que se prepara tiene los parámetros construidos dinámicamente de alguna manera, entonces es más que probable que sea la fuente de la debilidad.
Si usa una biblioteca de bases de datos adecuada con clases probadas para establecer parámetros, entonces no se abre a una inyección SQL en ningún momento, declaración preparada o no.
Recuerde, solo porque una declaración está preparada o porque está utilizando un procedimiento almacenado, no significa que esté a salvo de ataques de inyección. Solo cuando utiliza un código de proveedor de base de datos que desinfectará la entrada de parámetros (además de aplicarlo a todos los parámetros que pueden usarse) obtendrá protección contra la inyección de SQL.
Más allá de la inyección sql normal (lo que podríamos llamar de primer orden) ataque hay niveles secundarios. Por ejemplo, no es raro que los procedimientos almacenados utilicen la concatenación de cadenas para generar una consulta que luego se ejecuta. Si el resultado de los valores de campo recuperados se incluye en dicha concatenación, entonces existe el peligro de inyección.
Creo que lo que dijo fue que, cuando utilizaba Declaraciones preparadas, el servidor SQL podía almacenar en caché el plan de ejecución de consultas, por lo que incluso si modificaba algunos de los parámetros en la consulta en ejecución, el servidor podía elegir el incorrecto (probablemente en caché) plan de ejecución que funcionaría muy mal.
También mencionó una nueva característica de SQL Server 2008 para obligar al motor a reevaluar los planes de ejecución que usó para superar esta situación.
Con declaraciones preparadas, el único problema que tengo es esto. Considere el siguiente código de Java:
String sql = "select * from table where name like ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, "PATTERN%");
ResultSet rs = pstmt.executeQuery();
Aquí se puede esperar que, si usted tiene un índice en la tabla (nombre) que será utilizada por el plan de consulta. Bueno, no lo hará. Porque PraparedStatement debe precompilar y esperar lo peor: '% PATTERN%', por ejemplo. Por lo tanto, no se optimizará. Me llevó un tiempo descubrirlo. Estaba causando que mi base de datos sufriera. :(
Espero que ayude.