Duda para evitar duplicados.

Muy ilustrativa tu explicación, la verdad es que he visto bastantes
desarrollos muy vulnerables a DOS simplemente por poner querys pesadas en la
home o en alguna página concreta, esto ya es para nota :-)

Gracias como siempre Javier


-

Miguel Egea Gómez
Webmaster de PortalSQL

(lo de online sobra)

Microsoft SqlServer M.V.P.

"Javier Loria" escribió en el mensaje
news:#H$

Hola:
Asi es. En realidad ese patron de codigo que tan LARGO y tan FEO, es

lo

que se requiere para evitar una vulnerabilidad llamada TOCTTOU (Time of
Check to Time of Use), que en el caso de SQL se puede utilizar para hacer

un

DOS (Deny of Service).
Una vulnerabilidad TocTTou ocurre cuando en la aplicacion ocurre algun
lapso entre el checkeo y el uso, por ejemplo en la capa de negocios reviso
que no exista la llave. Desde la validacion hasta el uso de la regla la
aplicacion es suceptible a ataque. En el caso de SQL significa que puedo
provocar que se genere la misma llave, obligando al SQL a hacer rollbacks
frecuentes, que tienen un costo en desempeno muy alto.
Entonces si monitoreo el cable, veo que la aplicacion esta mandando

una

solicitud para una llave y en la aplicacion que ataca, envio la misma

llave

al SQL, fuerzo los Rollbacks. Si la hago bastante veces eventualmente se

les

negara el acceso a otros usuarios, por TimeOut logrando el DOS :(
Dos formas de reducir la exposicion al TocTou son incrementar los
chequeos y hacerlos lo mas cercanos posibles al uso.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Miguel Egea escribio:
> jeje, hombre prevenido vale por dos :-)
>
>

>
> "Javier Loria" escribió en el mensaje
> news:
>> Hola:
>> Desde el punto de vista de mantenimiento de codigo es mejor
>> insertar y revisar el error.
>> Desde el punto de vista de desempeno lo mejor es revisar antes y
>> si no existe iniciar la transaccion insertar y por ultimo controlar
>> que no hubo error. Este patron es:
>> => >> IF EXISTS(...)
>> BEGIN
>> RAISERROR(...)
>> END
>> IF EXISTS(..)
>> BEGING
>> RAISERROR(...)
>> END
>>
>> BEGIN TRAN
>> INSERT ...
>>
>> IF @@ERROR <> THEN
>> BEGIN
>> RAISERROR(...)
>> ROLLBACK
>> RETURN 1
>> END
>> INSERT ...
>>
>> IF @@ERROR <> THEN
>> BEGIN
>> RAISERROR(...)
>> ROLLBACK
>> RETURN 1
>> EDN
>> COMMIT
>> => >> Es muy rapido, porque evita la transaccion en la gran mayoria de
>> los casos. y cuando la realiza es muy poco probable que tenga error.
>> La desventaja es que tienes que escribir la regla 2 veces!!! en
>> el CHECK/PRIMARY KEY/FOREIGN KEY, y en el IF EXISTS, y a pesar de
>> esto puede ocurrir un error.
>> Saludos,
>>
>>
>> Javier Loria
>> Costa Rica
>> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
>> que pueda ser copiado y pegado al Query Analizer.
>> La version de SQL y Service Pack tambien ayuda.
>> Carmelo J. Morales Muñoz escribio:
>>> ¡Hola!
>>>
>>> ¿que es mejor forma de evitar duplicados?. Gestionar en el
>>> propio StoreProc de inserción si ya existe? Esperar a que de
>>> error las reglas de integridad?...
>>>
>>> Gracias!

EXCELENTE!!! no sabia esto, la verdad que muy buena exposicion Javier y para
tomarlo bien en consideracion.

Un abrazo


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Javier Loria" escribió en el mensaje
news:%23H$

Hola:
Asi es. En realidad ese patron de codigo que tan LARGO y tan FEO, es

lo

que se requiere para evitar una vulnerabilidad llamada TOCTTOU (Time of
Check to Time of Use), que en el caso de SQL se puede utilizar para hacer

un

DOS (Deny of Service).
Una vulnerabilidad TocTTou ocurre cuando en la aplicacion ocurre algun
lapso entre el checkeo y el uso, por ejemplo en la capa de negocios reviso
que no exista la llave. Desde la validacion hasta el uso de la regla la
aplicacion es suceptible a ataque. En el caso de SQL significa que puedo
provocar que se genere la misma llave, obligando al SQL a hacer rollbacks
frecuentes, que tienen un costo en desempeno muy alto.
Entonces si monitoreo el cable, veo que la aplicacion esta mandando

una

solicitud para una llave y en la aplicacion que ataca, envio la misma

llave

al SQL, fuerzo los Rollbacks. Si la hago bastante veces eventualmente se

les

negara el acceso a otros usuarios, por TimeOut logrando el DOS :(
Dos formas de reducir la exposicion al TocTou son incrementar los
chequeos y hacerlos lo mas cercanos posibles al uso.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Miguel Egea escribio:
> jeje, hombre prevenido vale por dos :-)
>
>

>
> "Javier Loria" escribió en el mensaje
> news:
>> Hola:
>> Desde el punto de vista de mantenimiento de codigo es mejor
>> insertar y revisar el error.
>> Desde el punto de vista de desempeno lo mejor es revisar antes y
>> si no existe iniciar la transaccion insertar y por ultimo controlar
>> que no hubo error. Este patron es:
>> => >> IF EXISTS(...)
>> BEGIN
>> RAISERROR(...)
>> END
>> IF EXISTS(..)
>> BEGING
>> RAISERROR(...)
>> END
>>
>> BEGIN TRAN
>> INSERT ...
>>
>> IF @@ERROR <> THEN
>> BEGIN
>> RAISERROR(...)
>> ROLLBACK
>> RETURN 1
>> END
>> INSERT ...
>>
>> IF @@ERROR <> THEN
>> BEGIN
>> RAISERROR(...)
>> ROLLBACK
>> RETURN 1
>> EDN
>> COMMIT
>> => >> Es muy rapido, porque evita la transaccion en la gran mayoria de
>> los casos. y cuando la realiza es muy poco probable que tenga error.
>> La desventaja es que tienes que escribir la regla 2 veces!!! en
>> el CHECK/PRIMARY KEY/FOREIGN KEY, y en el IF EXISTS, y a pesar de
>> esto puede ocurrir un error.
>> Saludos,
>>
>>
>> Javier Loria
>> Costa Rica
>> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
>> que pueda ser copiado y pegado al Query Analizer.
>> La version de SQL y Service Pack tambien ayuda.
>> Carmelo J. Morales Muñoz escribio:
>>> ¡Hola!
>>>
>>> ¿que es mejor forma de evitar duplicados?. Gestionar en el
>>> propio StoreProc de inserción si ya existe? Esperar a que de
>>> error las reglas de integridad?...
>>>
>>> Gracias!

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.676 / Virus Database: 438 - Release Date: 03/05/2004