Evitar sql injection y xss

[Rodrigo Fuentealba]

El día 26/09/07, Aldrin Gonzalo Martoq Ahumada <amartoq en dcc.uchile.cl> escribió:
> On 9/26/07, Alvaro Herrera <alvherre en alvh.no-ip.org> wrote:
> > 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.
>
> Quiero secundar la opinion de Alvaro. No estoy diciendo que la
> solucion es algo fuertemente tipado (como Java, que es otro cuento tan
> complejo que al final terminas teniendo los mismo problemas de algo
> mas "liberal").
>
> El problema del codigo PHP es que sigue siendo igual de malo en el
> sentido de los resultados que permite. Basta ver todos los phpnuke
> botados en todos estos an~os, ver la cantidad de esfuerzo que se gasto
> en tratar de mejorar la situacion y aun asi deben haber miles de hoyos
> "por descubrir" hasta el dia de hoy.

Los problemas de PHPNuke y Joomla no son problemas de PHP per sé. Es
como si le echara la culpa de los problemas de MySQL a que está hecho
en C, cuando PostgreSQL también está hecho en C y no tiene tantos
problemas (no diré que no tiene, porque al fin y al cabo es código
hecho por humanos, pero sólo por ello).
Para algo existen las buenas técnicas de programación, ¿no?
> Y esto es anti-natura de una de las mejores caracteristicas que ha
> seguido todo el software libre: reinventarse botando a la basura (sin
> asco) las cosas malas y horribles.

PHP recién con su versión 4 comenzó a "profesionalizarse". A
diferencia de Python, Andy Gutmans y Zeev Zuraski lo tomaron a cargo
porque su sintaxis era simple. Estaba hecho para analfabestias.
>  Uno de los ultimos ejemplos es
> Python3k, y es una de las cosas que mas me agrada y valoro;

¿Python 3K es el que te dice qué va a fallar en una próxima versión y
qué no, verdad? Yo estoy haciendo cosas con Python 2.5 todavía, pues
lo estoy aprendiendo.
> basta ver
> toda la mi*rda que trae windows "para poder correr la aplicacion DOS
> de facturas de hace 20 an~os".

No entendí el ejemplo de Windows, aunque podría comentarte cosas que
me causan gracia sobre la imbecilidad de quienes hicieron los objetos
DCOM.
> El CakePHP es malo porque permite escribir las leseras de ejemplos que
> salian en el articulo. Esos ejemplos eran horribles. No por los
> problemas que solucionan, sino por la cantidad de resultados
> "inesperados" que generan. Esos resultados inesperados pueden ir desde
> no poder escribir el apellido compuesto de Horst von Brand hasta
> dramas serios de seguridad o integridad de datos.

...sobretodo cuando se mezcla con MySQL, ¿cierto?
<script type="text/javascript">
  document.getElementById("darkprox").display = none;
  document.getElementById("darkprox").visibility = hidden;
</script>
> Eso es lo malo, eso debe botarse a la basura, por favor!!

¿Botemos el código PHP 4? Conforme. Pero antes, evaluemos si realmente
es necesario botar un buen código escrito en PHP 5.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas - Consultor UNIX - Database Administrator