En este blogpost que describe un pentest, el el autor agrega ' a un campo que requiere algo de valor y concluye que existe una vulnerabilidad de SQLi:
Tras una investigación adicional, agregar una sola cita haría que el servidor devuelve un error de estado 500, que ... SCREAMS SQLi
¿Un código HTTP 500 significa que es vulnerable a SQLi? ¿O todos los códigos de error HTTP significan que es una inyección SQL? ¿Qué código HTTP no significa un SQLi?
¿Un código HTTP 500 significa que es un SQLi?
Un código de error 500 significa Error interno del servidor . Consulte aquí para ver los códigos de estado HTTP y sus significados. Un código 500 en este caso (cuando se agrega una comilla simple) no significa necesariamente que sea un SQLi, porque puede tener otras causas (prevención de SQLi errónea, otros problemas de análisis). ¡Pero las posibilidades son realmente buenas, que es un SQLi!
¿o todos los códigos de error HTTP significan que es una inyección SQL?
No. Por ejemplo, se podría dar un 400 (Bad Request) , ya que no se permiten comillas simples. Esto podría indicar que se previene un SQLi (de forma sucia).
¿Qué código HTTP no significa un SQLi?
Eso nunca es seguro, porque la prevención de SQLi generalmente escapa a la cadena y la almacena en la base de datos, mientras que todo funciona normalmente y no se producen excepciones. Entonces, en ambos casos (SQLi y SQLi prevenido) el código de respuesta podría ser 200 (OK) .
No hay código de error para inyecciones de SQL. El código de estado HTTP 500 solo significa un error interno del servidor. Cuando se puede romper el código simplemente agregando algunos caracteres especiales, el código es vulnerable a una inyección de SQL ya que la entrada no está saneada,
Por ejemplo:
$sql = "SELECT * FROM mytable WHERE name = '$name'";
Al agregar "Jose's" en el campo, la declaración SQL sería:
$sql = "SELECT * FROM mytable WHERE name = 'Jose's'";
que sería un error en la sintaxis.
Si la entrada no está saneada, ahora podría agregar instrucciones SQL adicionales después de 'y, por lo tanto, ejecutar sus propias instrucciones SQL.
Digamos que la URL se ve así:
http://anysite.com/somefile.php?id=1
Y la consulta se convierte en:
SELECT * FROM product WHERE id='1'
Ahora, cuando intentes inyectar la comilla simple en esta forma:
http://anysite.com/somefile.php?id=1'
Entonces la consulta se convierte en esto:
SELECT * FROM product WHERE id='1''
Pero aquí coloca la comilla simple en ella para que devuelva el error de sintaxis siempre. Debido a que la base de datos no puede cumplir con la consulta, devolverá el error de sintaxis. El punto de la nota es la base de datos está devolviendo el error no el servidor. Por lo tanto, no hay relación entre el error del servidor 500 y el error de SQL.
Nota: los desarrolladores pueden ocultar el error de sintaxis mediante el uso de @ o el uso de algún otro, para que no pueda ver el error de sintaxis. Entonces, el SQL ciego viene al rescate.
Lea otras preguntas en las etiquetas http sql-injection