Re: 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