2010-11-18 8 views
10

He leído esto antes de "entrada de filtro, salida de escape" pero ¿es la entrada de filtrado realmente necesaria cuando uso PDO con PHP? Pensé que con PDO no necesito filtrar la entrada porque la declaración preparada se ocupa de las inyecciones sql. Creo que la "salida de escape" sigue siendo válida, pero ¿la "entrada de filtro" sigue siendo válida?Es "entrada de filtro, salida de escape" aún válida con PDO

Respuesta

9

Sí, sigue siendo válido.

Filtrar no se trata de prevenir las vulnerabilidades de seguridad, se trata de no poblar su base de datos con basura. Si está esperando una fecha, asegúrese de que al menos se parece a una fecha anterior a su almacenamiento.

El resultado del escape consiste en prevenir las vulnerabilidades de seguridad (es decir, XSS o Cross Site Scripting).

Así que sí, ambos son muy importantes y son totalmente ajenos a la inyección de SQL (aunque un buen número de desarrolladores todavía confundir con el filtrado de escape para las consultas SQL y por lo tanto todavía puede ser objeto de vulnerabilidades) ...

+2

"El filtrado no se trata de prevenir las vulnerabilidades de seguridad". Esto no puede ser exagerado. –

+0

@ ircmaxell y @JW, entonces ¿me equivoco al pensar que la entrada de filtrado es en parte para evitar la inyección de sql? ¿Estás diciendo que son 2 problemas separados? – sami

+1

@sami: absolutamente. No es necesario filtrar para evitar las inyecciones (de hecho, si es así, es probable que no funcione en todos los casos), y no es necesario evitar que las inyecciones se filtren. No son mutuamente inclusivos (aunque el filtrado agresivo PUEDE prevenir las inyecciones, no es para lo que está destinado) ... – ircmaxell

3

Dependiendo de la información que guarde, sí puede ser válida.

Por ejemplo, supongamos que tiene un cuadro de comentario y un usuario escribe un mensaje que contiene código HTML. En este caso, a menudo desearía eliminar dicha marca HTML del texto del comentario, incluso si terminó siendo escapado (después de todo, probablemente no se verá muy bien).

También existen otros casos, como si tiene un campo de número de teléfono, es posible que desee filtrarlo para que esté en el formato específico que su aplicación utiliza y así sucesivamente.

3

Siempre filtre la entrada del usuario. Siempre. Tal vez esté protegiendo contra ataques, o tal vez esté realizando validación de reglas comerciales, etc. Tenga en cuenta que no existe una tecnología o procedimiento que prevenga todos los ataques, solo ataques específicamente diseñados para evitarlos. La inyección SQL no es el único problema para evitar.

+0

¿Podría darme una idea de lo que quiere decir "la inyección SQL no es el único problema". Entiendo que necesito escapar de la salida, pero para la entrada, ¿qué otra cosa hay aparte de la inyección SQL realmente? No pensé nada. – sami

+1

@sami: Depende mucho de lo que está haciendo y cómo lo está haciendo, pero la entrada de los usuarios en los sistemas en general puede estar sujeta a cosas como ataques de desbordamiento de búfer u otras cosas que el desarrollador ni siquiera puede pensar, pero la plataforma en sí misma puede no estar equipada para manejar apropiadamente. Es raro, pero la regla general sigue siendo. Nunca confíes en lo que un usuario envía al sistema. – David

1

Según la inyección de sql y la seguridad, si está utilizando PDO correctamente con variables de vinculación, no, no es necesario desinfectar. Pero como Jani señaló, dependiendo de los datos que está guardando, como un campo de texto que no permite html, es posible que desee desinfectar sus datos, o si el campo debe ser un número, ejecutar parseInt() en él o alguna cosa. Pero esto no va a ser necesario para la seguridad, sino para la cordura de tu propia base de datos. Es algo feo cuando alguien intenta poner html en un comentario y lo escupe y ve > < etc.

+0

al escupir desde la base de datos, esa es la parte de "salida de escape", ¿verdad? – sami

+1

Sí, tradicionalmente usando htmlspecialchars(); – superfro

0

Sí , está escapando de entrada, pero no inmediatamente como magic_quotes_gpc. Citas mágicas es un horrible enfoque de seguridad. Las vulnerabilidades dependen en gran medida de cómo se usen los datos contaminados, nunca se puede tener una función que corrija todo todo el tiempo. También durante el flujo de la aplicación puede haber un caso cuando otra función socava magic_quotes, como stripslashes(), base64_decode(), urldecode(), htmlspecialchars_decode($var,ENT_QUOTES); e incluso substr().

En resumen, siempre debe escapar la entrada en el momento del uso. pdo y adodb hacen esto, y lo hace perfectamente.

Cuestiones relacionadas