Resumiendo, para asegurarnos de que nuestra base de datos no está expuesta a los datos que proceden de los formularios:
- (evidentemente) nunca pasar datos de un formulario a la base de datos que no han sido verificados previamente
- si estáis utilizando MySQL utilizar mysql_escape_string o mysql_real_escape para “escapar” una cadena utilizada en mysql_query, lo último coge el identificador de conexión y “escapa” la cadena de acuerdo con el código actual de caracteres
Si estáis usando PEAR habría que invocar el método DB:quote -en caso de que sea ADOdb es el mismo método que es compatible con PEAR- para limpiar vuestros datos.
También seria conveniente que echarais un vistazo a las siguientes directrices del manual de MySQL, se puede hacer una observación general aplicable a otras bases de datos pero prestar atención a las excepciones (mirar las observaciones).
Cuando MySQL este funcionando, seguir las siguientes pautas siempre que sea posible:
- No fiaros de ningún dato que otro usuario haya introducido. Podrían tratar de engañar a vuestro código introduciendo secuencias de caracteres especiales o “escapeados” en formularios web, o cualquier otra aplicación que hubierais costruido. Aseguraros de que vuestra aplicación sigue siendo segura si un usuario introduce algo como "DROP DATABASE mysql;”. Este es un ejemplo extremo, pero pueden darse importantes agüjeros de seguridad y pérdida de datos si los hackers utilizan sistemas como este, si no estais preparado para esto. También recordar los datos de tipo numérico. Un error común es proteger sólo las cadenas. Algunas veces, la gente piensa que si una base de datos contiene sólo datos accesibles públicamente no necesita ser protegida. Esto es incorrecto. Como mínimo debe hacerse una denegación de servicio en caso de ataque en ese tipo de bases de datos. El método más simple para protegerla de este tipo de ataques es utilizar apóstrofes a ambos lados de las constantes numéricas: SELECT * FROM table WHERE ID=’234′ mejor que SELECT * FROM table WHERE ID=234 -aquí debemos hacer una observación, bases de datos como ORACLE no soportan esto y devolverán un error debido a la no coincidencia del dato con el tipo de campo. En MySQL funcionará bien, ya que convierte de forma automática esta cadena a un número y elimina todos los elementos no numéricos.
Puntos: - Todas las aplicaciones web:
- Probad a introducir ‘ y ” en todos los formularios. Si os devuelve cualquier tipo de error de MySQL, investigar cual es el problema.
- Tratar de modificar cualquier URL dinámica añadiendo %22 (“), %23 (#), y %27 (‘) en el URL.
- Probad a modificar los tipos de datos en los URLs dinámicos, por ejemplo uno numérico a uno de tipo carácter incluyendo caracteres de los ejemplos anteriores. Vuestra aplicación debería ser segura frente a este y otro tipo de ataques similares.
- Tratar de introducir caracteres, espacios y otros símbolos especiales en vez de números en los campos numéricos. Vuestra apliación debería eliminarlos antes de pasarlos a MySQL o bien generar un error. ¡Pasar valores no chequeados a MySQL es muy peligroso!.
- Comprobad el tamaño de los datos antes de que lleguen a MySQL
- Considerar el tener vuestra apliación conectada a la base de datos utilizando un nombre de usuario distinto del que utilizais para administrar la base. No deis más privilegios de acceso a vuestra aplicación que aquellos que realmente son precisos.
- Los usuarios de PHP:
- Utilizar la función addslashes(). Desde PHP 4.0.3, está disponible una función, mysql_escape_string(), que está basada en la función del mismo nombre en el API C de MySQL.