Seguridad de Bases de Datos

Seguridad de Bases de Datos
Table of Contents

* 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 estos 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.


Conexión con la Base de Datos> <Seguridad del sistema de archivos Last updated: Fri, 22 Aug 2008

add a note add a note User Contributed Notes
Seguridad de Bases de Datos
ja4chem at yahoo dot co dot uk
17-Jan-2008 07:37
SQL injection could be prevented by inserting only base64_encoded data into the data base. Before searching the data base for a certain value or string base64_encode the search string and then start the query.
Dave Martin
16-Aug-2007 12:15
The posting below is at the very best extremely POV.

There is no more reason to assume you would want to change database vendor than there is to assume you might want to port your php code to Java for example. In either case, its going to be a matter of luck where your business rules sit.

Even if your business rules sit in your application, SQL is NOT portable. Oracle outer joins and pivot queries for example, can look completely different to those in other vendors software (particularly from 8i or lower). This fact alone means that changing your DB vendor requires work on your business rules either in the database or in the application.

Having your rules in the database and keeping the sql in application simple, will at least keep the work in the database if you need to change DB vendor. If you have the rules in the PHP, you'll have to change both.
x12code at yahoo dot com
14-Aug-2007 09:48
About offloading business logic to views and queries facilitated by the database engine, I seek to avoid this as much as possible, and only do so when such would drastically improve efficiency and user response time.

For instance, where I am there is database staff and application staff. Trying to do analysis on existent applications can easily become a snipe hunt.

The database should be kept discreet as much as possible from the application, such that any database or database provider can easily be substituted with a minimum of cognitive effort on the part of the one setting up a new database. If functionality has been offloaded to the database, additional testing is required to make sure triggers and views were done correctly, again, and that they work right.

Also, keeping all business logic with the application allows all functionality and documentation to be readable in one place, which is invaluable when doing subsequent analysis on an existing application. The worst thing is to have functionality scattered here and there.

Keeping everything with the application means one group of people is responsible, as in my case, application staff. Fewer requests go back and forth. Remember, anytime someone else is brought into the picture, such as asking a DBA to create a view or trigger for you, that DBA must take responsibility over his or her work, with whatever requirements, causing more bureaucracy and administrative complexity.
me at meme dot com
28-Jun-2007 12:23
<?php
$getal1 = 5.5;
$getal2 = 2.0;

function printDeling() {
$resultaat = global $getal1 / global $getal2;
return $resultaat;
}
function printVermenigvuldiging() {
$resultaat = global $getal1 * global $getal2;
return $resultaat;
}
function printSom() {
$resultaat = global $getal1 + global $getal2;
return $resultaat;
}
function printAftrekking() {
$resultaat = global $getal1 - global $getal2;
return $resultaat;
}

(printDeling()>=7) ? print "<font color=\"green\"> printDeling()</font>" : print "<font color=\"red\"> printDeling()</font>" ;
?>
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 add a note

Conexión con la Base de Datos> <Seguridad del sistema de archivos Last updated: Fri, 22 Aug 2008