PHP - ¿Cómo hacer un filtrado de entrada seguro a la luz de las vulnerabilidades de codificación multibyte?

Para poder montar una defensa adecuada contra una amenaza, necesitas entenderla. Los esquemas de codificación de capas ciegas son muy peligrosos ya que esto puede presentar un problema cuando, de manera predeterminada, por lo general no es un problema. En general, los problemas de seguridad relacionados con la codificación surgen porque las funciones de escape pueden actuar sobre los datos de manera diferente a como se interpretan. Pero esa no es la única preocupación, también puede confundir al programador porque piensan que una cadena se escapa, cuando no lo es.

La primera preocupación es que las funciones de escape pueden crear cadenas peligrosas para el atacante .

mysql_real_escape_string () es una función especial que sabe qué tipo de codificación está utilizando la base de datos, y ajusta su escape para seguir su ejemplo. Ahí nunca puede haber una desconexión entre el método de codificación, la función de escape y el intérprete. El simple uso de addslashes() puede ser muy peligroso por esta razón.

Como ejemplo, permite usar 0xbf27 , que es un solo carácter GBK. addslashes() no entiende GBK, solo entiende ASCII. Si esta cadena se interpretara como ASCII, el primer carácter sería 0xbf, que es un carácter ASCII no imprimible, permite llamar a ¿ . El segundo carácter ASCII es 0x27, que es una comilla simple ' . Después de las barras de adición () 0xbf27 se convierte en 0xbf5c27 o si se imprimiera en ASCII sería ¿\' . El problema es que 0xbf5c es un carácter GBK válido, por lo que addlashes () ha convertido un carácter de múltiples bytes en 2 caracteres, uno de ellos es una comilla simple. Otra forma de pensar esto es que la barra invertida está siendo consumida por la codificación GBK.

El consumo de caracteres puede ser un problema sin funciones de escape . Permite usar SHIFT-JS y HTML como ejemplo. Este ejemplo se tomó de The Tangled Web :

<img src="http://fuzzybunnies.com/0xEO">...thisisstillapartofthemarkup..." onerror="alret('this will execute!')"
<div>
...the page continues...

En este caso, los "> al final de la etiqueta img son caracteres de control muy importantes que se están consumiendo . " está siendo consumido por el esquema de codificación, y luego > y algún otro texto parece estar separado del atributo src de HTML, no es hasta que alcanza el " onerror que el atributo está terminado.

... Pero eso no es todo. Vamos a cambiar de marcha un poco. ¿Qué hay de urldecode() ?

<?php
$id=mysql_real_escape_string($_GET['id']);
$id=urldecode($id);
mysql_query("select * from user where id='".$id."'");

¿Ves la vulnerabilidad? Desde mi experiencia, la mayoría de los programadores de PHP no lo ven. El problema es que urldecode() se puede usar para crear una cadena vulnerable, digamos que el atacante proporcionó una cadena como http://localhost/vuln.php?id=%2527 or sleep(30)-- . Bueno, casi todas las plataformas de aplicaciones web ejecutarán automáticamente un código de usuario en todas las entradas HTTP. Por lo tanto, el contenido de $ _GET ['id'] es en realidad %27 or sleep(30)-- Esto se debe a que% 25 se ha decodificado en % (% es hex 25). Después de mysql_real_escape_string() o incluso addslashes() , el valor sigue siendo solo %27 or sleep(30)-- Después de ejecutar urldecode () nuevamente, el contenido de $id ahora es ' or sleep(30)-- , lo cual es peligroso.

Por lo tanto, como una sugerencia de pirata informático, cuando audito una base de código que usa magic_quotes_gpc o algo similar, repaso el código buscando funciones de decodificación , como urldcode() , htmlspecialchars_decode() , base64_decode() y funciones similares. A pesar de que la aplicación ejecuta el comando addlashes () a ciegas en todas las entradas, una función de decodificación permitirá al atacante construir su cadena de ataque.

Entonces, ¿cómo te defiendes? Pues prueba tu código. Algunos escáneres de aplicaciones web probarán la codificación de fallas exactamente como esta. De hecho, investigué este tema mientras construía un escáner vulnerable . Otro punto, siempre desinfectar la entrada en el momento de uso, esto evita el problema de descodificar después de escapar. No se puede saber cómo se usará, por lo que la codificación / decodificación / escape de todo siempre será defectuosa. Se utilizaron consultas parametrizadas para crear sentencias de SQL. UTF-8 es un gran valor predeterminado en la mayoría de los casos (pero no siempre), y * la mayoría * de estos problemas no surgen con este esquema de codificación de muli-byte.

No, no recomiendo el enfoque que mencionaste.

Primero que nada, déjame retroceder. Conceptualmente, quizás el enfoque más seguro es aplicar una combinación de validación de entrada y escape de salida. Validación de entrada significa que usted define cuál es la forma de las entradas esperadas / buenas, y verifica que las entradas tengan esa forma. Escape de salida significa que se escapa de las salidas, según el contexto en el que se consumirán. La validación de entrada generalmente se realiza a las entradas tan pronto como las recibe; el escape de la salida generalmente se realiza al final, justo antes de insertar un valor en un documento HTML u otra salida.

Para obtener información general sobre los conceptos de validación de entrada y salida de salida, así como sugerencias de implementación, OWASP tiene algunos recursos excelentes. Consulte también esta pregunta: ¿Filtra las entradas del usuario antes de la base de datos o en la pantalla? , para obtener más información sobre los conceptos.

Para realizar la validación de entrada, creo que definiría una lista blanca de caracteres permitidos o una expresión regular que contenga la entrada esperada, y verificaría que la entrada coincida con esta expresión regular / lista blanca. (Una lista blanca adecuada debería tratar los problemas relacionados con las codificaciones de entrada divertidas). En algunos casos, otra forma de validación de entrada es convertir la entrada en un tipo específico, como (int) . La función de validación específica dependerá del tipo y formato de la entrada; no se puede usar un validador de talla única.

Para hacer un escape de salida, recomiendo usar una biblioteca de escape, como OWASP ESAPI. Debe comprender los diferentes contextos de análisis donde pueden aparecer los valores, y luego usar la función de escape correcta para ese contexto de análisis. Por ejemplo, htmlspecialchars() es una función de escape apropiada para valores dinámicos que se insertarán en un documento HTML entre etiquetas, pero no es apropiada para una URL (para las URL, también debe verificar que el protocolo sea válido). OWASP ESAPI proporciona un conjunto de funciones de escape para los contextos más comunes donde puede insertar datos en las salidas.

Asegúrese de utilizar declaraciones preparadas. No cree consultas SQL a través de la concatenación de cadenas.

Dicho esto, el soporte de PHP para la seguridad es débil. Muchos otros marcos de programación web modernos brindan un mayor soporte para la seguridad, por ejemplo, al proporcionar un sistema de plantillas con escape automático sensible al contexto , al proporcionar soporte automático para tokens CSRF, gestión segura de sesiones, inicios de sesión de usuarios, ORM de bases de datos, etc.

Ver también Ataques de seguridad en aplicaciones web de PHP , ¿Qué características de seguridad debería tener un marco PHP? , ¿Es strip_tags () horriblemente inseguro? , ¿Cuáles son algunas buenas herramientas gratuitas para ejecutar auditorías de seguridad automatizadas para el código PHP? , ¿Cómo realizar una auditoría de seguridad para una aplicación PHP? , ¿Por qué la gente dice que PHP es intrínsecamente inseguro? .

He llegado a la conclusión de usar:

$input = mb_convert_encoding( $input, 'UTF-8' );

Para sanear la codificación de caracteres antes de realizar cualquier otra operación, como la validación de entrada y el escape de salida. Probablemente tendré que buscar en la fuente de mb_convert_encoding y en las pruebas unitarias para estar seguro, pero tengo la impresión de que siempre devolverá una cadena UTF-8 válida.

El resto de mi aplicación utilizará utf-8 en todo momento, lo que evita que todo se interprete de manera diferente hasta el navegador.