ataque XSS a htmlspecialchars de bypass() en atributo de valor

Digamos que tenemos esta forma, y la posible parte de un usuario para inyectar código malicioso es esto más adelanteataque XSS a htmlspecialchars de bypass() en atributo de valor

... 
<input type=text name=username value= 
     <?php echo htmlspecialchars($_POST['username']); ?>> 
...

No puede simplemente poner una etiqueta , o un javascript: alerta(); llamada, porque el valor se interpretará como una cadena, y htmlspecialchars filtra el <,>, ', ", por lo que no podemos cerrar el valor con las cotizaciones.

Podemos usar String.fromCode (... ..) para moverse por las comillas, pero todavía no puede obtener un cuadro de alerta sencilla para que aparezca.

¿Alguna idea?

Fuente

2010-05-24 Setzer

Excelente pregunta, porque Confío en htmlspecialchars() para la seguridad, como lo estoy, estoy seguro, mucha gente. Me hace preguntarme si se puede deslizar una evaluación() o algo así ... especialmente porque creo que el navegador se deshabilita antes de aprobar valores para el intérprete js. Creo que sería más explotable si está insertando datos de usuario en un clic en un clic o href u otro atributo ejecutable; explotar un atributo de valor parece ser más difícil. –

@Frank: si está poniendo datos maliciosos en Javascript, también necesitas codificarlo con Javascript. – SLaks

Además, es importante mencionar que permitir a las personas inyectar HTML o JavaScript en su página (y no en su fuente de datos) no conlleva ningún riesgo de seguridad inherente. Ya existen extensiones de navegador que le permiten modificar el DOM y las secuencias de comandos en las páginas web, pero dado que solo están en el lado del cliente, son las únicas que sabrán.

Dónde XSS se convierte en un problema es cuando las personas a) lo utilizan para eludir la validación del lado del cliente o el filtrado de entrada o b) cuando las personas lo utilizan para manipular los campos de entrada (por ejemplo, cambiando los valores de etiquetas de opción en una ACL a otórgales permisos que no deberían tener). La ÚNICA forma de prevenir estos ataques es desinfectar y validar las entradas del lado del servidor en lugar de, o además de, la validación del lado del cliente.

Para desinfectar HTML de entrada, htmlspecialchars es perfectamente adecuado a menos que QUIERA permitir ciertas etiquetas, en cuyo caso puede usar una biblioteca como HTMLPurifier. Si está colocando la entrada del usuario en HREF, ONCLICK o cualquier atributo que permita la creación de scripts, solo está buscando problemas.

EDIT: mirando su código, parece que no está citando sus atributos! Eso es bastante tonto. Si alguien puso su nombre de usuario como:

john onclick="alert('hacking your megabits!1')"

A continuación, la secuencia de comandos podría analizar como:

<input type=text name=username value=john onclick="alert('hacking your megabits!1')">

SIEMPRE use comillas alrededor de los atributos. Incluso si no son ingresados por el usuario, es un buen hábito entrar.

<input type="text" name="username" value="<?php echo htmlspecialchars($_POST['username']); ?>">

Fuente

2010-05-24 03:03:45 Daniel

Aunque estoy de acuerdo en que debe citar, 'htmlspecialchars' reemplaza las comillas simples y dobles. –

por supuesto! ¡Gracias! – Setzer

El espacio es correcto, pero aún no puede usar citas, es cuando String.fromCharCode será útil para el ataque anterior – Setzer

value es un atributo HTML normal, y no tiene nada que ver con Javascript.
Por lo tanto, String.fromCharCode se interpreta como un valor literal, y no se ejecuta.

Para inyectar el script, primero necesita forzar el analizador para cerrar el atributo, lo que será difícil de hacer sin >'".

Olvidó poner comillas alrededor del valor del atributo, por lo que todo lo que necesita es un espacio.

Incluso si citan el valor, aún puede ser vulnerable; ver this page.

Fuente

2010-05-24 02:39:58 SLaks

¿De verdad? ¿Cómo se puede ejecutar el código dentro de un 'valor' citado cuando no se puede cerrar la cita? –

I chec ked esa página, pero no puedo ver un ataque que omita htmlspecialchars y el atributo se cita – Setzer

Hay una manera.No está de paso htmlspecialchars() el tercer parámetro de codificación o la comprobación de codificación correctamente, así:

$source = '<script>alert("xss")</script>'; 
$source = mb_convert_encoding($source, 'UTF-7'); 
$source = htmlspecialchars($source); //defaults to ISO-8859-1 
header('Content-Type: text/html;charset=UTF-7'); 
echo '<html><head>' . $source . '</head></html>';

sólo funciona si se puede a) establecer la página a la salida UTF-7 o b) engañar a la página para que lo haga (por ejemplo, iframe en una página sin un juego de caracteres claro). La solución es garantizar que todas las entradas tengan la codificación correcta y que la codificación esperada esté configurada correctamente en htmlspecialchars().

Cómo funciona? En UTF-7, <> "los caracteres tienen diferentes puntos de código que UTF-8/ISO/ASCII para que no se escapen a menos que conviertan la salida a UTF-8 para aseguramiento (ver extensión iconv)

Fuente

2010-06-25 12:24:10 padraicb

Digo 'htmlentities()' debería usarse en lugar de 'htmlspecialchars()', con 'ENT_QUOTES | ENT_HTML5' banderas. ;) –

ataque XSS a htmlspecialchars de bypass() en atributo de valor

Respuesta

Cuestiones relacionadas