Se negó a ejecutar un script de JavaScript. Código fuente del script encontrado dentro de la solicitud

81

En WebKit obtengo el siguiente error en mi JavaScript:

Se negó a ejecutar un script de JavaScript. El código fuente del script que se encuentra dentro de la solicitud.

El código es para un spinner de JavaScript, ver ASCII Art .

El código solía funcionar bien y todavía funciona correctamente en Camino y Firefox. El error solo parece aparecer cuando la página se guarda a través de un POST y luego se recupera mediante un GET. Sucede tanto en Chrome / Mac como en Safari / Mac.

Alguien sabe lo que esto significa y cómo solucionarlo?

javascript code-injection

— doekman
fuente

Hmm, probablemente mi WebKit se haya actualizado. La página funciona de nuevo. También todas las revisiones antiguas de la página (consulte el botón Revisiones antiguas en la parte inferior de la página).

— doekman

este error ocurre en el editor tryit de w3schools w3schools.com/js/tryit.asp?filename=tryjs_events el script se ejecuta la primera vez, pero está bloqueado desde el momento en que hace clic en el botón "editar y hacer clic en mí".

1

Si presiona el botón "editar y haga clic en mí", el contenido del área de texto (con el javascript) se envía al servidor a través de un POST. Chrome detecta que javascript está publicado en el servidor y podría ser malicioso. El bloqueo es la medida contra los ataques XSS.

— doekman

Aquí está el enlace que muestra cómo configurar el encabezado X-XSS-Protection: stackoverflow.com/questions/4635403/…

— hh_s

67

Es una medida de seguridad para prevenir ataques XSS (cross-site scripting) .

Esto sucede cuando se envía algún código JavaScript al servidor a través de una solicitud HTTP POST, y el mismo código vuelve a través de la respuesta HTTP. Si Chrome detecta esta situación, se niega la ejecución del script y aparece el mensaje de error Refused to execute a JavaScript script. Source code of script found within request.

Consulte también esta entrada de blog sobre Seguridad en profundidad: nuevas funciones de seguridad .

— Greg
fuente

5

Sería bueno ver algún tipo de referencia.

— Kangax

¿Pero esto va a causar algún problema? es decir, ¿está bien si ignoramos este mensaje?

— Samach

@Greg ¿Qué algoritmo utilizan los navegadores para "detectar la situación"? No puede ser simplemente buscar la cadena "<script>" en los datos, ¿verdad?

— Pacerier

1

Me gustaría ver una discusión entre esta respuesta y la respuesta de Kendall a continuación con respecto a la implicación de usar la solución X-XSS-Protection: 0. ¿Abre el sitio a ataques XSS? Si es así, ¿hay otra forma de resolver este error?

— dansalmo

Referencia que explica esto con más detalle , blog.chromium.org/2010/01/… Consulte la sección Protección reflectante XSS

— h - n

131

Esta "función" se puede desactivar enviando el encabezado HTTP no estándar X-XSS-Protectionen la página afectada.

X-XSS-Protection: 0

— Kendall Hopkins
fuente

2

Asegúrese de que la página que desencadena este error se envíe con este encabezado, no con la página de envío.

— Kendall Hopkins

@KendallHopkins .... ¿Puede decirme cómo puedo usar esto a través de Javascript / Java?

— SRy

+1 Esto responde la pregunta completamente a diferencia de la respuesta aceptada, sin embargo, advierte pero no da ninguna solución.

— JohnnyQ

2

-1 Esto puede "solucionar" el problema en Chrome, pero no resuelve el problema real: su sitio sigue siendo vulnerable a los ataques de secuencias de comandos entre sitios (más vulnerable de hecho) si hace esto. La solución real, como @Greg aludió pero no dijo explícitamente, es no enviar HTML / JS de vuelta en la respuesta que se envió en la solicitud. La lectura de los enlaces que proporcionó debería haberlo dejado claro.

— sfarbota

@sfarbota Hay muchos casos en los que esta protección es mala. Por ejemplo, rompe muchos sistemas CMS, donde es perfectamente aceptable devolver JS que está editando. Pero para su punto, no recomendaría agregar esto a cada página de un sitio y probablemente solo sea necesario en los casos en que un desarrollador encuentra este error.

— Kendall Hopkins

15

Respuesta corta : actualice la página después de realizar el envío inicial del javascript, o presione la URL que mostrará la página que está editando.

Respuesta larga : debido a que el texto que completó en el formulario incluye javascript, y el navegador no necesariamente sabe que usted es el origen del javascript, es más seguro para el navegador asumir que usted no es el origen de este JS, y no ejecutarlo.

Un ejemplo : supongamos que le di un enlace a su correo electrónico o facebook con algo de javascript. E imagina que el javascript enviaría un mensaje a todos tus amigos con mi enlace genial. Entonces, el juego de hacer que ese enlace sea invocado se convierte en simplemente, encontrar un lugar para enviar el javascript de manera que se incluya en la página.

Chrome y otros navegadores WebKit intentan mitigar este riesgo al no ejecutar ningún javascript que se encuentre en la respuesta, si estuviera presente en la solicitud. Mi infame ataque se vería frustrado porque su navegador nunca ejecutaría ese JS.

En su caso, lo está enviando a un campo de formulario. El campo Publicar del formulario provocará una representación de la página que mostrará el Javascript, lo que hará que el navegador se preocupe. Sin embargo, si su javascript está realmente guardado, ingresar a esa misma página sin enviar el formulario permitirá que se ejecute.

— Koos Kleven
fuente

1

Como han dicho otros, esto sucede cuando una respuesta HTTP contiene una cadena de JavaScript y / o HTML que también estaba en la solicitud. Esto generalmente se debe a la introducción de JS o HTML en un campo de formulario, pero también se puede activar de otras formas, como ajustar manualmente los parámetros de la URL.

El problema con esto es que alguien con malas intenciones podría poner cualquier JS que quiera como valor, enlazar a esa URL con el valor JS malicioso y causar problemas a sus usuarios.

En casi todos los casos, esto se puede solucionar mediante la codificación HTML de la respuesta , aunque hay excepciones. Por ejemplo, esto no será seguro para el contenido dentro de una <script>etiqueta. Otros casos específicos se pueden manejar de manera diferente; por ejemplo, la codificación de URL sirve mejor para inyectar entradas en una URL.

Como mencionó Kendall Hopkins, puede haber algunos casos en los que realmente desee que se ejecute JavaScript de las entradas del formulario, como crear una aplicación como JSFiddle . En esos casos, le recomendaría que al menos revise la entrada en su código de backend antes de escribirlo a ciegas. Después de eso, puede usar el método que mencionó para evitar el bloqueo de XSS (al menos en Chrome), pero tenga en cuenta que lo está abriendo a los atacantes.

— sfarbota
fuente

0

Utilicé este truco de PHP hacky justo después de comprometerme con la base de datos, pero antes de que el script se procese desde mi _GETsolicitud:

if(!empty($_POST['contains_script'])) { 
    echo "<script>document.location='template.php';</script>";
}

Esta fue la solución más barata para mí.

— gabrielcrowe
fuente