Evitar la inyección sql

Hola, una forma es armar un SP con todas las condiciones necesarias y usar
el truco de isnull(@var,capo)

Si vas a usar SQl desde la aplicacion yo haria que no se permita introducir
codigo ' y lo reemplazaria por espacios en blanco :)




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"José Antonio" escribió en el mensaje
news:%

Buenos días a :

1)Tengo que hacer una consulta sobre una tabla y otro par de tablas más
relacionadas con la primera en plan tabla1:facturas,
tabla2:asientos(para cada factura) tabla3:proveedores. De tal forma que al
final me queda que el usuario puede consultar por hasta 10 campos. Pero
también solo puede hacerlo por uno, o por dos, o por tres, o .con
todas
las posibles combinaciones, con lo que si no recuerdo mal la combinatoria
me
quedarían 1023 formas posibles de realizar la consulta.

Estoy empeñado en evitar en lo posible la posibilidad de inyección sql
utilizando procedimientos almacenados y parametros. En todo el desarrollo
de
la aplicación lo he hecho así, y resulta que ahora (que tengo prisa por
terminar) me encuentro con que lo más comodo sería generar la sentencia
sql
en el programa cliente y mandarla al servidor.

No se muy bien que hacer y es cierto que desde el programa cliente solo se
permite la entrada libre en 6 campos de los que puedo controlar 2 porque
son de tipo númerico. De esta forma obtendría 15 formas posibles y una
sentencia sql que debería combinar en el procedimiento almacenado. ¿Es
esta
una buena forma?. De ser así podíais decirme como lo hago. Quizas
mediantes
sp_executesql?. Hay otras formas mejores. ¿Es esto una chapuza?.


2) ¿Puedo pasar como parametro a un procedimiento almacenado algo así?

@ModoEntrega as nvarchar(200) --¿? @ModoEntrega = ('1', '3', '5')

Select * from RegiFacturas Where idModoEntrega in @ModoEntrega


Perdonar el abuso y muchas gracias.

Un abrazo,

José Antonio Sánchez

Hola:
Mi opinion, por supuesto totalmente criticable.
Una consulta Ad-Hoc es algo que no quieres hacer en un procedimiento, es
mejor en este caso una vista o incluso acceso directo a la tabla. Mis
razones, siendo "fanatico" de los procedimientos almacenados.
Un procedimiento almacenado te ayuda a "esconder" las tablas con lo cual
puedes cambiarla sin necesidad de cambiar el codigo de la aplicacion, en una
consulta Ad-Hoc esto no es cierto, pasas los parametro pasas el valor. Si
cambias la tabla debes cambiar tambien el procedimiento.
Un Procedimiento almacenado te ayuda en la seguridad. Esto no es cierto
para la consulta ad-hoc, el usuario puede hacer lo mismo que con una vista.
Un Procedimiento almacenado te ayuda en el desempeno, porque sus planes
de acceso estan "compilados la primera vez" y luego reutilizados. Esto no es
cierto para una consulta ad-hoc, ya que los planes cambiaran de acuerdo a
los parametros.
En este caso los Procedimientos no son la medicina adecuada.
Mi recomendacion, genera la consulta en la estacion. Revisa varias
cosas: cada parametro debe ser del tipo adecuado (un entero, fecha, char) y
de largo adecuado. Los ' se convierten en '', revisa adicionalmente los
comentarios (--, /* y */) que o no ocurren del todo u ocurren solo dentro
del '-'. Si el codigo que viene de la estacion es maligno, no deberias tener
problemas si el usuario no tiene permisos. Si el usuario tiene todos los
permisos, la inyeccion de codigo es el menor de los males :(.
En cuanto a la consulta, no es posible hacer lo que deseas (pasar un
arreglo) y ponerlo en un IN, debes o "parsear" el string e insertar fila por
fila en un tabla temporal o en una variable table, u otra alternativa es
usarla en formato XML.

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

"José Antonio" wrote in message
news:#

Buenos días a :

1)Tengo que hacer una consulta sobre una tabla y otro par de tablas más
relacionadas con la primera en plan tabla1:facturas,
tabla2:asientos(para cada factura) tabla3:proveedores. De tal forma que al
final me queda que el usuario puede consultar por hasta 10 campos. Pero
también solo puede hacerlo por uno, o por dos, o por tres, o .con

todas

las posibles combinaciones, con lo que si no recuerdo mal la combinatoria

me

quedarían 1023 formas posibles de realizar la consulta.

Estoy empeñado en evitar en lo posible la posibilidad de inyección sql
utilizando procedimientos almacenados y parametros. En todo el desarrollo

de

la aplicación lo he hecho así, y resulta que ahora (que tengo prisa por
terminar) me encuentro con que lo más comodo sería generar la sentencia

sql

en el programa cliente y mandarla al servidor.

No se muy bien que hacer y es cierto que desde el programa cliente solo se
permite la entrada libre en 6 campos de los que puedo controlar 2 porque
son de tipo númerico. De esta forma obtendría 15 formas posibles y una
sentencia sql que debería combinar en el procedimiento almacenado. ¿Es

esta

una buena forma?. De ser así podíais decirme como lo hago. Quizas

mediantes

sp_executesql?. Hay otras formas mejores. ¿Es esto una chapuza?.


2) ¿Puedo pasar como parametro a un procedimiento almacenado algo así?

@ModoEntrega as nvarchar(200) --¿? @ModoEntrega = ('1', '3', '5')

Select * from RegiFacturas Where idModoEntrega in @ModoEntrega


Perdonar el abuso y muchas gracias.

Un abrazo,

José Antonio Sánchez

Gracias a Javier (una vez más) y a Maxi. Seguiré vuestros consejos.
Por cierto Javier. Estuve en septiembre en tu país y me pareció precioso.
Un saludo desde España,

José Antonio Sànchez

Hola:
Muchas gracias por tus palabras.
Yo por mi parte, me gustaria muchisimo ir a Espana, pero no he tenido
oportunidad.
Tal vez si el proximo ano, me porto mejor. :D
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

"José Antonio" wrote in message
news:

Gracias a Javier (una vez más) y a Maxi. Seguiré vuestros consejos.
Por cierto Javier. Estuve en septiembre en tu país y me pareció precioso.
Un saludo desde España,

José Antonio Sànchez