Evitar sql injection y xss

[Rodrigo Fuentealba]

El 26/09/07, Alvaro Herrera <alvherre en alvh.no-ip.org> escribió:
> Rodrigo Fuentealba escribió:
> El problema a que apunta Ricardo no son las capacidades, sino los
> problemas.  Si la banda AM te permite (supongamos) quemar la radio
> cuando se reciba una señal determinada, entonces el equipo nuevo es
> igual de vulnerable si tiene AM

Pasemos de la metáfora entonces, a un ejemplo esencial. No me meteré
en XSS ni nada de eso (no me quiero quebrar la cabeza para ello), es
solamente la forma correcta de hacer las cosas en PHP 5.

PHP 4 te permite hacer algo como esto:

<?php

   class Test
   {
      var $valor;

      function funciontest()
      {
      }
   }

?>

PHP 5 también te lo permite. Sin embargo, la manera de interpretarlo
es la misma que si escribieras:

<?php

   class Test
   {
      public $valor;

      public function funciontest()
      {
      }
   }

?>

Si escribes todas tus propiedades y métodos de manera pública, tendrás
luego un posible problema de seguridad, si utilizas la posibilidad de
autocarga de objetos que trae PHP 5.

A eso apunta Cristian y a eso apunto yo cuando decimos que mucho del
código que sea escrito en PHP 4 estará mal diseñado, aunque pueda
correr en PHP 5. Hay una cantidad de cosas que están plenamente
diseñadas y que deberíamos considerar.

- http://www.php.net/manual/en/migration5.php

Si nos vamos a:
http://www.php.net/manual/es/migration5.incompatible.php, vamos a ver
bastante información sobre las cosas que han cambiado.

> 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.

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; 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? (no, no desarrollo el lenguaje PHP pero soy
responsable de él en una distro).

Saludos,

-- 
Rodrigo Fuentealba