Seguridad

[davidMS]

Hola a todos.

Hoy estoy un poco intrigado, por lo que es la seguridad en las aplicaciones despues de leer un documento donde explican como una base de datos fue hackeada con un "SQL INJECTION" en un espacio de comentario.
Una de las medidas que he tomado es por deshabilitar la opcion de register_globals en el php.ini. Esto para estar seguro de donde provienen las variables, usando los super arraglos $_POST, $_SERVER, etc. Ademas estoy comprobando los campos de los formularios que son agregados al sql query que en un principio de origen son "strings" pasandolos a integer con settype. Pero tengo una duda, como puedo filtrar los campos que son tipo texto que se van a utilizar en un sql query, he heco un mecanismo para que filtre ciertas palabras como select *, o flush, insert, update..ect, pero no lo veo como muy efectivo, hay alguna otra forma de filtrar esto.
Ademas me gustaria comenzar a utilizar el php en "safe_mode" y utilizar un certificado de seguridad "ssl". Hay algo que tengo que tomar en cuenta a la hora de programar, quiero decir hay algo que varia, digamos declaracion de variables o algo por el estilo?

de antemano muchas gracias

[josemi]

Hola,

No es que tengas que filtrar esas palabras "peligrosas", solo tienes que hacer que todo lo que metas en la consulta sea "inofensivo".

Por ejemplo, si un campo de texto lo tienes que usar en una consulta, asegurate de meterlo como una cadena de texto valida para sql. Todas las bases de datos tienen reglas de validacion para sus tipos de datos en sus consultas. Por ejemplo, en MySQL el caracter "peligroso" es ':

SELECT * FROM usuarios WHERE usuario='$_POST[usuario]' AND clave='$_POST[clave]'

Parece seguro, ¿verdad? Pero si $_POST[clave]=' OR '1'='1 , tendriamos

SELECT * FROM usuarios WHERE usuario='usuario' AND clave='' OR '1'='1'

Si la validacion de usuario se basa en que esa consulta devuelva un numero de registros distinto de 0, pues ya la hemos liado.

El "truco" es "desactivar" las ' del contenido de $_POST[clave] con mysql_escape_string() (www.php.net/mysql_escape_string).

Y la maxima siempre es nunca fiarse de lo que llega al script desde el lado del cliente. Ni las cabeceras HTTP, ni los datos de un formulario validado con javascript, ni el ID de sesion, ni el contenido de un fichero, ni unas cookies, nada absolutamente nada del lado del cliente esta a salvo de una simple manipulacion.

Y otro consejo: al enemigo ni agua. Traduccion: en entorno de produccion, nada de mensajes de error que muestren las "tripas" de la aplicacion. Asi que error_reporting a cero, el mysql_error() nada en el navegador. Nada que sirva de pista al enemigo.

Saludos.