La frase SQL se ve así,
"SELECT * from XX where id = '" + id + "'"
La variable id viene directamente del parámetro GET denominado id .
Y la aplicación web de Java no permite explícitamente comillas simples. Si se encontró una comilla simple en ese parámetro, el servidor deja de procesarlo de inmediato y devuelve un error.
Entonces, ¿esto es aún explotable? Con entorno postgresql y tomcat.
Es posible que desee consultar este documento ( enlace de la máquina de backback ). Detalla algunos métodos para omitir tales filtros.
Por ejemplo, algunos filtros SQL reemplazan todas las comillas simples con un par de comillas simples. Sin embargo, alimentarlos con una entrada que contenga \' puede omitir esto.
Además, existe el contrabando de Unicode, donde se usa un carácter Unicode que Java (PHP / Ruby / Python / cualquier otra cosa) entiende como diferente de una cita, pero la base de datos no.
A menos que tenga una razón realmente buena, le recomiendo que use el escape integrado.
Estás hablando de "prevenir el mal conocido", que solo funciona hasta que alguien piensa en algo nuevo. Como dice @Manishearth, \' es una técnica. Para una URL, %27 es otra. En HTML, puede tener ' , ' , ' , ' , ' son otros. ¿Qué hace su servidor si estas técnicas se combinan como en %40%230039%3B ( ' url codificado) o %5C%27 ( \' url codificado) o \\' ?
Prevenir el mal conocido es siempre una propuesta arriesgada. Permitir el bien conocido siempre es mejor cuando es una opción. Por lo tanto, la conversión a un tipo entero siempre proporcionará más seguridad que tratar de evitar cadenas específicas. Las declaraciones preparadas proporcionan una excelente capa de protección.
Consulte el artículo de Wikipedia sobre Mitigación de la inyección de SQL .
Suponiendo que el parámetro 'ID' de GET solo esté en dígitos, lo mejor que puede hacer es verificar si ID realmente contiene solo dígitos, por ejemplo, convirtiéndolo en un INT (y detectando la excepción si hay alguna), y no algunas cosas desagradables como comillas / barras inclinadas / caracteres codificados / etc.
En general, prefiero tener una variable entera real, ya que sé perfectamente que contiene solo dígitos, en lugar de una cadena de escape que podría contiene algunos caracteres extraños ..
Lea otras preguntas en las etiquetas sql-injection