¿Existe una inyección de SQL equivalente en los parámetros pasados de url a un servlet?

Si todo lo que hace es imprimir los parámetros, el vector de ataque principal es XSS .

Aunque esto no puede ejecutar código en el servidor, puede ejecutar código en el navegador.

Entonces, si un atacante envía a un usuario legítimo un enlace

http://www.example.com/foo.jsp?foo=<script>alert(123)</script>

y cuando se sigue el enlace, el código del script se ejecuta en el navegador del usuario por la página, entonces la página es vulnerable. Efectivamente, el lado del cliente de la sesión ahora está bajo el control del atacante si el atacante hubiera hecho algo más malvado en lugar de mostrar un cuadro de alerta. Por ejemplo, enviando cookies a ellos mismos o inyectando un keylogger.

Hay muchas variaciones en este ataque y no tiene que ser en forma de etiquetas script .

La ejecución de código arbitrario es dudosa, otras formas de inyecciones son una posibilidad.

Pueden ocurrir cosas como la inyección de HTML o incluso XSS si la entrada no se verifica correctamente y / o no se realiza la codificación de salida.

También considere la posibilidad de phishing y desfiguración no persistente.

Un controlador de errores nunca debe depender de los parámetros GET y solo debe mostrar información mínima. Se recomienda no utilizar un parámetro GET para generar un mensaje de error.

Espero que esto ayude!

Como se mencionó anteriormente, su principal vector de ataque para mostrar los parámetros de la cadena de consulta sería la vulnerabilidad XSS. Si estos datos nunca van a una capa persistente, se conoce como un ataque XSS tipo II (reflejado).

Siempre debe considerar el contexto en el que se presentan los datos que no son de confianza. Muchas plantillas de plantillas / web modernas como Jinja y Angular proporcionan un escape contextual automático. Aun así, aún debe validar y desinfectar todos los datos no confiables con los que entra en contacto.

Si un atacante sabe que los parámetros de la cadena de consulta no se están limpiando, podría crear un parámetro que envíe una cookie de sesión a un servidor remoto con bastante facilidad. Por eso siempre debes practicar la defensa en profundidad en la seguridad. HttpOnly (si utiliza cookies) / Política de seguridad de contenido / Desinfección / Validación / Cifrado, etc. ...