Java: cadena de escape para evitar la inyección de SQL
Estoy intentando implementar alguna inyección anti sql en Java y me resulta muy difícil trabajar con la función de cadena "replaceAll". En última instancia, necesito una función que convierta cualquier \to existente \\, any "to \", any 'to \'y any \nto \\npara que cuando MySQL evalúe la cadena, las inyecciones SQL se bloqueen.
Subí un código con el que estaba trabajando y todo lo que hay \\\\\\\\\\\en la función me está volviendo loco. Si alguien tiene un ejemplo de esto se lo agradecería mucho.
Las declaraciones preparadas son el camino a seguir, porque hacen imposible la inyección SQL. Aquí hay un ejemplo simple que toma la entrada del usuario como parámetros:
public insertUser(String name, String email) {
Connection conn = null;
PreparedStatement stmt = null;
try {
conn = setupTheDatabaseConnectionSomehow();
stmt = conn.prepareStatement("INSERT INTO person (name, email) values (?, ?)");
stmt.setString(1, name);
stmt.setString(2, email);
stmt.executeUpdate();
}
finally {
try {
if (stmt != null) { stmt.close(); }
}
catch (Exception e) {
// log this error
}
try {
if (conn != null) { conn.close(); }
}
catch (Exception e) {
// log this error
}
}
}
No importa qué caracteres haya en el nombre y el correo electrónico, esos caracteres se colocarán directamente en la base de datos. No afectarán la declaración INSERT de ninguna manera.
Existen diferentes métodos de configuración para diferentes tipos de datos; cuál utilice depende de los campos de su base de datos. Por ejemplo, si tiene una columna INTEGER en la base de datos, debe usar un setIntmétodo. La documentación de PreparedStatement enumera todos los diferentes métodos disponibles para configurar y obtener datos.
La única forma de evitar la inyección de SQL es con SQL parametrizado. Simplemente no es posible crear un filtro que sea más inteligente que las personas que se ganan la vida hackeando SQL.
Por lo tanto, utilice parámetros para todas las cláusulas de entrada, actualizaciones y dónde. SQL dinámico es simplemente una puerta abierta para los piratas informáticos, y eso incluye SQL dinámico en procedimientos almacenados. Parametrizar, parametrizar, parametrizar.
Si realmente no puede usar la Opción de defensa 1: Declaraciones preparadas (Consultas parametrizadas) o la Opción de defensa 2: Procedimientos almacenados , no cree su propia herramienta, use la API de seguridad empresarial de OWASP . Del OWASP ESAPI alojado en Google Code:
¡No escriba sus propios controles de seguridad! Reinventar la rueda cuando se trata de desarrollar controles de seguridad para cada aplicación o servicio web genera pérdida de tiempo y enormes agujeros de seguridad. Los kits de herramientas OWASP Enterprise Security API (ESAPI) ayudan a los desarrolladores de software a protegerse contra fallas de diseño e implementación relacionadas con la seguridad.
Para obtener más detalles, consulte Prevención de la inyección de SQL en Java y Hoja de referencia para la prevención de la inyección de SQL .
Preste especial atención a la Opción de defensa 3: Escapar de todas las entradas proporcionadas por el usuario que presenta el proyecto OWASP ESAPI ).
