Como validar Acceso al sistema

alcides · #1 02-12-2004

Hola amigos del foro

estoy usando delphi 7, y las tablas en access,

Tengo un tabla de usuarios, con nivel y password.
entonces para el acceso al sistema no he podido validar
en nombre del usuario y el password.

si por favor me pueden dar una manito, para cuando en la patalla
-acceso al sistema- se introduzca el nombre del usuario, como validarlo con el nombre ya creado en la tabla de usuarios.

Gracias

Alcides
Rep.Dom.

Neftali [Germán.Estévez] · #2 02-12-2004

En tu formulario de Acceso coloca un ADOTable (por ejemplo), lo configuras hacia tu Base de Datos de Access y cuando el usuario pulse el botón de acceptar abres la tabla y realizas un Locate con el nombre de usuario y el password que te han introducido a ver si existe.
Otra variante es utilizar un ADOQuery y montar la sentencia SQL (propiedad SQL)con el nomnre y password, lanzarla contra la Base de Datos de Access (ADOQuery.ExecSQL)y ver si devuelve algun registro (ADOQuery.EOF).

¿Exactamente qué es lo que no te funciona del proceso?

alcides · #3 02-12-2004

Gracias Neftali por ayudarme, voy a tratar y luego te hago saber,
porque realmente lo que no he podido es validar el nombre del usuario ya creado, cuando se pide el acceso.

alcides
Rep.Dom.

marcoszorrilla · #4 02-12-2004

Ahondando en la situación se supone que la clave esta encriptada por un algoritmo, hecho por ti mismo, no se te estará olvidando de desencriptar la clave para compararla con la introducida por el usuario, o también puedes utilizar lo contrario encriptar lo que introduce el usuario y compararlo con la clave que tienes en la tabla.

Un Saludo.

alcides · #5 03-12-2004

Hola marcoszorrilla,
esto es lo que hago para validar mediante un qry el nombre del usuario,
esto lo hago en el on change del campo.

ls_Nombre := Tbl_UsuarioNombre_Usuario.AsString;
Qry_Usuario.Close;
with qry_Usuario do begin
with sql do begin
clear;
add ('select * from Usuario');
add ('where Nombre_Usuario ='+(ls_Nombre));
open;
if recordcount <> 0 then begin
ShowMessage('!!!!!!Nombre de Usuario Incorrecto ');
Abort;
end;
end;
end;

y no me funciona, a ver que estoy haciendo mal

Gracias,

Alcides
Rep.Dom.

marcoszorrilla · #6 03-12-2004

Código Delphi [-]  ls_Nombre := Tbl_UsuarioNombre_Usuario.AsString;
   Qry_Usuario.Close;
   with qry_Usuario do begin
   with sql do begin
   clear;
   add ('select * from Usuario');
   add ('where Nombre_Usuario ='+(ls_Nombre));
   open;
    if recordcount = 0 then   begin
      ShowMessage('!!!!!!Nombre de Usuario Incorrecto ');
      Abort;
      end;
   end;
   end;

Un Saludo

mamcx · #7 03-12-2004

Aprovecho, ahora que la seguridad esta de moda, a apuntar que ese tipo de codigo esta invitando a todo el mundo a hacer una injeccion Sql.... O sea, se puede ingresar a la aplicacion si cracking ni brute-forcing ni nada...

Pillan por que?

marcoszorrilla · #8 03-12-2004

Conste que yo no utilizo SQL para comprobar las claves.
1.- Se teclea el nombre de Usuario
2.- La clave
3.-Abro tabla usuarios busco el nombre si existe
4.-Compruebo su clave que lógicamente está encriptada.

En caso negativo presento mensaje de error.

Usuario inexistente o clave incorrecta.

Un Saludo.

roman · #9 03-12-2004

Cita:

Empezado por mamcx

esta invitando a todo el mundo a hacer una injeccion Sql

¿Podrías explicar un poco más? Eres la segunda persona en pocos dias que menciona el tema dejando a muchos en ascuas.

Por otra parte, al menos yo no alcanzo a ver dónde está el problema. La consulta sólo da por condición el nombre de usuario así que aun inyectando código sql de manera que se "encuentre" al usuario, la posterior verificación de contraseña fallará.

Si no es así estaré encantado y agradecido de que menciones dónde está la falla.

// Saludos

mamcx · #10 03-12-2004

Puede que el esquema que tengas sea seguro, pero la mayoria de las veces no es. Injeccion Sql o Injeccion de codigo implica que se esta insertando codigo que ANULA o REEMPLAZA el existente. La mayoria de los sistemas/codigo de Login hechos por personas que no saben que es Sql Injeccion generan una alta probabilidad de que el sistema sea violado.

La injeccion funciona, en el ejemplo presente, asi:

1- El codigo original

Código Delphi [-]      add ('where Nombre_Usuario ='+QuoteStr(ls_Nombre)));
    open;
     if recordcount = 0 then   begin
       ShowMessage('!!
 !!!!Nombre de Usuario Incorrecto ');

2- Lo que el programador SUPONE que esta pasando

Código SQL [-]    where Nombre_Usuario = 'Mamcx'

3- Lo que cualquier hacker, o de hecho, un programador con nada que hacer, digitaria en el nombre de usario/clave algo como ' OR 1=1 ''=

4- Lo que va a pasar

Código SQL [-]     where Nombre_Usuario = '' OR 1=1 OR ''=''

Ahora bien, marcoszorrilla tiene un esquema que PARECE mas seguro, pero quien sabe?. Si la base de datos es Paradox, es probable que si. Si es un motor sql, a lo mejor no.

Si el codigo es:

Código Delphi [-]    dsUsuarios.Filter:=ls_Nombre;    
      if recordcount = 0 then   begin
          ShowMessage('!!!!!!Nombre de Usuario Incorrecto ');

Le pasa lo mismo. Si es:

Código Delphi [-]     dsUsuarios.Locate(ls_Nombre...    
       if recordcount = 0 then   begin
         ShowMessage('!!!!!!Nombre de Usuario Incorrecto ');

La anterior injeccion falla (creo. No he probado). Pero se puede trabajar un poco mas. Aun un codigo que use parametros y un procedimiento almacenado o use Locate o Find PUEDE ser suceptible a la injeccion. Ahora, no he probado con Localte o Find, pero seguro que con parametros de texto y SP se puede...

La UNICA forma de estar seguro, es que el usuario/clave tenga una mascara que solo acepte caracteres validos.

marcoszorrilla · #11 03-12-2004

Yo en concreto a lo que se teclea le aplico el algoritmo correspondiente para convertirlo en algo ilegible que compararé con la clave de igual a igual, por lo tanto es indiferente que tecleen por ejemplo el signo =.

Por otra parte no uso ningúna máscara para que puedan teclear cualquier cosa y así sea más dificil econtrar la clave por azar.

A los 3 intentos fallidos el sistema se cierra por completo.

A pesar de todo, pienso que cualquier Hacker, quer merzca ese nombre se saltaría la clave sin mucha dificultad. (la mía).

Recuerdo hace tiempo que con un amigo discutíamos acerca de la seguridad de cualquier sistema, en mi opinión si hay verdadero interés por saber algo se sabrá y no hay clave que se resista ·$$$$$$$.

Un Saludo.

mamcx · #12 03-12-2004

Disculpa... solo estaba creando expectacion, nada de quedarme con el secretico...!

Hay varios tipos de ataques, a saber, los Sql Injeccion, los Code/Scripts Injeccion, los Buffer Overrund, etc.. que se valen de que el programador confia en que el usuario/aplicacion esta digitando caracteres validos. Es probable que se haya creado un esquema de validacion de caracteres para las cajitas y de hecho, eso cura en gran medida el mal.

Sin embargo, si la aplicacion es distribuida o es tipo Web, el cliente que usa el usuario NO ES NI TIENE que ser el UNICO cliente posible. O sea, si el codigo de validacion es JavaScript y Ok, se filtran caracteres invalidos. Pero el hacker simplemente analiza hacia donde van los Request de la pagina y coje los QueryString o el Form y manda el mismo la solicitud. Si SOLAMENTE en el cliente se valido, el servidor quedara expuesto... quiere decir, se debe volver a revalidar en el servidor toda entrada que PUEDA ser digitada por un usuario, incluyen las URL, los QueryString, las cajas, combos, etc Y LOS CAMPOS ESCONDIDOS (que aproposito se usan para hacer suplantaciones bien bizarras).

Ahora, estos problemas son mas grandes en las aplicaciones Web y distribuidas, no tanto en las Desktop pero es bueno ir haciendose a la practica

marcoszorrilla · #13 03-12-2004

Cita:

Disculpa... solo estaba creando expectacion, nada de quedarme con el secretico...!

No hay nada que disculpar hombre, es muy interesante el tema que se está abordando y han sido muy oportunas tus pinceladas acerca de los posibles ataques contra la seguridad.

Yo recuerdo haber visto un programa que pulsando sobre un edit revelaba la clave tecleada aunque solamente se estuvieran mostrano asteriscos.

Un Saludo.

roman · #14 04-12-2004

Sí, sí. Entiendo eso pero sigo sin ver, aún permitiendo la inyección, cómo va a poder acceder al sistema estando de por medio la verificación de contraseña.

Es decir, si mi consulta es

Código SQL [-]select usuario, password from usuarios
where usuario = :usuario

inyectando los caracteres que mencionas, ciertamente la consulta me va a regresar registros.

Pero si después de ello hago algo como

Código Delphi [-]if DataSet['password'] <> EditPassword.Text then
  abort;

o mejor aún

Código Delphi [-]if DataSet['password'] <> Encrypt(EditPassword.Text) then
  abort;

¿entonces de qué sirve haber inyectado caracateres?

// Saludos

mamcx · #15 04-12-2004

En ese caso, ya es menos probable. Pero existen posibilidades... no con inyeccion de Sql sino con Buffer Overflow.... El punto es, bueno pa nosotros, exige verdadero esfuerzo hacerle eso al Delphi

No es como con C/C++, que de acuerdo a un estudio que vi la semana pasada, el 70-80% de todos los problemas de seguridad de MS se deben a una "caracteristica" del C++ o alguna deficiencia no administrada por parte del programador.

Ahora bien, la tecnica elemental de un overflow es tratar de hacerle tragar a un programa mas datos de los que permite el tipo de datos. Algo casi imposible con Delphi, porque genialmente, es un lenguaje bien tipado. Pero si se le intentase meter una cantidad BRUTAL de datos, tal vez haya experanzas.

Sin embargo, el punto es que un atacante no se quedara eternamente intentando un unico esquema. El codigo que se esboza aqui es mas tipico de una aplicacion Web y de hecho, de un programador ASP/VB, porque en Delphi uno hace mas comunmente lo de Roman.

En ese caso, el ataque se moveria mas por el lado de intentar crackear la aplicacion. Pero eso es un "poquito" mas sofisticado y seria mas bien tema de otra discusion...

El punto final es que no es bueno confiar en las entradas de datos (A proposito...otra forma de injeccion es intentar fastidiar el programa injectando un archivo con datos basuras y cosas asi.. razon por la que archivos planos o XML se deberian chequear contra un esquema.... obviamente depende del grado del riesgo) y se debe como minimo, tener mascaras de entrada. Contra un servicio Web o un sitios Web, se debe extremar el cuidado porque es mucho mas facil automatizar los ataques (por ejemplo, un script que intente varias sequencias de Injeccion y para un servidor Web no funiona *tan simplemente* el anular al 3 intento, por su naturaleza desconectada).

Tambien se debe anular la practica de logearse contra la base de datos como administrador. ESPECIALMENTE con Sql Server es MORTAL. De hecho, si veo que la aplicacion esta hecha en ASP.NET/ASP tengo un enorme chance de que use Acces o Sql Server. Asi que contra una entrada de datos desprotegida, se hace algo como meterle un comentario e hacer una llamada a un procedimiento especial que tiene Sql Server para AGREGAR USUARIOS AL DOMINIO, Y AL ESTAR COMO SA, ES EL Administrador!. Escalofriante cuando nos lo mostraron en una conferencia de MS!