¿Es esto vulnerable a la inyección de Sql?

Question

¿Es esto vulnerable a la inyección de Sql?

#1 de OscarAkaElvis (2 votos)
#2 de kaidentity (0 votos)

3

Resulta que tengo una aplicación que cuando inserto una cita simple me aparece lo siguiente:

httpStatus":400,"errorCode":"BAD_QUERY_PARAMETER","message":"java.lang.NumberFormatException: For input string: \"'\"","implementationDetails":"com.sun.jersey.api.ParamException$QueryParamException: java.lang.NumberFormatException: For input string: \"'\"\n\tat com.sun.jersey.server.impl.model.parameter.QueryParamInjectableProvider$QueryParamInjectable.getValue(QueryParamInjectableProvider.java:74)

La pregunta que tengo es; ¿Se puede usar este parámetro para realizar la inyección SQL? Si es así, ¿cómo puedo probar si este es el caso?

sql-injection java error-handling

pregunta user152754 07.07.2017 - 00:01

fuente

2 respuestas

Lea otras preguntas en las etiquetas sql-injection java error-handling

Copias de seguridad cifradas incrementales fuera del sitio para una pequeña oficina de abogados [cerrado] ¿Cómo deshabilitar "la última contraseña que recuerda" de Google, después de saber que alguien tiene mi contraseña?

score 2 · Answer 1

Claro, parece vulnerable. El backend está esperando allí un número y eso generó el error. Pero el síntoma de insertar una sola cita y generar un error es una buena señal, probablemente es una vulnerabilidad de inyección de SQL.

El primer paso podría ser saber qué tipo de base de datos es. Se supone que lo sabes ... porque es tu propia base de datos, ¿verdad? : D

Le recomiendo que inicie algunas aplicaciones como sqlmap para explorar más a fondo la vulnerabilidad.

De todos modos, puedes comprobar lo habitual. Hay una lista completa de esto. Voy a poner tres de ellos:

' or '1'='1
a' or 1=1--
' or 0=0--

Buena suerte.

score 0 · Answer 2

La excepción NumberFormatException suele ser una indicación de que el servidor realiza una validación de que una entrada es realmente un número. Proporcionar una cotización en este caso obviamente genera una violación de validación de entrada y esto no es una indicación de una vulnerabilidad potencial de SQLi. Para confirmar una vulnerabilidad de este tipo, debe poder modificar el resultado proporcionando entradas como

0 and 1=1 (=> lot of results because where clause always true)
0 and 1=0 (=> no results because where clause always false)

En su caso, supondría que estas entradas también generarán una excepción NumberFormatException. Así que mi conjetura es que su código no es inyectable.