Hoy en día, las bases de datos son componentes esenciales de cualquier aplicación web, permitiendo a los sitios web proveer variedad de contenido dinámico. Puesto que se puede almacenar información muy sensible o secreta en una base de datos, debería considerarse ampliamente la protección de las bases de datos. Para obtener o almacenar cualquier información, es necesario conectarse a la base de datos, enviar una consulta válida, obtener el resultado, y cerrar la conexión. Hoy en día, el lenguaje de consultas más utilizado en esta interacción es el Lenguaje Estructurado de Consultas (SQL, por sus siglas en inglés). Vea como un atacante puede realizar manipulaciones maliciosas con una consulta SQL. Como es de suponer, PHP no puede proteger una base de datos por sí mismo. Las siguientes secciones tienen como objetivo ser una introducción básica de cómo acceder y manipular bases de datos dentro de scripts de PHP. Tenga en mente esta sencilla regla: Protección en profundidad. En cuantos más sitios se tomen acciones para aumentar la protección de una base de datos, menor es la probabilidad de que un atacante tenga éxito en exponer o abusar de cualquier información que tenga almacenada. Un buen diseño del esquema de la base de datos y de la aplicación se ocupará de sus mayores temores. El primer paso es siempre crear una base de datos, a menos que se quiera utilizar una de un tercero. Cuando se crea una base de datos, esta es asignada a un propietario, aquel que ejecutó la sentencia de creación. Usualmente, sólo el propietario (o un superusuario) puede hacer cualquier cosa con los objetos de esa base de datos. Para que otros usuarios puedan utilizarla, se les deben conceder privilegios. Las aplicaciones nunca deberían conectarse a la base de datos como su propietario o como un superusuario, porque estos usuarios pueden ejecutar cualquier consulta a su antojo; por ejemplo, modificar el esquema (p.ej., eliminar tablas) o borrar su contenido por completo. Se pueden crear distintos usuarios de una base de datos para cada aspecto de la aplicación con permisos muy limitados a los objetos de dicha base de datos. Solamente deberían otorgarse los privilegios necesarios, evitando así que el mismo usuario pueda interactuar con la base de datos en diferentes casos y uso. Esto significa que si un intruso obtiene acceso a una base de datos utilizando las credenciales de la aplicación, solamente puede efectuar los cambios que la aplicación permita. Se recomienda no implementar toda la lógica de negocio en la aplicación web (esto es, en los scripts); se ha de hacer en su lugar en el esquema de la base de datos utilizando vistas, disparadores o reglas. Si el sistema evoluciona, se tendrá por objeto abrir nuevos puertos a la base de datos, teniendo así que reimplementar la lógica en cada cliente de la base de datos por separado. Además, los disparadores se pueden utilizar para manejar campos de forma transparente y automática, lo que a menudo ayuda en la depuración de problemas con la aplicación o en el seguimiento de transacciones. Se pueden establecer las conexiones sobre SSL para encriptar las comunicaciones cliente/servidor y aumentar la seguridad, o también emplear ssh para encriptar la conexión de red entre los clientes y el servidor de bases de datos. Si se utiliza algunas de estas opciones, será difícil para un posible atacante la monitorización del tráfico y la obtención de información de la base de datos. SSL/SSH protege los datos que viajan desde el cliente al servidor: SSL/SSH no protege los datos persistentes almacenados en una base de datos. SSL es un protocolo que protege los datos mientras viajan por el cable. Una vez que un atacante obtiene acceso directo a una base de datos (eludiendo el servidor web), los datos sensibles almacenados podrían ser divulgados o mal utilizados, a menos que la información esté protegida por la base de datos misma. Encriptar los datos es una buena forma de mitigar esta amenaza, pero muy pocas bases de datos ofrecen este tipo de encriptación de datos. La forma más sencilla para evitar este problema es crear primero un paquete de encriptación propio y utilizarlo en los scripts de PHP. Hay muchas extensiones de PHP que pueden ser de ayuda para esto, tales como Mcrypt y Mhash, cubriendo así una amplia variedad de algoritmos de encriptación. El script encripta los datos antes de insertarlos en la base de datos, y los desencripta al obtenerlos. Véanse las referencias para ejemplos adicionales del funcionamiento de la encriptación. En caso de datos que deban estar realmente ocultos, si no fuera necesaria su representación real, (es decir, que no sean mostrados), quizás convenga utilizar algoritmos hash. El ejemplo más típico del uso del hash es a la hora de almacenar el hash criptográfico de una contraseña en una base de datos, en lugar de almacenar la contraseña en sí. Véase también crypt. ]]> Muchos desarrolladores web no son conscientes de cómo las consultas SQL pueden ser manipuladas, y asumen que una consulta SQL es una orden fiable. Esto significa que las consultas SQL son capaces de eludir controles de acceso, evitando así las comprobaciones de autenticación y autorización estándar, e incluso algunas veces, que las consultas SQL podrían permitir el acceso a comandos al nivel del sistema operativo del equipo anfitrión. La inyección directa de comandos SQL es una técnica donde un atacante crea o altera comandos SQL existentes para exponer datos ocultos, sobrescribir los valiosos, o peor aún, ejecutar comandos peligrosos a nivel de sistema en el equipo que hospeda la base de datos. Esto se logra a través de la práctica de tomar la entrada del usuario y combinarla con parámetros estáticos para elaborar una consulta SQL. Los siguientes ejemplos están basados en historias reales, desafortunadamente. Debido a la falta de validación en la entrada de datos y a la conexión a la base de datos con privilegios de superusuario o de alguien con privilegios para crear usuarios, el atacante podría crear un superusuario en la base de datos. ]]> Un usuario común hace clic en los enlaces 'siguiente' o 'atrás' donde el $índice está codificado en el URL. El script espera que el $índice entrante sea un número décimal. Sin embargo, ¿qué pasa si alguien intenta irrumpir anteponiendo a la URL algo como lo siguiente empleando urlencode? Si esto sucediera, el script podría otrogar un acceso de superusuario al atacante. Observe que 0; es para proveer un índcie válido a la consulta original y así finalizarla. Es una técnica común forzar al analizador de SQL a ignorar el resto de la consulta escrita por el desarrollador con --, lo cual representa un comentario en SQL. Una forma factible de obtener contraseñas es burlar las páginas de búsqueda de resultados. Lo único que el atacante necesita hacer es ver si hay variables que hayan sido enviadas y sean empleadas en sentencias SQL que no sean manejadas apropiadamente. Estos filtros se pueden establecer comunmente en un formulario anterior para personalizar las cláusulas WHERE, ORDER BY, LIMIT y OFFSET en las sentencias SELECT. Si la base de datos admite el constructor UNION, el atacante podría intentar anteponer una consulta entera a la consulta original para enumerar las contraseñas de una tabla arbitraria. Se recomienda encarecidamente utilizar campos de contraseña encriptadas. ]]> La parte estática de la consulta se puede combinar con otra sentencia SELECT la cual revelará todas las contraseñas: Si esta consulta (jugando con ' y --) fuera asignada a una de las variables utilizadas en $consulta, despertaría a la consulta "monstruo". Las sentecias UPDATE de SQL también son susceptibles a ataques. Estas consultas también están amenazadas por el corte y la anteposición de una consulta completamente nueva. El atacante podría juguetear con la cláusula SET, aunque en este caso, debe poseer algo de información sobre los esquemas para manipular la consulta con éxito. Esta información puede adquirirse examinando los nombres de las variables del formulario, o sencillamente mediante la fuerza bruta. No hay muchas convenciones de nombres para campos que almacenen contraseñas o nombres de usuarios. ]]> Pero un usuario malicioso podría enviar el valor ' or uid like'%admin% a $uid para cambiar la contraseña del administrador, o simplemente cambiar $pwd a jejeje', trusted=100, admin='yes para obtener más privilegios. Entonces, la consulta se tornaría: ]]> Un ejemplo turbador de cómo se puede acceder a los comandos a nivel del sistema operativo en algunos equipos anfitriones de bases de datos. ]]> Si un atacante envía el valor a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- a $prod, la $consulta será: ]]> El servidor MSSQL ejecuta la sentencia SQL en el lote incluyendo un comando para añadir un usuario nuevo a la base de datos de cuentas local. Si esta aplicación estuviera ejecutándose como sa y el servicio MSSQLSERVER se estuviera ejecutando con los privilegios suficientes, el atacante ahora podría tener una cuenta con la cual acceder a esta máquina. Algunos de los ejemplos citados están vinculados a un servidor de bases de datos específico. Esto no significa que un ataque similar sea imposible en otros productos. Su servidor de base de datos también podría ser vulnerable de otra manera. Un ejemplo comprobado de los problemas con respecto a las inyecciones de SQL Imagen cortesía de xkcd Pese a que pueda parecer obvio que un atacante debe tener al menos algún conocimiento de arquitecturas de bases de datos para poder realizar un ataque con éxito, la obtención de esta información suele ser muy sencilla. Por ejemplo, cuando la base de datos forma parte de un software de código abierto o disponible públicamente con una instalación predefinida, dicha información se encuentra completamente libre y utilizable. Esta información podría haber sido divulgada en proyectos de código cerrado (incluso si está codificada, ofuscada o compilada), o incluso por el propio código mediante la visualización de mensajes de error. Otros métodos incluyen el uso de nombres frecuentes de tablas y columnas. Por ejemplo, un formulario de inicio de sesión que utiliza una tabla 'usuarios' con los nombres de columna 'id', 'username', y 'password'. Estos ataques se basan principalmente en explotar el código que no ha sido escrito teniendo en cuenta la seguridad. Nunca se ha de confiar en ningún tipo de entrada, especialmente la que viene del lado del cliente, aún cuando esta venga de un cuadro de selección, un campo oculto o una cookie. El primer ejemplo muestra cómo una inofensiva consulta puede causar desastres. Nunca se conecte como superusuario o como propietario de la base de datos. Siempre utilice usuarios personalizados con privilegios muy limitados. Emplee sentencias preparadas con variables vinculadas. Son proporcionadas por PDO, MySQLi y otras bibliotecas. Compruebe si la entrada proporcionada tiene el tipo de datos previsto. PHP tiene un amplio rango de funciones para validar la entrada de datos, desde las más simples, encontradas en Funciones de variables y en Funciones del tipo carácter (p.ej., is_numeric, ctype_digit respectivamente), hasta el soporte para Expresiones regulares compatibles con Perl. Si la expresión espera una entrada numérica, considere verificar los datos con la función ctype_digit, o silenciosamente cambie su tipo utilizando settype, o emplee su representación numérica por medio de sprintf. ]]> Si la capa de la base de datos no admite variables vinculadas, entrecomille cada valor no numérico proporcionado por el usuario que sea pasado a la base de datos con la función de escapado de cadenas específica de la base de datos (p.ej. mysql_real_escape_string, sqlite_escape_string, etc.). Las funciones genéricas como addslashes son útiles solamente en un entorno muy específico (p.ej., MySQL en un juego de caracteres monobyte con NO_BACKSLASH_ESCAPES deshabilitada), por lo que es mejor evitarlas. Sea como sea, no muestre ninguna información específica de la base de datos, especialmente sobre el esquema. Vea también Notificación de errores y Manejo de errores y funciones de registro. Su pueden utilizar procedimientos almacenados y cursores previamente definidos para abstraer el acceso a datos para que los usuarios no tengan acceso directo a las tablas o vistas, aunque que esta solución tiene otros impactos. Además, se puede beneficiar del registro de consultas, ya sea dentro de un script o mediante la base de datos en sí misma, si es que lo soporta. Obviamente, llevar un registro no previene los intentos dañinos, aunque puede ser útil para realizar un seguimiento de las aplicación que han sido eludidas. El registro no es útil por sí mismo, sino por la información que contiene. Normalmente cuantos más detalles, mejor.