php - Cuando se usa correctamente, ¿es htmlspecialchars suficiente para la protección contra todos los XSS?

security

Question

Si las siguientes afirmaciones son verdaderas,

• Todos los documentos se envían con el encabezado HTTP Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=UTF-8 .
• Todos los atributos HTML están incluidos entre comillas simples o dobles.
• No hay etiquetas <script> en el documento.

¿hay casos en los que htmlspecialchars($input, ENT_QUOTES, ''UTF-8'') (convertir & , " , '' , < , > a las entidades HTML con el nombre correspondiente) no sea suficiente para proteger contra las secuencias de comandos entre sitios al generar HTML en un servidor web?

Answer 1

Por lo que yo sé, sí. No puedo imaginar un caso donde no evite xss. Si quieres estar completamente seguro, usa strip_tags ()

Answer 2

Suponiendo que no esté utilizando versiones anteriores de PHP (5.2 o menos), htmlspecialchars es "seguro" (y por supuesto, teniendo en cuenta el código de fondo como @Royal Bg menciones)

En versiones anteriores de PHP, se han formado caracteres UTF-8 con formato incorrecto que hicieron esta función vulnerable ( http://www.securityfocus.com/bid/37389 )

Mis 2 centavos: siempre desinfecte / verifique sus entradas diciendo lo que está permitido, en lugar de simplemente escapar de todo / codificar todo

es decir, si alguien debe ingresar un número de teléfono, puedo imaginar que se permiten los siguientes caracteres: 0123456789 () + -. y un espacio, pero todos los demás son simplemente ignorados / eliminados

Lo mismo se aplicaría a las direcciones, etc. Alguien que especifique caracteres UTF-8 para puntos / bloques / corazones, etc. en su dirección debe estar mentalmente enfermo ...

Answer 3

htmlspecialchars() es suficiente para evitar la inyección de HTML en tiempo de creación de documentos con las limitaciones que establece (es decir, sin inyección en el contenido de la etiqueta / atributo sin comillas).

Sin embargo, hay otros tipos de inyección que pueden conducir a XSS y:

No hay etiquetas <script> en el documento.

Esta condición no cubre todos los casos de inyección de JS. Por ejemplo, podría tener un atributo de controlador de eventos (requiere que JS-escape dentro de HTML-escape):

<div onmouseover="alert(''<?php echo htmlspecialchars($xss) ?>'')"> // bad!

o, lo que es peor, un enlace javascript: (requiere que JS-escape dentro de URL-escapando dentro de HTML-escaping):

<a href="javascript:alert(''<?php echo htmlspecialchars($xss) ?>'')"> // bad!

Por lo general, es mejor evitar estas construcciones de todos modos, pero especialmente cuando se hacen plantillas. Escribir <?php echo htmlspecialchars(urlencode(json_encode($something))) ?> Es bastante tedioso.

Y ... los problemas de inyección también pueden ocurrir en el lado del cliente (DOM XSS); htmlspecialchars() no lo protegerá contra la escritura de JavaScript en innerHTML (comúnmente .html() en scripts de jQuery deficientes) sin escape explícito.

Y ... XSS tiene una gama más amplia de causas que solo inyecciones. Otras causas comunes son:

• Permitiendo al usuario crear enlaces, sin buscar esquemas de URL en buen estado ( javascript: es el esquema dañino más conocido, pero hay más)

• Permitir deliberadamente que el usuario cree un marcado, ya sea directamente o a través de esquemas de marcado de luz (como bbcode, que es invariablemente explotable)

• permitiendo al usuario cargar archivos (que pueden reinterpretarse a través de diversos medios como HTML o XML)