Encuentre posibles problemas de inyección de SQL en código Java/JSP

Question

Estoy trabajando para un cliente con una enorme base de código heredado que consta de varias aplicaciones basadas en Java y JSP.

La mayoría de las consultas se realizan utilizando el sistema 'orm' de construcción casera.Algunas aplicaciones utilizan JDBC antiguo y simple.Algunas aplicaciones se basan en Hibernate (sí, la compilación HQL con signos más también es un problema potencial).Algunas de las aplicaciones más antiguas están escritas íntegramente en JSP.

Encontré un par de errores de inyección SQL manualmente.Pero realmente me vendría bien algún tipo de herramienta para buscar posibles puntos débiles.

¿Algunas ideas?

Answer 1

yo recomendaria encontrar errores (También hay un complemento de eclipse) que puede rastrear estos problemas y muchos más.

Lo estamos usando en el trabajo, es rápido y vale la pena (como gratis).Hemos resuelto algunos problemas comunes con su ayuda.

Answer 2

Escribiría algunas búsquedas o cargaría un IDE que buscara el uso de java.sql.Statement en lugar de PreparedStatement.

Answer 3

¿Qué tamaño tiene su espacio de URL?Si es posible, es mejor intentar la inyección SQL mediante solicitudes HTTP GET y POST.Hay algunos problemas que se pueden encontrar mediante el examen del código fuente/bytes, pero la única forma de saber con certeza qué tipos de entradas potencialmente maliciosas aceptará su aplicación es utilizar solicitudes HTTP.

CAL9000 es una buena herramienta de prueba de inyección SQL/scripting entre sitios si su conjunto de URL es pequeño.

Las empresas que se toman en serio la detección de entradas maliciosas mal manejadas contratarán a un tercero para realizar pruebas de penetración. Seguridad de sombrero blanco es un proveedor con el que he trabajado en el pasado y puedo recomendar.Los usamos para un sitio web de comercio electrónico de más de 100 millones de dólares.(No tengo ninguna afiliación con White Hat y no me beneficio de ninguna manera si usted se convierte en su cliente).

Dejando a un lado todas las pruebas/endurecimiento de su código, es una muy buena idea tener un firewall HTTP implementado como mod_seguridad.

Answer 4

Cuando estaba trabajando en la localización de la aplicación "esta-nunca-necesitará-localización", utilizamos una herramienta casera para analizar el código compilado (IL en .NET, es lo mismo que el código de bytes en Java).

Puede encontrar llamadas a los métodos especificados que funcionan con DB (normalmente operaciones CRUD) que tienen un parámetro de cadena con comando SQL, y realizar un seguimiento de la instancia de cadena y verificar la concatenación.

Usamos .NET Reflector para descompilar y rastrear cadenas.Pero no sé si hay disponible una herramienta similar para Java :(.

Answer 5

Puedes optar por la prevención en lugar de la cura.agregue una capa de desinfección justo debajo de su interfaz de usuario, para que no termine con sql/scripts en las entradas del usuario.Debe haber ejemplos en Java, he visto un enfoque de este tipo en CakePHP.

Answer 6

Encuentre cualquier lugar que no utilice un PreparedStatement.

Answer 7

Recomiendo CAL9000.Puede obtener detalles en el siguiente enlace:

CAL9000