Pregunta

Estoy analizando cómo escapar de forma adecuada los datos que provienen del mundo exterior antes de que se utilicen para el control de aplicaciones, el almacenamiento, la lógica ... ese tipo de cosas.

Obviamente, con la directiva de comillas mágicas en desuso en breve en php 5.3.0+, y eliminada en php6, esto se vuelve más apremiante para cualquiera que busque actualizar y acceder a las nuevas características de idioma, mientras mantiene el código heredado (no Nos encanta ...).

Sin embargo, una cosa que no he visto es mucha discusión sobre teoría / mejores prácticas con qué hacer una vez que haya protegido sus datos, por ejemplo, para almacenar con o sin barras diagonales. Personalmente, creo que mantener los datos escapados en la base de datos es una mala decisión, pero quiero escuchar el debate y leer algunos estudios de caso de manera preferible ...

Algunos enlaces del manual de PHP solo para referencia:

Manual de PHP - mysql_real_escape_string

Manual de PHP - htmlspecialchars

etc. etc.

¿Algún consejo?

¿Fue útil?

Solución

Echa un vistazo a las declaraciones preparadas. Sé que en mysql esto funciona muy bien y es una forma segura de obtener datos en su base de datos. También tiene algunos beneficios de rendimiento.

http://dev.mysql.com/tech -resources / articles / 4.1 / prepared-statement.html

Tengo algunos recursos más si está interesado.

Espero que esto sea lo que está buscando, tc.

Editar:

Una cosa que puedo agregar es usar filtros en combinación con declaraciones preparadas. Por ejemplo, para verificar si el valor es una picadura, use FILTER_SANITIZE_STRING, o para el correo electrónico que usa FILTER_SANITIZE_EMAIL.

Esto guarda cierta cantidad de código y funciona muy bien. Después, siempre puede verificar los datos utilizando sus propios métodos, pero hay muchos filtros que puede usar.

Otros consejos

  • Use el método correcto de escape de datos al ejecutar consultas: mysql_real_escape_string, consultas preparadas, etc ...

  • Almacenar datos en la base de datos sin alterar

  • Use el método correcto para escapar los datos en la salida: htmlspecialchars, etc.

Para el trabajo de la base de datos, verifique las consultas parametrizadas y las declaraciones preparadas. DOP y mysqli son buenos para eso.

Htmlspecialchars es la herramienta adecuada para mostrar texto en html documentos.

Y, como mencionó php 5.3, tiene acceso a las funciones de filtro que son un uso obligatorio cuando se manejan datos de usuario.

Para inserciones en la base de datos, la solución es utilizar variables de enlace .

En general, cada vez que se le escapa algo (argumento a un comando de shell, pieza de comando db, html proporcionado por el usuario, etc.), indica que no está utilizando la llamada de función correcta (por ejemplo, utilizando < code> system cuando podría usar una forma multi-arg de exec ), o que su marco es deficiente. El enfoque estándar para trabajar en un marco deficiente es mejorarlo para que pueda volver a no pensar en cotizar.

Pensar en los niveles de escape y en los niveles de cotización puede ser divertido, pero si realmente disfrutas, juega con Tcl en tu tiempo libre. Para un trabajo real, no debe pensar en citar a menos que esté diseñando una biblioteca para que la usen otras personas, en cuyo caso debe citar correctamente y dejar que sus usuarios eviten pensar en citar. (Y debe documentar con mucho cuidado exactamente qué tipo de cita hace y no hace)

Es simple. TODOS los datos entrantes se deben ejecutar a través de mysql_real_escape_string () antes de insertarlo en la base de datos. Si sabe que algo debe ser un entero, por ejemplo, configúrelo en un entero antes de insertarlo, etc. Recuerde que esto es solo para detener la inyección de SQL. XSS y la validación de datos son diferentes.

Si quiere que algo sea un correo electrónico, obviamente necesita validarlo antes de insertarlo en la base de datos.

htmlentities () limpia los datos, lo que significa que modifica los datos. Creo que siempre deberías almacenar datos en bruto en la base de datos y cuando tomes esos datos, elige cómo quieres sanearlos.

Me gusta usar la siguiente función como " envoltura " para la función mysql_real_escape_string () .

function someFunction( $value )
{
    if ( is_int( $value ) || is_float( $value ) ) {
        return $value;
    }
    return "'" . mysql_real_escape_string( (string) $value ) . "'";
}

Si el valor es un valor flotante o un entero, no tiene sentido ejecutar mysql_real_escape_string () . La razón por la que asigno el valor a una cadena antes de pasarlo a mysql_real_escape_string () , es porque a veces el valor podría no ser una cadena.

Un ejemplo de que el valor no es una cadena:

http: //localhost/test.php? hello [] = prueba

Dentro de test.php, usted ejecuta mysql_real_escape_string () en $ _GET ['hola'] hola para ser una cuerda Bueno, dado que la persona estableció el valor en una matriz, en realidad causará un aviso ya que hola no es una cadena.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top