En esta edición del quiz, un poco sobre la influencia que tiene la codificación de una página que se envía al cliente.
$charset = 'utf-8';
/* Comprobación simple del charset: no debe contener caracteres raros */
if ( !empty($_GET['charset']) && preg_match('/^[a-z\d-]+$/i', $_GET['charset']) )
$charset = $_GET['charset'];
header('Content-type:text/html; charset=' . $charset);
?>
<html>
<head>
<title>Test</title>
</head>
<body>
<?php
if ( !empty($_GET['url']) )
echo sprintf('<a href="%s">Enlace</a>', htmlentities($_GET['url']));
?>
</body>
</html>
¿Qué problema o problemas existen en el código mostrado?
Solución
Una alternativa de solución, es la que comenta Francesc, sin embargo la funcion htmlentities no acepta todos los encodings, lo que podría conllevar a que el código mostrado sea vulnerable a ataques XSS, para evitar esto, lo mejor es evitar que el usuario establezca el encoding del documento.
7 replies on “Implicancias de la codificación del documento”
Yo veo dos cosas relacionadas con la codificación:
1. El propio fichero estará en alguna codificación por lo que si se permite cambiarla "al vuelo" se debería pasar toda la salida por un conversor (obstart() + iconv(), por ejemplo).
2. La función htmlentities() por defecto trata el contenido que le pasas como ISO-8859-1, por lo que si éste está en otra codificación hay que pasársela.
Haber, veamos...
¡¡Quien sabe!! pero creo que tiene que ver con lo que dice Francesc (obstart() un encode al tipo de juego de caracteres + echo ob_get_clean())... hmmm 🙁
Victor, como seguramente sabes, iconv permite convertir un texto en un encoding X a otro Y, lo que sugiere Fransesc en el punto 1, es para asegurar que el documento vaya en un solo encoding y no sea una mezcla, valga la redundancia, de varios encodings.
Francesc, sobre los puntos que pones tienes razón, en especial en el punto 2, ya que el código mostrado podría ser vulnerable por ejemplo a ataques XSS.
Sabes tu quiz y la forma como debaten es excelente pero fuera bueno que al ultimo pusieras el codigo vulnerable y el codigo arreglado sin vulnerabilidad no crees alex... asi seria mejor
Saludos
Muchas gracias por la sugerencia, dentro de unos días actualizaré las entradas para que éstas sean más útiles 🙂
hmm, no entiendo con claridad cual sería la solución.
Victor, el punto es que la función html_entities no acepta todos los encodings, sólo unos cuantos, y esto se considera un problema si dejas especificar que encoding debería tener la página resultante.