some - sanitize() php

Cuándo usar filter_input()

Question

Esta pregunta fue originalmente hecha en un comentario here .

¿ filter_input() siendo necesario filter_input() si está utilizando consultas parametrizadas y htmlspecialchars() antes de imprimir los datos proporcionados por el usuario?

Me parece innecesario, pero siempre me han dicho que "Filtro de entrada, Salida de escape". Entonces, aparte de una base de datos (u otra forma de almacenamiento), ¿hay alguna necesidad de filtrar los datos ingresados?

Answer 1

Bueno, habrá diferentes opiniones.

Mi opinión es que siempre debe usarla (o la extensión de filter en general). Hay al menos 3 razones para esto:

1. La entrada de desinfección es algo que siempre debes hacer. Dado que la función le brinda esta capacidad, realmente no hay razón para encontrar otras formas de desinfectar las entradas. Ya que es una extensión, el filtro también será mucho más rápido y más seguro que la mayoría de las soluciones de PHP, lo que ciertamente no duele. La única excepción es si necesita un filtro más especializado. Incluso entonces debería tomar el valor usando el filtro FILTER_UNSAFE_RAW (ver # 3).

2. Hay muchas cosas buenas en la extensión del filter . Puede ahorrarle horas de escribir el código de saneamiento y validación. Por supuesto, no cubre todos los casos, pero hay suficiente para que pueda centrarse más en el filtrado específico / código de validación.

3. El uso de la función es muy bueno para cuando está depurando / auditando su código. Cuando se utiliza la función, usted sabe exactamente cuál será la entrada. Por ejemplo, si usa el filtro FILTER_SANITIZE_NUMBER_INT , puede estar seguro de que la entrada será un número: no habrá inyecciones SQL, ni código HTML ni Javascript, etc. Si, por otro lado, utiliza algo como FILTER_UNSAFE_RAW entonces sabrá que debe tratarse con cuidado y que puede causar problemas de seguridad fácilmente.

Answer 2

Como dice Sverri M. Olsen, hay diferentes opiniones sobre esto.

Estoy muy de acuerdo con la filosofía Filter Input, Escape Output .

¿Sigue siendo necesario filter_input () si está utilizando consultas parametrizadas y htmlspecialchars () antes de imprimir los datos proporcionados por el usuario?

Respuesta corta: IMO, No. No es necesario, pero puede ser útil en algunos casos.

La función filter_input tiene muchos filtros útiles, y uso algunos de ellos (es decir, FILTER_VALIDATE_EMAIL). Los filtros de validación son útiles para validar la entrada. Sin embargo, IMO, los que transforman datos solo deben usarse en la salida.

Algunas personas fomentan la entrada de escape. De hecho, los ejemplos dados en la página del manual de filter_input parecen alentar esto también.

$search_html = filter_input(INPUT_GET, ''search'', FILTER_SANITIZE_SPECIAL_CHARS);
$search_url = filter_input(INPUT_GET, ''search'', FILTER_SANITIZE_ENCODED);

Los únicos ejemplos son para escapar . Eso combinado con el nombre de la función (filter_ input ) parece sugerir que escapar de la entrada es una buena práctica. El escape es necesario, pero, IMO, debe hacerse antes de la salida, no en la entrada. Al menos los valores de retorno se almacenan en variables con nombres apropiados.

Estoy totalmente en desacuerdo con la entrada de escape . Ya me he topado con situaciones del mundo real donde la transformación de datos demasiado pronto es un problema.

Por ejemplo, Google Analytics procesa la entrada de tal manera que está causando que se descodifiquen mis ampersands (% 26) codificados antes de que se excluyan los parámetros de consulta. El resultado es que tengo estadísticas para los parámetros de consulta que en realidad ni siquiera existen en mis URL. Vea mi pregunta sobre este problema que sigue sin resolverse.

También puede leer Por qué escapar de la entrada es una mala idea . Aquí hay algunos extractos con los que estoy de acuerdo, en caso de que el artículo desaparezca [énfasis en el original].

[...] escape-en-entrada es incorrecto [...] es una infracción de capas: mezcla un problema de formato de salida en el manejo de entrada. Las violaciones de capas hacen que su código sea mucho más difícil de entender y mantener, ya que debe tener en cuenta otras capas en lugar de dejar que cada componente y capa haga su propio trabajo.

y

Has corrompido tus datos por defecto. El sistema [...] ahora está mintiendo acerca de los datos que ingresaron.

y

El escape en la entrada no solo no solucionará los problemas de más de una salida, sino que también hará que sus datos sean incorrectos para muchas salidas.

y

PHP solía tener una característica llamada comillas mágicas. Fue una función de escape en la entrada que causó [...] todo tipo de problemas. [...] Según Lerdorf, la extensión mucho más reciente del ''filtro'' de PHP es "magic_quotes done right". Pero todavía sufre de casi todos los problemas descritos aquí.

Entonces, ¿cómo es mejor la extensión del filtro que las citas mágicas (aparte del hecho de que tiene muchos filtros diferentes)? Los filtros causan muchos de los mismos problemas que hicieron las citas mágicas.

Aquí están las convenciones de codificación que utilizo:

• los valores en $ _POST, $ _GET, $ _REQUEST, etc. no deben escaparse y siempre deben considerarse inseguros
• los valores deben validarse ¹ antes de escribirse en la base de datos o almacenarse en $ _SESSION
• los valores que se espera sean numéricos o booleanos deben ser desinfectados ² antes de ser escritos en la base de datos o almacenados en $ _SESSION
• confíe en que los valores numéricos y booleanos de la base de datos y $ _SESSION son de hecho numéricos o booleanos
• los valores de cadena deben ser escapados de SQL antes de ser utilizados directamente en cualquier consulta SQL (los valores que no sean de cadena deben ser saneados ² ) o usar declaraciones preparadas
• los valores de cadena deben escaparse de HTML antes de ser utilizados en la salida HTML (los valores que no sean de cadena deben ser desinfectados ² )
• los valores de cadena deben estar codificados en porcentaje antes de ser utilizados en cadenas de consulta (los valores que no sean de cadena deben ser desinfectados ² )
• use una convención de nomenclatura de variables (como * _url, * _html, * _sql) para almacenar datos transformados

Terminología

Para mis propósitos aquí, así es como defino los términos utilizados anteriormente.

1. validar los medios para confirmar cualquier suposición que se haga sobre los datos, como tener un formato específico o campos obligatorios que tengan un valor
2. para sanear los medios para confirmar que los valores son exactamente los esperados (es decir, $ id_num no debe contener más que dígitos)

Resumen

En general (puede haber algunas excepciones), recomendaría lo siguiente:

• usar filtros de validación en la entrada
• usar filtros de desinfección en la salida
• recuerde TIMTOWDI: por ejemplo, prefiero htmlspecialchars () (que tiene más opciones) en lugar de FILTER_SANITIZE_FULL_SPECIAL_CHARS o FILTER_SANITIZE_SPECIAL_CHARS (que escapa los saltos de línea)