viernes, 27 de abril de 2007

Inyecciones SQL (III parte)

Continuando con la exposición ....
No sé si estoy logrando lo que pretendo : que se tome conciencia de que este tema es muy serio y peligroso...
Y cada vez que hacemos consultas a una base de datos, se debe tomar las precauciones del caso, validar las entradas del usuario como si estuvieras seguro de que intentarán ponerte una inyección SQL.

Tío, hasta pueden detener tu servidor SQL SERVER ...
simplemente poniendo; SHUTDOWN;
El comando SHUTDOWN no es una consulta (es una orden!!), por lo tanto no tiene que estar precedido por una palabra reservada como UNION o SELECT o alguna otra...

A decir verdad, el comando SHUTDOWN es tu carta de despido... si no haces bien las validaciones ... no sé si me entiendes.

Noooo, qué va ...el comando SHUTDOWN no es tan malo, digamos que es más o menos malo ...
Quieres saber qué sería realmente malo? realmente malo sería hacerle un ;DROP DATABASE TU_BASE_DE_DATOS;

Otra cosa que pueden hacer -hay que decirlo: es interesante!!- es conectarse desde tu base de datos a otra base de datos.
Repasemos algunas formas de lograr esto:

1.- Definiendo un servidor enlazado, que no es más que los datos de conexión resumidos en un alias, para establecer la conexión a un origen de datos que está en otro servidor (ORACLE, SQL SERVER, ACCESS, EXCEL ...etc)...
y, de esta manera poder manipular los datos como si estuvieran en un único servidor.Para recuperar los datos, simplemente hay que referenciarla a través del alias establecido...algo así:
SELECT * FROM MIALIAS...MITABLA

2.- Usando consultas creadas "al vuelo", con los comandos OPENROWSET y OPENDATASOURCE, que incluye los datos de conexión al servidor en la cadena de consulta, para acceder a datos de diversos orígenes de datos.
Como dije: estos comandos sirven para consultas repentinas o poco usuales.

Y ya que hablamos de diversos orígenes de datos ... cae a pelo que les pase el link de http://www.connectionstrings.com/ ... como alguien diría: ahí ta' to'.

Las consultas "al vuelo" son muy usadas para obtener información ajena... ejemplo:
http://127.0.0.1/xxx/Error.aspx?ErrorCode=1 UNION select * from OPENROWSET('SQLoledb','server=121.45.45.55,80;database=TU_BASE_DE_DATOS;uid=sa;pwd=;timeout=5','SELECT blah FROM blah)
Se dan cuenta que las posibilidades de inyectar código SQL son inmensas?


Tío, si tú piensas que no tienes que preocuparte de las inyecciones SQL... déjame decirte que estás totalmente loco.

Pero, defenderse de las inyecciones SQL es muy fácil:

Lo único que tienes que hacer es analizar minuciosamente la data que va a ser usada como parámetro en tu consulta SQL.

Esperando haberte concientizado un poco ... me despido temporamente.

No hay comentarios.: