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". Leí que algunos usaban > el OID como primary key dentro de sus modelos de datos, y que > reclamaron aún cuando la razón de este cambio es que usar el OID como > PK es para evitar una mala práctica de programación.
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. 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 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. > 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. 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. -- Alvaro Herrera http://www.advogato.org/person/alvherre "La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez) From [EMAIL PROTECTED] Wed Sep 26 19:37:35 2007 From: [EMAIL PROTECTED] (Rodrigo Fuentealba) Date: Wed Sep 26 19:40:02 2007 Subject: Evitar sql injection y xss In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> El 26/09/07, Alvaro Herrera <[EMAIL PROTECTED]> 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
