El SQL Server se instala en
Windows 2000 como un servicio y por tanto es necesario asignar un usuario para
que inicie ese servicio y para que el SQL Server trabaje en ese contexto de
seguridad. Este usuario que asignaremos a los servicios SQL Server y SQL Server
Agent (habitualmente se utiliza el mismo para los dos servicios) puede ser o
bien la cuenta local del sistema o una cuenta del dominio asignada por nosotros.

Por norma general escogeremos la segunda de las opciones y crearemos una cuenta
en el dominio especialmente dedicada a los servicios de SQL Server, porque sólo
de esta manera el SQL Server podrá acceder a archivos de otros equipos,
planear trabajos entre varios servidores, realizar copias de seguridad en ubicaciones
de red, mandar notificaciones mediante email, hacer modificaciones en el registro…

La cuenta que vamos a crear en el dominio para el SQL Server deberá tener
las siguientes características:
• Miembro del grupo local administradores,

• Activado el atributo “La contraseña no caduca nunca”,
• Permitido el inicio de sesión a todas las horas,
• Permitido iniciar sesión como servicio.

Además de esto necesitaremos una cuenta en el servidor de correo Exchange si queremos
que el SQL Server Agent pueda comunicarse con nosotros a través del correo
para enviarnos avisos, notificaciones, alertas…

Los usuarios:

En SQL Server 2000 los usuarios
pueden ser de dos tipos dependiendo del modelo de seguridad elegido. Usuarios
de Windows, creados en el dominio y administrados desde la herramienta “usuarios
y equipos del dominio”, y usuarios propios de SQL Server. Para utilizar
estos últimos usuarios es necesario configurar el servidor SQL en modo
de autentificación mixto.

La mejor manera de gestionar la seguridad es utilizando usuarios de Windows
porque es la única manera de poder asignar directivas de seguridad a
las cuentas de los usuarios. Así podemos por ejemplo establecer caducidades
para las contraseñas, establecer un mínimo de longitud, detectar
intentos de acceso ilegales…

Estos usuario que creamos en el dominio no tienen necesidad de ningún
privilegio extra en el dominio (además de ser usuarios del dominio) y
los permisos que tienen en el SQL Server se administran desde dentro del propio
SQL Server.

El administrador:

Para poder manejar todos estos
elementos de seguridad es necesaria la figura del administrador.
En el SQL Server se pueden definir fácilmente uno o varios administradores
que lleven a cabo las tareas necesarias para el correcto funcionamiento del
servidor. Pero hay tareas de configuración del servidor y de gestión
de usuarios que tienen que ser realizadas por un usuario que tenga ciertas características:

• Poder crear y modificar cuentas de usuarios,
• Tener acceso a las claves del registro del servidor donde este
instalado el SQL Server,
• Tener acceso total al sistema de archivos del equipo donde está
instalado el SQL Server,
• Tener privilegios para poder iniciar y detener los servicios SQL
Server, SQL Server Agent, Servicio Microsoft Search,
• Poder acceder a los registros de equipos clientes (si se van a
utilizar controladores ODBC),

• Poder leer y buscar a través del visor de sucesos del servidor,
• Poder utilizar el monitor del sistema y crear registros de log
de cualquier tipo de contador,
• Instalar y reparar el software del SQL Server,
• Realizar copias de seguridad en dispositivos externos.

Por
tanto deberíamos crear una cuenta específica para la administración
de SQL Server que tuviera todos estos privilegios. Lo más sencillo y
seguro será crear un usuario perteneciente al grupo de Administradores
del Dominio encargado de realizar estas tareas. En su defecto basta con crear
un usuario normal y asignarle estos derechos y permisos (o asignar dichos derechos
y permisos a un usuario ya existente)

Por
supuesto que en un entorno donde haya problemas de seguridad se puede “hilar
más fino” y asignar permisos y derechos más restrictivos
a todas estas cuentas de las que hemos hablado.

Este tipo de errores puede permitir a usuarios malintencionados acceder a datos
a los que de otro modo no tendrían acceso y, en el peor de los casos,
modificar el comportamiento de nuestras aplicaciones.

Vamos a ver con un ejemplo que significa eso
de “Inyección de código”:

Supongamos que tenemos una aplicación Web (realizada en ASP por sencillez)
en la que el acceso a ciertas secciones está restringido. Para restringir
ese acceso creamos una tabla de usuarios y contraseñas y sólo
los usuarios que se validen contra esa tabla podrán acceder a esos contenidos.
Una manera de que los usuarios se validen será colocar un par de cuadros
de texto en nuestra página Web (por ejemplo txtUsuario y txtPassword)
donde puedan introducir su nombre y su contraseña y enviar ese par usuario/contraseña
a la base de datos para comprobar si es válido.

Primero creamos la tabla que vamos a usar
y la rellenamos con datos:

use web-- Nuestra base de datos se llama webgo-- Creamos una tabla para almacenar los pares usuario/contraseñacreate table usuarios (Usuario varchar (50) not null primary key,
Password varchar (50))go-- Introducimos un par de datos de pruebainsert into usuarios (Usuario, Password) values ('Admin', '1234')insert into usuarios (Usuario, Password) values ('Usuario', 'abcd')

Ahora veamos el código de las páginas
que forman parte del proceso de login.

index.htm<form action="login.asp" method="post">Nombre: <input type="text" name="txtUsuario"><br>Password: <input type="password" name="txtPassword"><br><input type="submit"></form>

Esta primera página es sencilla. Simplemente
los dos cuadros de texto mencionados que enviarán los datos a la página de login.

Login.asp<%Dim Usuario, Password, RS, SSQLUsuario = Request.Form("txtUsuario")Password = Request.Form("txtPassword")SSQL = "SELECT count(*) FROM Usuarios WHERE Usuario = '" &
Usuario &"' AND password='" & Password & "'"Set RS = Server.CreateObject("ADODB.Recordset")RS.Open SSQL, "Cadena de conexion"If (RS.EOF) ThenResponse.Write "Acceso denegado."ElseResponse.Write "Te has identificado como " & RS("Usuario")End IfSet RS = Nothing%>

Y en esta segunda página creamos dinámicamente
una sentencia SQL que enviamos a la base de datos para la validación.

Si el usuario escribe Admin y 1234 la sentencia creada será:

“SELECT Count(*) FROM Usuarios WHERE Usuario=’Admin’ AND
Password=’1234’”

Y como esta sentencia nos devuelve un registro,
dejaremos que el usuario entre en la Web. Si el usuario escribe por ejemplo
‘Admin’ y de contraseña cualquier otra cosa, la sentencia no nos devolverá registros
y no permitiremos entrar a esa persona.

Pero ¿qué ocurre si el usuario
escribe ‘ or ‘1′=’1 como usuario y lo mismo de contraseña?

En este caso la variable Consulta contendrá
la cadena:

"SELECT Count(*) FROM Usuarios WHERE Usuario = '' or '1'='1' AND
password = '' or '1'='1'"

Y obviamente esta sentencia nos devuelve registros
con lo que el usuario entrará en nuestra Web sin tener permiso.

Pero esto no es lo peor. Lo peor será
que el usuario utilice estos trucos de inyección de SQL para ejecutar
código arbitrario en nuestro servidor. Sentencias DDL, cambiar permisos,
utilizar procedimientos almacenados y un largo etcétera. Qué ocurriría
si alguien escribiese de contraseña cosas como:

' exec master..xp_cmdshell 'net user test /ADD' –

Como evitarlo:

Y ahora lo más importante, ¿qué
podemos hacer para evitar estos errores?
Pues hay varios sistemas para evitarlo. Por ejemplo podemos filtrar las entradas
de los usuarios reemplazando la aparición de ‘ por ‘’
(dos comillas simples) e incluso evitando que los usuarios puedan pasar caracteres
como \ / “ ‘ o cualquier otro que se nos ocurra que puede causar
problemas. Estos filtros pueden ser tan sencillos como utilizar la sentencia
replace de Visual Basic:

SSQL= "SELECT count(*) FROM Usuarios WHERE Usuario = '" & ReplacetxtUsuario.Text, "'", "''") & "' AND password='" & Replace(txtPassword.Text, "'", "''") & "'"

Otro factor importante en cuanto a la seguridad
es limitar al máximo los permisos del usuario que ejecuta estas sentencias
para evitar posibles problemas. Por ejemplo utilizando un usuario distinto para
las sentencias SELECT, DELETE, UPDATE y asegurándonos que cada ejecución
de una sentencia ejecute una sentencia del tipo permitido.

Por supuesto utilizar el usuario ‘sa’
o uno que pertenezca al rol ‘db_owner’ para ejecutar las sentencias
de uso habitual de la base de datos debería quedar descartado.

Una solución definitiva sería trabajar con procedimientos almacenados.
El modo en el que se pasan los parámetros a los procedimientos almacenados
evita que la inyección SQL pueda ser usada. Por ejemplo utilizando el
siguiente procedimiento almacenado:

CREATE Procedure Validar @usuario varchar(50), @password varchar(50)
ASIf (SELECT Count(*) FROM Usuarios WHERE Usuario=@Usuario and Password=@password)>0Return 1Return 0

También deberíamos validar los
datos que introduce el usuario teniendo en cuenta por ejemplo la longitud de
los campos y el tipo de datos aceptados. Esto lo podemos hacer en el cliente
con los RegularExpressionValidator o con los CustomValidators del VB.NET. De
todos modos si la seguridad es importante todas estas validaciones hay que repetirlas
en el servidor.

Por ultimo, y ya que estamos pensando en entornos
Web, podemos programar en ASP.NET y utilizar siempre que sea posible las clases
System.Web.Security.FormsAuthentication para que los usuarios entren en nuestras
aplicaciones Web.