Evitar sql injection y xss

[Rodrigo Fuentealba]

El 26/09/07, Alvaro Herrera <alvherre en alvh.no-ip.org> escribió:
> Rodrigo Fuentealba escribió:
>
> > > porque todavía puedes quemar el equipo.
> > > Si puedes ver TV y escuchar CDs, super bien, pero cuando me lo queme el
> > > vecino que me odia no me voy a sentir muy feliz.
> >
> > Sobre lo que alega Ricardo: lo mismo ocurrió cuando a PostgreSQL le
> > cambiaron el valor default_with_oids a "off".
>
> Este es un mal ejemplo, porque el cambio de OID es simplemente una
> optimizacion.  Si lo necesitas, simplemente ponlo en ON y todo seguira
> funcionando OK.  No hay ningun hoyo nuevo de seguridad.

Sabía que lo sería.

En PHP 5 también hay un ejemplo equivalente, que es el short_open_tag,
que ahora es por defecto off, y ya no puedes escribir código
utilizando:

<? echo('Hello World'); ?>

Esto, cuando estás generando un XML, te complica con la declaración inicial:

<?xml version="1.0"?>

> El problema ocurre cuando el codigo anterior sigue funcionando sin
> cambios, por lo tanto el usuario puede hacer un upgrade, su codigo
> seguira funcionando, y no hara nada.  Dado que el codigo se interpreta
> de una manera equivalente, el problema de seguridad persiste -- con la
> diferencia de que "PHP5 es seguro", por lo tanto el usuario se queda con
> la falsa sensacion de seguridad.

Lo que Cristian y yo decimos es que PHP 5 es seguro, pero debemos
olvidar las viejas prácticas de PHP 4, por lo tanto debe hacerse una
revisión del código (que, en muchos casos, no es necesario que sea
exhaustiva). Si no existiera cambio alguno, no habrían "notas de
migración".

Ahora, idioteces como el RFI:

<?php if(isset($_GET['error'])) { include $_GET['error']; } ?>

No hay cómo evitarlas, porque no se puede modificar la mentalidad del
usuario; como mucho debería haber notas de seguridad, y las que
publica Stefan Esser son bastante contundentes en ese aspecto.

> > Lo que ocurre en PostgreSQL cada vez que se cambia de versión es que
> > debes seguir un procedimiento antes de reemplazar el motor 7.4.13 por
> > el motor de 8.2.5;
>
> Dump/reload.  En PHP no tienes que hacer nada: tomas el codigo viejo, lo
> pones en el servidor nuevo, y listo.  Sigue funcionando.

Nope. En PHP debes probar la aplicación utilizando E_ALL para
desplegar los errores más graves. Las cosas que han cambiado te
lanzarán, cuando menos, un E_NOTICE. Si tienes aplicaciones que
incluyen clases, debes revisar sus declarativos.

Sobre esto último, hasta el cansancio y en todos los boletines que leí
sobre PHP 5, se dijo "se ha reescrito el soporte para orientación a
objetos de PHP 5, soportando ahora correctamente métodos públicos,
privados y protegidos, además de incorporar interfaces, clases
abstractas, clases finales y ahora funciona correctamente la
sobrecarga de objetos.". Si los programadores fueran responsables con
sus códigos, claro que le habrían echado una mirada al changelog al
menos.

> > en PHP es exactamente lo mismo, la documentación
> > existe sobre qué hacer y en qué fijarse, pero en general los usuarios
> > de PHP no tienen conciencia de ello. ¿de quién es la culpa, si les
> > hemos dicho que lo lean?
>
> Obviamente es de quien diseñó PHP4.  Y pudiendo arreglarlo (rompiendo la
> compatibilidad hacia atras y por lo tanto forzando a los usuarios a
> cambiar el codigo), no lo hacen.

Sí, eso es claramente un error (yeah, los tipos de PHP están demasiado
lejos de ser blancas palomitas en el clásico problema PHP 4 versus PHP
5). Por ese y otros motivos (me gusta siempre lo último de lo último
que está en producción, me aseguro de que estará más tiempo en
producción), dejé de usar PHP 4.

> En Postgres, si el problema de seguridad requiere un cambio en el
> codigo que significa perdida de compatibilidad hacia atras, se hace.  La
> compatibilidad hacia atras es muy importante y se valora mucho, pero la
> seguridad se valora mucho mas.

En tal caso, critico enormemente el hecho de que PHP no haya hecho una
versión de PHP 4.9 "para laboratorio", que envíe más notices del tipo
"esto dejará de funcionar dentro de las próximas versiones de PHP".
Python hizo algo así, creo.

-- 
Rodrigo Fuentealba