Problemas con comillas

Es que las consultas parametrizadas y SP no me valen, pero supon que pongo:

"select * from pedidos where id=" & var & " order by fecha"

¿Me podrian hacer igualmente lo del drop?

"Jesús López" escribió en el mensaje
news:u%

¿Mejor que usar consultas parametrizadas?. Pues usar procedimientos
almacenados que es aún más seguro, ya que con estos, no es necesario dar
permisos para acceder directamente a las tablas. Si los usuarios tienen
permiso para SELECT, UPDATE y DELETE en una tabla. ¿Qué les impide desde
el Excel usando MSQUERY o desde cualquier otra herramienta como desde el
Access usando una consulta de paso a través, ejecutar DELETE FROM Tabla?
cualquier usuario malintencionado y con no demasiados conocimientos lo
podrá hacer.

Saludos:

Jesús López



"Cid" escribió en el mensaje
news:

Pues me dejas frito, tengo un monton de casos de estos, ¿aparte de usar
parametros que solucion se le puede dar?

"Jesús López" escribió en el mensaje
news:Oj7z$

No señor, por lo menos en SQL Server y en otros sistemas de base de
datos está permitido mandar más de una sentencia SQL en el mismo proceso
por lotes. Así que de relativo nada, tienes un agujero de seguridad como
la boca del metro.

Saludos:

Jesús López

¿Que las consultas parametrizadas no te valen? ¿Serías tan amable de
explicarme por qué?.

Yo no digo que los procedimientos almacenados y las consultas parametrizadas
vayan a servir en todos los casos. Lo que digo es que es recomendable
usarlas siempre que puedas. De todas maneras, me gustaría que me mostraras
varios casos en los que crees que no se pueden usar consultas
parametrizadas, yo podría intentar parametrizarlas en la medida de lo
posible y sobre todo intentar evitar la posibilidad de inyeccción SQL.

supongamos que var:

var = "1; drop table pedidos; select 1 as fecha "

¿qué daría como resultado de?:

"select * from pedidos where id=" & var & " order by fecha"

esto:

select * from pedidos where id =1; drop table pedidos; select 1 as fecha
order by fecha

Pufff !!!! te han eliminado la tabla pedidos escribiendo en una caja de
texto de tu programa !!!

Saludos:

Jesús López
MVP



"Cid" escribió en el mensaje
news:

Es que las consultas parametrizadas y SP no me valen, pero supon que
pongo:

"select * from pedidos where id=" & var & " order by fecha"

¿Me podrian hacer igualmente lo del drop?

"Jesús López" escribió en el mensaje
news:u%

¿Mejor que usar consultas parametrizadas?. Pues usar procedimientos
almacenados que es aún más seguro, ya que con estos, no es necesario dar
permisos para acceder directamente a las tablas. Si los usuarios tienen
permiso para SELECT, UPDATE y DELETE en una tabla. ¿Qué les impide desde
el Excel usando MSQUERY o desde cualquier otra herramienta como desde el
Access usando una consulta de paso a través, ejecutar DELETE FROM Tabla?
cualquier usuario malintencionado y con no demasiados conocimientos lo
podrá hacer.

Saludos:

Jesús López



"Cid" escribió en el mensaje
news:

Pues me dejas frito, tengo un monton de casos de estos, ¿aparte de usar
parametros que solucion se le puede dar?

"Jesús López" escribió en el mensaje
news:Oj7z$

No señor, por lo menos en SQL Server y en otros sistemas de base de
datos está permitido mandar más de una sentencia SQL en el mismo
proceso por lotes. Así que de relativo nada, tienes un agujero de
seguridad como la boca del metro.

Saludos:

Jesús López

supongamos que var:

var = "1; drop table pedidos; select 1 as fecha "

Si la sentencia SQL esta en una sola linea (y por lo general es asi) esto
mejor (o peor?)

var = "1; drop table pedidos; --"

Porque todo el resto queda como comentario y ya que no tienes que saber como
sigue la sentencia.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

Es que las consultas parametrizadas y SP no me valen

¿Por que? Si estas usando una BD Access esta bien que los SP no te valen
pero puedes igualmente usar consultas parametrizadas.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

Sí señor, es mucho mejor/peor ;-)

Saludos:

Jesús López
MVP