Duda con SELECT y parametros en un SP

Hola:
Adicional al comentario de Max de inyeccion de codigo, debes considerar
la naturaleza de los procedimientos almacenados y su funcionalidad. Yo soy
muy amigo de los Procedimientos Almacenados pero en este caso en particular
que "valor" adicional te da el Procedimiento Almacenado:
Seguridad> NO
Desempeno > NO
Encapsula(esconde) las tablas > NO

Porque no hacer desde la aplicacion directamente el SELECT?


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

"Maxi" wrote in message
news:

Hola, el SQL-dinamico es peligroso porque te pueden injectar codigo :(

ejemplo:

variable = ';drop table clientes;'

Aca tienes mas info del SqlDinamico

http://www.algonet.se/~sommar/dynamic_sql.html


Si usas buenos wheres el pasaje de los campos no seria tan dramatico


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



"José G Alvarez" escribió en el mensaje
news:
>
> > Hola, eso no lo haria en un SP ya que deberias usar SQL-Dinamico y
> realmente
> > no es para nada aconsejado usarlo por muchos problemas de Seguridad y
> > Performance que esto lleva.
>
> Soy un tanto novato... Podrias esplicarme un poco mejor este punto de
> vista?, es decir, por que tendria problemas de seguridad y/o

performance?

>
> > Ahora, cual es el sentido que solo te retorne ese campo? porque no
> retornar
> > todo y en la aplicacion cliente usar lo que realmente necesitas?
>
> La tabla contiene demasiados campos, y no me agrada la idea, en lo
absoluto,
> de pasarlos tan frecuentemente a travez del cable utp
>
>



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.764 / Virus Database: 511 - Release Date: 15/09/2004

Amigo Javier, hay un punto en el cual no estoy de acuerdo contigo ;-)

Y es en seguridad: Si armas un SP le das solo acceso a los usuarios el mismo
y no a las tablas de forma directa, con lo cual estas ganando en seguridad y
mucho te diria :-)

Ademas, cuando estas en un equipo de trabajo es bueno poder definir un
metodo que luego no tenga excepciones por todos lados ,-), si a tus
desarrolladores les decis que todo se haga con SP sera una forma muy buena
de poder tener una metrica de trabajo y control.

Un abrazo




Maxi

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

Msn Messager:

"Javier Loria" escribió en el mensaje
news:

Hola:
Adicional al comentario de Max de inyeccion de codigo, debes considerar
la naturaleza de los procedimientos almacenados y su funcionalidad. Yo soy
muy amigo de los Procedimientos Almacenados pero en este caso en
particular
que "valor" adicional te da el Procedimiento Almacenado:
Seguridad> NO
Desempeno > NO
Encapsula(esconde) las tablas > NO

Porque no hacer desde la aplicacion directamente el SELECT?


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

"Maxi" wrote in message
news:

Hola, el SQL-dinamico es peligroso porque te pueden injectar codigo :(

ejemplo:

variable = ';drop table clientes;'

Aca tienes mas info del SqlDinamico

http://www.algonet.se/~sommar/dynamic_sql.html


Si usas buenos wheres el pasaje de los campos no seria tan dramatico


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



"José G Alvarez" escribió en el mensaje
news:
>
> > Hola, eso no lo haria en un SP ya que deberias usar SQL-Dinamico y
> realmente
> > no es para nada aconsejado usarlo por muchos problemas de Seguridad y
> > Performance que esto lleva.
>
> Soy un tanto novato... Podrias esplicarme un poco mejor este punto de
> vista?, es decir, por que tendria problemas de seguridad y/o

performance?

>
> > Ahora, cual es el sentido que solo te retorne ese campo? porque no
> retornar
> > todo y en la aplicacion cliente usar lo que realmente necesitas?
>
> La tabla contiene demasiados campos, y no me agrada la idea, en lo
absoluto,
> de pasarlos tan frecuentemente a travez del cable utp
>
>



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.764 / Virus Database: 511 - Release Date: 15/09/2004

Perdón por la intrusión, pero ahora que estás hablando de eso Maxi, yo tengo
una aplicación en 3 capas, ya la tenemos bastante avanzada y el acceso a
datos es todo por SP, la seguridad la tenemos pensada como lo estás
diciendo ahora, dándole permisos de ejecución al usuario sobre el SP y asi
nunca podría manejar las tablas,etc etc, pero el otro día me he quedado
bastante sorprendida con el artículo que teneis sobre las funciones de
aplicación. Se suele combinar los 2 métodos? Cual es la mejor manera de
implementar la seguridad en una aplicacion de 3 capas accediendo a datos
solamente por SP???

Muchas gracias :)

"MAXI" escribió en el mensaje
news:

Amigo Javier, hay un punto en el cual no estoy de acuerdo contigo ;-)

Y es en seguridad: Si armas un SP le das solo acceso a los usuarios el

mismo

y no a las tablas de forma directa, con lo cual estas ganando en seguridad

y

mucho te diria :-)

Ademas, cuando estas en un equipo de trabajo es bueno poder definir un
metodo que luego no tenga excepciones por todos lados ,-), si a tus
desarrolladores les decis que todo se haga con SP sera una forma muy buena
de poder tener una metrica de trabajo y control.

Un abrazo




Maxi

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

Msn Messager:

"Javier Loria" escribió en el mensaje
news:
> Hola:
> Adicional al comentario de Max de inyeccion de codigo, debes

considerar

> la naturaleza de los procedimientos almacenados y su funcionalidad. Yo

soy

> muy amigo de los Procedimientos Almacenados pero en este caso en
> particular
> que "valor" adicional te da el Procedimiento Almacenado:
> Seguridad> NO
> Desempeno > NO
> Encapsula(esconde) las tablas > NO
>
> Porque no hacer desde la aplicacion directamente el SELECT?
>
>
> 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
>
> "Maxi" wrote in message
> news:
>> Hola, el SQL-dinamico es peligroso porque te pueden injectar codigo :(
>>
>> ejemplo:
>>
>> variable = ';drop table clientes;'
>>
>> Aca tienes mas info del SqlDinamico
>>
>> http://www.algonet.se/~sommar/dynamic_sql.html
>>
>>
>> Si usas buenos wheres el pasaje de los campos no seria tan dramatico
>>
>>
>> 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
>>
>>
>>
>> "José G Alvarez" escribió en el mensaje
>> news:
>> >
>> > > Hola, eso no lo haria en un SP ya que deberias usar SQL-Dinamico y
>> > realmente
>> > > no es para nada aconsejado usarlo por muchos problemas de Seguridad

y

>> > > Performance que esto lleva.
>> >
>> > Soy un tanto novato... Podrias esplicarme un poco mejor este punto de
>> > vista?, es decir, por que tendria problemas de seguridad y/o
> performance?
>> >
>> > > Ahora, cual es el sentido que solo te retorne ese campo? porque no
>> > retornar
>> > > todo y en la aplicacion cliente usar lo que realmente necesitas?
>> >
>> > La tabla contiene demasiados campos, y no me agrada la idea, en lo
>> absoluto,
>> > de pasarlos tan frecuentemente a travez del cable utp
>> >
>> >
>>
>>
>>
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.764 / Virus Database: 511 - Release Date: 15/09/2004
>>
>>
>
>

Hola Max:
No.
Cuando usas SQL Dinamico debes dar permiso tanto a Procedimiento
Almacenado como a las Tablas. Por ejemplo en el codigo que publico Tinoco no
basta con darle permisos al usuario al procedimiento, sino luego tienes que
dar permisos de Select a ConfigTablas.
La inyeccion de codigo es solo uno de los problemas de seguridad del SQL
Dinamico. Puedes hacer algunas pruebas. Crea en un BD llamada Pruebas el
siguiente script:
=USE Pruebas
GO
CREATE TABLE Pruebas(
Columna1 INT NOT NULL PRIMARY KEY
, Columna2 INT NOT NULL
, Columna3 INT NOT NULL
)

INSERT Pruebas
SELECT 1, 1, 1

GO
CREATE PROC Sel_Pruebas(
@pNombreCampo SYSNAME
)
AS
DECLARE @SQLString NVARCHAR(500)
SET @SQLString = N'SELECT ' + @pNombreCampo + ' FROM Pruebas WHERE ' +
@pNombreCampo + '=1'
EXECUTE sp_executesql @SQLString
GO
EXEC Sel_Pruebas 'Columna1'

GO
EXEC sp_addlogin 'Demo','Demo', 'Pruebas'
EXEC sp_adduser 'Demo', 'Demo'
GRANT EXEC ON Sel_Pruebas TO Demo
= Esto crea una Tabla y un Procedimiento en la BD Pruebas y luego crea un
Login y un Usuario Demo con permisos para ejecutar Sel_Pruebas. En otra
Analizador de Consultas haz login como Demo (asumiendo que usas Seguridad de
SQL) y pruebas ejecutar el procedimiento. Deber darte Error de Permimos
SELECT permision denied on object 'Pruebas'
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

"MAXI" wrote in message
news:

Amigo Javier, hay un punto en el cual no estoy de acuerdo contigo ;-)

Y es en seguridad: Si armas un SP le das solo acceso a los usuarios el

mismo

y no a las tablas de forma directa, con lo cual estas ganando en seguridad

y

mucho te diria :-)

Ademas, cuando estas en un equipo de trabajo es bueno poder definir un
metodo que luego no tenga excepciones por todos lados ,-), si a tus
desarrolladores les decis que todo se haga con SP sera una forma muy buena
de poder tener una metrica de trabajo y control.

Un abrazo




Maxi

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

Msn Messager:

"Javier Loria" escribió en el mensaje
news:
> Hola:
> Adicional al comentario de Max de inyeccion de codigo, debes

considerar

> la naturaleza de los procedimientos almacenados y su funcionalidad. Yo

soy

> muy amigo de los Procedimientos Almacenados pero en este caso en
> particular
> que "valor" adicional te da el Procedimiento Almacenado:
> Seguridad> NO
> Desempeno > NO
> Encapsula(esconde) las tablas > NO
>
> Porque no hacer desde la aplicacion directamente el SELECT?
>
>
> 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
>
> "Maxi" wrote in message
> news:
>> Hola, el SQL-dinamico es peligroso porque te pueden injectar codigo :(
>>
>> ejemplo:
>>
>> variable = ';drop table clientes;'
>>
>> Aca tienes mas info del SqlDinamico
>>
>> http://www.algonet.se/~sommar/dynamic_sql.html
>>
>>
>> Si usas buenos wheres el pasaje de los campos no seria tan dramatico
>>
>>
>> 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
>>
>>
>>
>> "José G Alvarez" escribió en el mensaje
>> news:
>> >
>> > > Hola, eso no lo haria en un SP ya que deberias usar SQL-Dinamico y
>> > realmente
>> > > no es para nada aconsejado usarlo por muchos problemas de Seguridad

y

>> > > Performance que esto lleva.
>> >
>> > Soy un tanto novato... Podrias esplicarme un poco mejor este punto de
>> > vista?, es decir, por que tendria problemas de seguridad y/o
> performance?
>> >
>> > > Ahora, cual es el sentido que solo te retorne ese campo? porque no
>> > retornar
>> > > todo y en la aplicacion cliente usar lo que realmente necesitas?
>> >
>> > La tabla contiene demasiados campos, y no me agrada la idea, en lo
>> absoluto,
>> > de pasarlos tan frecuentemente a travez del cable utp
>> >
>> >
>>
>>
>>
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.764 / Virus Database: 511 - Release Date: 15/09/2004
>>
>>
>
>

Gracias Javier, yo me referia a NO usar Sql-Dinamico bajo ningun concepto
;-), como veras no lo uso :-)

Vos decias de hacer el Select en la aplicacion, y para ello deberias usar
roles de aplicacion ya que sino el usuario tendria acceso directo a las
tablas y no seria muy bueno que digamos :(


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:

Hola Max:
No.
Cuando usas SQL Dinamico debes dar permiso tanto a Procedimiento
Almacenado como a las Tablas. Por ejemplo en el codigo que publico Tinoco

no

basta con darle permisos al usuario al procedimiento, sino luego tienes

que

dar permisos de Select a ConfigTablas.
La inyeccion de codigo es solo uno de los problemas de seguridad del

SQL

Dinamico. Puedes hacer algunas pruebas. Crea en un BD llamada Pruebas el
siguiente script:
=> USE Pruebas
GO
CREATE TABLE Pruebas(
Columna1 INT NOT NULL PRIMARY KEY
, Columna2 INT NOT NULL
, Columna3 INT NOT NULL
)

INSERT Pruebas
SELECT 1, 1, 1

GO
CREATE PROC Sel_Pruebas(
@pNombreCampo SYSNAME
)
AS
DECLARE @SQLString NVARCHAR(500)
SET @SQLString = N'SELECT ' + @pNombreCampo + ' FROM Pruebas WHERE ' +
@pNombreCampo + '=1'
EXECUTE sp_executesql @SQLString
GO
EXEC Sel_Pruebas 'Columna1'

GO
EXEC sp_addlogin 'Demo','Demo', 'Pruebas'
EXEC sp_adduser 'Demo', 'Demo'
GRANT EXEC ON Sel_Pruebas TO Demo
=> Esto crea una Tabla y un Procedimiento en la BD Pruebas y luego crea

un

Login y un Usuario Demo con permisos para ejecutar Sel_Pruebas. En otra
Analizador de Consultas haz login como Demo (asumiendo que usas Seguridad

de

SQL) y pruebas ejecutar el procedimiento. Deber darte Error de Permimos
SELECT permision denied on object 'Pruebas'
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

"MAXI" wrote in message
news:
> Amigo Javier, hay un punto en el cual no estoy de acuerdo contigo ;-)
>
> Y es en seguridad: Si armas un SP le das solo acceso a los usuarios el
mismo
> y no a las tablas de forma directa, con lo cual estas ganando en

seguridad

y
> mucho te diria :-)
>
> Ademas, cuando estas en un equipo de trabajo es bueno poder definir un
> metodo que luego no tenga excepciones por todos lados ,-), si a tus
> desarrolladores les decis que todo se haga con SP sera una forma muy

buena

> de poder tener una metrica de trabajo y control.
>
> Un abrazo
>
>
>
>
> Maxi
>
> Buenos Aires - Argentina
> Desarrollador .NET 3 Estrellas
> Microsoft User Group (MUG)
> Mail: Maxi_accotto[arroba]speedy.com.ar
>
> Msn Messager:
>
> "Javier Loria" escribió en el mensaje
> news:
> > Hola:
> > Adicional al comentario de Max de inyeccion de codigo, debes
considerar
> > la naturaleza de los procedimientos almacenados y su funcionalidad. Yo
soy
> > muy amigo de los Procedimientos Almacenados pero en este caso en
> > particular
> > que "valor" adicional te da el Procedimiento Almacenado:
> > Seguridad> NO
> > Desempeno > NO
> > Encapsula(esconde) las tablas > NO
> >
> > Porque no hacer desde la aplicacion directamente el SELECT?
> >
> >
> > 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
> >
> > "Maxi" wrote in message
> > news:
> >> Hola, el SQL-dinamico es peligroso porque te pueden injectar codigo

:(

> >>
> >> ejemplo:
> >>
> >> variable = ';drop table clientes;'
> >>
> >> Aca tienes mas info del SqlDinamico
> >>
> >> http://www.algonet.se/~sommar/dynamic_sql.html
> >>
> >>
> >> Si usas buenos wheres el pasaje de los campos no seria tan dramatico
> >>
> >>
> >> 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
> >>
> >>
> >>
> >> "José G Alvarez" escribió en el mensaje
> >> news:
> >> >
> >> > > Hola, eso no lo haria en un SP ya que deberias usar SQL-Dinamico

y

> >> > realmente
> >> > > no es para nada aconsejado usarlo por muchos problemas de

Seguridad

y
> >> > > Performance que esto lleva.
> >> >
> >> > Soy un tanto novato... Podrias esplicarme un poco mejor este punto

de

> >> > vista?, es decir, por que tendria problemas de seguridad y/o
> > performance?
> >> >
> >> > > Ahora, cual es el sentido que solo te retorne ese campo? porque

no

> >> > retornar
> >> > > todo y en la aplicacion cliente usar lo que realmente necesitas?
> >> >
> >> > La tabla contiene demasiados campos, y no me agrada la idea, en lo
> >> absoluto,
> >> > de pasarlos tan frecuentemente a travez del cable utp
> >> >
> >> >
> >>
> >>
> >>
> >> Outgoing mail is certified Virus Free.
> >> Checked by AVG anti-virus system (http://www.grisoft.com).
> >> Version: 6.0.764 / Virus Database: 511 - Release Date: 15/09/2004
> >>
> >>
> >
> >
>
>

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.764 / Virus Database: 511 - Release Date: 15/09/2004