Desarrollo inseguro, aún con un Object-Relational Mapping.
Seguro más de una vez has escuchado cuándo alguien dice orgulloso: "Mi aplicación es más segura, uso Hibernate para la persistencia de mis datos."
Si no, algún día toparás con alguien que te lo diga.
El uso de herramientas como Hibernate, que nos permiten trabajar con objetos durante nuestras sesiones de trabajo no garantiza que nuestra aplicación sea inmune. Simplemente no hay aplicaciones inmunes, pero no hay que dejar que sea trabajo fácil para el que intenta corromper nuestra seguridad.
Por defecto Hibernate utiliza sentencias de tipo Prepared Statements lo cual de primera instancia nos permitiría pensar que no debemos preocuparnos por algún SQL Injection, pero no es así, por ejemplo:
Como vemos la variable idUsuario puede contener caracteres no deseados que pueden ser interpretados de manera que generen errores o peor aún, fugas de información.
Otro ejemplo con el mismo caso :
La manera que pareciera más correcta para utilizar parámetros en nuestras consultas son más o menos estas:
Enviando parámetros posicionados:
En el caso anterior le enviamos el parámetro a utilizar y su tipo, como a éste le indicamos que estará en la posición 0 será el primero que utilice en la consulta, muy parecido a como trabajaríamos con el prepared statement del JDBC.
Identificando los parámetros:
Como vemos, se asigna un nombre al parámetro y la consulta lo consumirá, no por la posición que le indiquemos si no por el identificador que le hemos asignado.
Para los que no quieren alejarse de SQL:
Hay algunas otras maneras, aunque a mi experiencia estas son las más utilizadas y por ende los casos más vulnerables.
Con sencillas prácticas podemos evitar dolores de cabeza terribles como cuando el cliente nos busque por que los datos han desaparecido. >.<'
- 043h68's blog
- Inicie sesión o regístrese para enviar comentarios
Desarrollo inseguro
Tienes razón cualquier aplicación puede ser insegura si no se tiene cuidado.
@ezamudio había escrito algo sobre seguridad en SQL
http://www.javamexico.org/blogs/ezamudio/ejemplo_de_inyeccion_de_sql
Buen post.
Gracias.
Gracias!
Tienes razón, que bueno que agregas el link del post de @ezamudio, ayuda a comprendero más éste.
Aprovechar busqueda por criterio
Me parece que cuando se usa hql en lugar de SearchByCriteria se esta desaprovechando una de las principales ventajas de Hibernate.
No solo dificultas enormemente las inyecciones, sino que también te libras de una buena vez del odioso SQL y la necesidad de estar metiendo dichos Strings con sentencias SQL a ciegas en tu código Java.
Un ejemplo muy simple: Al query del ejemplo
lo podemos fácilmente estructurar así con SearchByCriteria :
Con esto Hibernate solo espera un valor para comparar y no aceptará código hql dentro de la variable idUsuario.
¿No creen que conviene mas? :)
HQL.
Y que me podrías comentar sobre el HQL de hibernate?
Consultas complejas
Estoy de acuerdo contigo en cuanto al
Legibilidad HQL ya cambió un poco el tema.
Buen post 043h68, saludos.
Para mí es más sencillo entender y optimizar un query que optimizar sentencias Hibernate.
Debo comentar que no diseñar una buena base de datos que incluya llaves e índices por el simple hecho de usar Hibernate me parece un grave problema.
Por otra parte trabajar con procedimientos almacenados es más sencillo y da mejor rendimiento vs su costo de migración a otra plataforma.
¿Tendrá Hibernate algún motor para ejecución de script tipo PL?