CapÃtulo 27. Seguridad de Bases de Datos

Tabla de contenidos
DiseÃ±o de Bases de Datos
ConexiÃ³n con la Base de Datos
Modelo de Almacenamiento Encriptado
InyecciÃ³n de SQL

Hoy en dÃa, las bases de datos son componentes cardinales de cualquier aplicaciÃ³n basada en web, permitiendo que los sitios web provean contenido dinÃ¡mico. Debido a que informaciÃ³n considerablemente sensible o secreta puede ser almacenada en una base de datos, usted debe considerar seriamente la protecciÃ³n de sus bases de datos.

Para recuperar o almacenar cualquier informaciÃ³n necesita conectarse a la base de datos, enviar una consulta vÃ¡lida, recoger el resultado y cerrar la conexiÃ³n. Hoy en dÃa, el lenguaje de consultas usado comÃºnmente en estas interacciones es el Lenguaje de Consultas Estructurado (SQL por sus siglas en InglÃ©s). Puede apreciar cÃ³mo un atacante puede intentar acometidas con una consulta SQL.

Como puede suponer, PHP no puede proteger su base de datos por sÃ solo. Las siguientes secciones estÃ¡n dirigidas a servir de introducciÃ³n a los conceptos bÃ¡sicos de cÃ³mo acceder y manipular bases de datos desde scripts PHP.

Mantenga en mente esta simple regla: protecciÃ³n en profundidad. Entre mÃ¡s acciones tome para incrementar la protecciÃ³n de su base de datos, menor serÃ¡ la probabilidad de que un atacante tenga Ã©xito exponiendo o abusando de cualquier informaciÃ³n almacenada. Un buen diseÃ±o del esquema de la base de datos y de la aplicaciÃ³n basta para lidiar con sus mayores temores.

DiseÃ±o de Bases de Datos

El primer paso siempre es crear la base de datos, a menos que desee usar una creada por alguien mÃ¡s. Cuando una base de datos es creada, Ã©sta es asignada a un dueÃ±o, quien ejecutÃ³ la sentencia de creaciÃ³n. Usualmente, Ãºnicamente el dueÃ±o (o un super-usuario) puede hacer cualquier cosa con los objetos de esa base de datos, y para que otros usuarios puedan usarla, deben otorgarse privilegios.

Las aplicaciones nunca deberÃan conectarse a la base de datos bajo el usuario correspondiente a su dueÃ±o, o como un super-usuario, ya que Ã©stos usuarios pueden, por ejemplo, ejecutar cualquier consulta a su antojo, modificando el esquema (p. ej. eliminando tablas) o borrando su contenido completo.

Usted puede crear diferentes usuarios de la base de datos para cada aspecto de su aplicaciÃ³n con derechos muy limitados sobre los objetos de la base de datos. Tan solo deben otorgarse los privilegios estrictamente necesarios, y evitar que el mismo usuario pueda interactuar con la base de datos en diferentes casos de uso. Esto quiere decir que si un intruso gana acceso a su base de datos usando las credenciales de sus aplicaciones, Ã©l solo puede efectuar tantos cambios como su aplicaciÃ³n se lo permita.

Es buena idea que no implemente toda la lÃ³gica del asunto en la aplicaciÃ³n web (es decir, en su script); en su lugar, hÃ¡galo en el esquema de la base de datos usando vistas, disparadores o reglas. Si el sistema evoluciona, se espera que nuevos puertos sean abiertos a la aplicaciÃ³n, y tendrÃ¡ que re-implementar la lÃ³gica para cada cliente de la base de datos. Por sobre todo, los disparadores pueden ser usados para gestionar de forma transparente todos los campos automÃ¡ticamente, lo cual con frecuencia provee informaciÃ³n Ãºtil cuando se depuren problemas de su aplicaciÃ³n, o se realicen rastreos sobre transacciones particulares.

add a note User Contributed Notes
Seguridad de Bases de Datos

somebody at whocares dot com
10-May-2006 09:03


Encrypting user input doesn't do much to guard against SQL injection attacks.  Naturally, you want to encrypt sensitive information across the wire, but if a user puts in malicious data into an input field, any encryption scheme will just dutifully unpack it at the other and and still run the SQL injection hack if you haven't guarded against it.



Encryption is not magic pixie dust to sprinkle on things to make them more secure.

30-Jun-2005 03:57


you can also chamge CHMOD for some file containing "user names" or "passwords"

webmaster at rackhouse dot net
12-Mar-2005 02:08


On a database design point of view, you should make sure that you design databases in a manor that any query run from them need minimal input from the user and if it requires user input, that you encrypt where possible.

jjahn at SPAMSUCKS dot signicast dot com
20-Jun-2003 10:17


I would say one of the best ways to guard against SQL injection is to use the excellent PEAR DB package. If you prepare() and execute() your queries, PEAR will automagically addslashes and handle the query depending on your RDBMS. And of course, for repeatable queries prepare and execute will give you a bit of a readability and speed increase.

add a note