¿Cómo protegerse de la nueva técnica de inyección de Javascript que no utiliza eval ()?

Question

¿Cómo protegerse de la nueva técnica de inyección de Javascript que no utiliza eval ()?

#1 de rook (11 votos)
#2 de Karol J. Piczak (2 votos)

4

Hay una nueva técnica de inyección de Javascript que genera chatter en los foros mencionados aquí

Aquí está el ejemplo del código:

String.prototype.code = function(){ return (new Function('with(this) { return ' + this + '}' )).call({}); };
var s = 'alert("hello!");'
s.code();

¿Qué componentes de infraestructura deben actualizarse (si los hay) para monitorear y proteger de esta clase de explotación?

Por ejemplo:

Tengo la impresión de que algunos administradores de bases de datos analizan sus bases de datos en busca de pruebas de un ataque de inyección ... esto es casi un enfoque de última instancia para mitigar una aplicación mal escrita en una empresa distribuida.

La última vez que trabajé con Microsoft en un ataque de Inyección JS, el desarrollador en India no verificó correctamente la entrada del formulario. Esto causó que la base de datos de nuestro cliente estuviera llena de código Javascript que se ejecutaba en el cliente. La respuesta de Microsoft fue buscar en la base de datos las cadenas predefinidas que se usan comúnmente en los ataques.

Estoy asumiendo que hay productos o sensores que monitorean el tráfico de SQL o HTTP para detectar malware obvio en js. Si doy un paso más en mi suposición, esos dispositivos deben tener la firma actualizada para este vector.

web-application appsec xss javascript

pregunta random65537 17.05.2011 - 17:10

fuente

2 respuestas

2

No estoy seguro de entender qué es tan diferente en esta técnica que el tipo general de ~~inyección~~ de secuencias de comandos entre sitios.

Si esto ha avanzado hasta el momento y usted permite que se inyecte y ejecute código JavaScript arbitrario en su sitio, usted está buscando problemas de cualquier manera, sin importar la técnica. Intente buscar en su sitio las vulnerabilidades de XSS .

Lo siento si me falta algo aquí, corríjame si no obtuve el panorama general aquí (como me siento de esa manera).

respondido por el Karol J. Piczak 17.05.2011 - 17:30

fuente

Lea otras preguntas en las etiquetas web-application appsec xss javascript

¿Qué beneficio ofrecen los Captchas? ¿Ver la política de grupo aplicada en una PC cliente no se considera una infracción de seguridad menor?

score 11 · Accepted Answer

Es todo XSS, no es apropiado llamarlo "Inyección de JavaScript". El vector XSS del que estás hablando no es nuevo, y es interesante. XSS es un problema de salida . Si realiza la misma validación de entrada en todas las entradas, seguirá teniendo problemas con XSS. Si codifica o elimina todos los caracteres < > para cada variable de entrada, todavía tendrá grandes problemas con xss. Esto se debe a que XSS depende en gran medida de dónde se imprime la variable en la página.

Esta línea de código es segura:

var x='alert(123)'

Sin embargo, puede explotarse si el atacante tiene acceso a comillas simples ' . Por ejemplo, si el atacante tenía una solicitud como ?x=';alert(123); , entonces podría romper las comillas y ejecutar javascript. La solución es codificar todas las comillas también. En PHP puedes usar htmlspecialchars($var,ENT_QUTOES);

Pero aquí está el kicker real, incluso esta función no puede detener a todos los XSS. Se detendrá alrededor del ~ 90% de xss. Pero incluso después de htmlspecialchars($var,ENT_QUTOES); , todavía puedes tener problemas con xss basado en DOM y XSS a través de controladores de eventos .

Entonces, ¿cuál es la solución real ? ¡Prueba tu código! Utilice un servicio gratuito de exploración de vulnerabilidades como Sitewatch o una herramienta de código abierto como Wapiti . Estas herramientas conocen todas las reglas extrañas para XSS y podrán encontrar estas violaciones en su aplicación. Google utiliza Sitewatch .