Re: Seguridad en PostgreSQL

Disculpen pero no me queda del todo claro el tema de inyesión SQL.

Según tengo entendido es un BUG de muchos motores ... no solo de postgresql.
postgresql ya lo tiene solucionado ??? desde qué versión?? Me parece dificil
que un motor le de solución a este problema, el control debería estar más
del lado del programador.
utilizar el magic_quotes es una solución para php?
qué técnicas existen para solucionarlo? me parece buena la de prevalidar los
strings y eliminar cualquier palabra reservada.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

----- Original Message -----
From: "Juan Martínez" <jeugenio(at)umcervantes(dot)cl>
To: "Juan Martínez" <jeugenio(at)umcervantes(dot)cl>; "Gunnar Wolf"
<gwolf(at)gwolf(dot)org>; "Alejandro Gasca" <agasca(at)yahoo(dot)com>; "Mario Gonzalez (
mario__ )" <gonzalemario(at)gmail(dot)com>; "Jaime Casanova"
<systemguards(at)gmail(dot)com>; "Roberto Pupo" <roberto(dot)pupo(at)gmail(dot)com>;
<pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Saturday, November 04, 2006 4:53 PM
Subject: Re: [pgsql-es-ayuda] Seguridad en PostgreSQL

> Alvaro Herrera escribió:
>> Juan Martínez escribió:
>>> Alvaro Herrera escribió:
>>>> Juan Martínez escribió:
>>>>
>>>>> De hecho, yo uso una "técnica" que Postgres la permite, y hasta aquí
>>>>> nadie a dicho que sea mala (leyendo por internet)...
>>>>>
>>>>> $SQLcon = "SELECT nombre,descripcion FROM articulo WHERE id = '$id';";
>>>>>
>>>>> (En PHP esta vez)...
>>>>>
>>>>> El mal por inyeccion SQL no permitida se anula, pues lo que pongan en
>>>>> $id se considera como un string, por ende no se ejecuta, o me
>>>>> equivoco?
>>>> ???
>>>>
>>>> Preguntate que pasa en este caso:
>>>>
>>>> $id = "1'; delete from articulo; select 'nombre', 'descripcion";
>>> Lo ejecute tanto desde php como desde psql y solo se ejecuta el
>>> SELECT...
>>
>> Tienes "magic_quotes" o algo asi activado? Prueba desactivandolo.
>
> Mmm...a ver:
>
> en php.ini
>
> magic_quotes_gpc = On
> magic_quotes_runtime = Off
> magic_quotes_sybase = Off
>
> Creo que para este caso, la linea relevante es la de magic_quotes_runtime,
> si no me equivoco...de todas maneras, estas lineas vienen así desde el
> paquete de debian.
>
>> El problema es que muchas aplicaciones simplemente asumen que eso va a
>> funcionar bien, pero resulta que algun hosting tiene que desactivar
>> magic_quotes porque otra aplicacion asume que _no_ esta activo y ahi
>> empiezan los problemas.
>
> Si...entiendo...No es mi caso.
>
>> Es facil confundirse y ejecutar una aplicacion
>> que asume que magic_quotes va a estar activo en un servidor donde no lo
>> esta, y viceversa, sobre todo cuando tienes mas de una aplicacion en el
>> mismo servidor.
>
> Si. En general lo mejor es pensar que no esta activo.
>
>> IMHO esta es una falla de PHP. magic_quotes es un parche para un
>> problema real de seguridad, pero lamentablemente el parche tiene sus
>> propios problemas.
>
> Estoy de acuerdo.
> Solo para cerrar el tema. Como medida de seguridad, yo invento usuarios en
> postgres que tendrán accesos determinados para ejecutar comandos
> especificos (un usuario para los SELECT, otro para los UPDATES,...)
> exclusivos para la aplicacion web (los controlo ademas por pg_hba.conf)
>
> Cuando se trata de hacer un query que se arma a partir de algo que se le
> pregunta al usuario (en un campo INPUT type="text" por ejemplo), suelo
> tener una funcion en PHP que al recibir el dato:
>
> $texto_buscar = anti_indeseables($_REQUEST['texto_buscar']);
>
> elimina palabras claves de SQL, como precisamente "DELETE FROM ..." o
> "ALTER USER ... WITH PASSWORD ...", etc., y lo que quede se va al query...
>
> Digamos que eso me da mediana seguridad. De todas maneras es obligada la
> lectura diaria de los log de postgres (log_statement=all)...
>
> --
> Juan Martinez G.
> Departamento de Informatica
> Universidad Miguel de Cervantes
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 8: explain analyze es tu amigo
>