Programadores PHP, PHP website admins.

[Joaz Rivera]

Pixy is a Java program that performs automatic scans of PHP 4 source code, aimed at the detection of XSS and SQL injection vulnerabilities. Pixy takes a PHP program as input, and creates a report that lists possible vulnerable points in the program, together with additional information for understanding the vulnerability.

 

Lo probe bajo unos modulos propios para Joomla y trabaja a la perfeccion.

 

 

[Noel Vargas]

URL?

> firma_email
>
>  image001.jpg
> 74KViewDownload

[Joaz Rivera]

Ups. Sorry...
http://pixybox.seclab.tuwien.ac.at/pixy/

-----Mensaje original-----
De: seguridad-softwar...@googlegroups.com [mailto:seguridad-softwar...@googlegroups.com] En nombre de Noel Vargas
Enviado el: Miércoles, 21 de Enero de 2009 01:50 p.m.
Para: Seguridad Software Libre Nicaragua
Asunto: [Seguridad SL Nicaragua] Re: Programadores PHP, PHP website admins.

[Jorge Dávila]

Por qué PHP? Hay muchas elecciones en lenguajes de programación para
web: java, python, por ejemplo, pueden resolver las mismas tareas de
forma más eficiente.

Un punto básico que se me ocurre mencionar ahora mismo, es por
ejemplo, lo que ocurre cuando llega una petición http que requiere una
consulta a una BD. El script debe leerse del disco, cargarse en
memoria, crear las estructuras de datos en memoria, colocar las
instrucciones en memoria CADA VEZ que llega la petición.

Cuando este proceso ocurre con Java o Python (hablando de Zope y
Plone) ... las clases se cargan y permanecen en memoria, dentro del
respectivo mecanismo (la máquina virtual para Java o Zope Plone). ¿Qué
se gana? En sitios web muy tráficos, la forma y frecuencia cómo son
accedidos los dispostivos de almacenamiento es relevante.

Bueno, son mis impresiones.

Saludos,

Jorge Dávila.

> firma_email
>
>  image001.jpg
> 74KViewDownload

[Jose Sanchez]

Creo que PHP tiene muchas cosas interesantes, como por ejemplo el desempeño, algo con lo cual no podían competir otros lenguajes de programación en sus albores. Cabe señalar que ese desempeño se debe en gran medida a la caché del Webserver, que no necesariamente carga del disco un script en cada request para interpretarlo. Pero es un hecho que los lenguajes interpretados siempre tendrán una desventaja con relación a los lenguajes compilados.

 

En lo personal considero que Java o .Net son más interesantes porque son lenguajes fuertemente tipados, en primer lugar, y porque extienden significativamente el concepto de reusabilidad de componentes de software. Aquí mismo, en Xolo, tenemos por ejemplo módulos totalmetne reusables, tanto para Web como en Desktop (y en un futuro en móvil). Todas las operaciones back-end son independientes de la capa de presentación, que están en JSP o bien ASPX. PHP solo nos habría servido para la capa de presentación.

Pero en general, una de las principales desventajes que encuentro en PHP es la mezca de código HTML, con Scripts (javascript), código PHP e incluso sentencias SQL. Esto es como tener todo en un mismo archivo fuente (si bien han mejorado este aspecto). Esto requiere que el programador conozca todas las tecnologías y es más propenso a falla. En otros lenguajes como .Net (MasterPages o WebParts) o Java (Templates) hemos podido separar las cosas a tal punto que la persona que prepara las interfaces gráficas, no necesita saber Java, o .Net. y el que programa la capa de negocios no necesita saber HTML (o al menos no mucho), e incluso, en teoría, no necesariamente tendría que saber de bases de datos.

 

En fin, en cualquiera que sea el caso, contar con herramientas de automatización del testeo  y vulnerabilidades del software es una gran ayuda.

 

Saludos

 

José Abelardo

[Noel Vargas]

Creo que es muy importante tocar el tema del PHP no tanto por si es
superior a otro lenguaje/tecnología, sino a la gran cantidad de
herramientas y software open source que lo usa.

Por otro lado, qué gusto verte por acá, Tito!

[Joaz Rivera]

Bueno. Tienes razon, pero, ahorita en Nicaragua esta el BOOM de Joomla,
Wordpress, etc, etc...

-----Mensaje original-----
De: seguridad-softwar...@googlegroups.com
[mailto:seguridad-softwar...@googlegroups.com] En nombre de

Jorge Dávila
Enviado el: Jueves, 22 de Enero de 2009 09:30 p.m.

Para: Seguridad Software Libre Nicaragua
Asunto: [Seguridad SL Nicaragua] Re: Programadores PHP, PHP website admins.

[Joaz Rivera]

Quiero recalcar algo que dijo el Sr. Abelardo.

“esto es como tener todo en un mismo archivo fuente”

En scripts como Joomla y Wordpress esto es un dolor de cabeza, por algo se considera por muchos programadores el lenguaje más desordenado.

Por tal razón, creo que es muy, muy importante, siempre, usar herramientas (si no se posee el conocimiento para hacerlo manualmente) para testeo de seguridad dentro de toda la aplicación.

 

De: seguridad-softwar...@googlegroups.com [mailto:seguridad-softwar...@googlegroups.com] En nombre de Jose Sanchez
Enviado el: Viernes, 23 de Enero de 2009 08:07 a.m.
Para: seguridad-softwar...@googlegroups.com
Asunto: [Seguridad SL Nicaragua] Re: Programadores PHP, PHP website admins.

 

Creo que PHP tiene muchas cosas interesantes, como por ejemplo el desempeño, algo con lo cual no podían competir otros lenguajes de programación en sus albores. Cabe señalar que ese desempeño se debe en gran medida a la caché del Webserver, que no necesariamente carga del disco un script en cada request para interpretarlo. Pero es un hecho que los lenguajes interpretados siempre tendrán una desventaja con relación a los lenguajes compilados.

> 74KViewDownload<br

[Jose Matus]

Hola a todos, este hilo comenzó con un anuncio del señor Joaz Rivera sobre una herramienta para auditar código PHP y posteriormente se convirtió en una evaluación sobre el performance de PHP.  Me gustaría retormar la idea original del hilo citando una frase del Joaz: "es muy, muy importante, siempre, usar herramientas (si no se posee el conocimiento para hacerlo manualmente) para testeo de seguridad dentro de toda la aplicación."

Me parece que al realizar un análisis de vulnerabilidades para un sitio Web (ya sea gray box, black box o wihte box testing) el uso de herramientas que busquen vulnerabilidades de forma automática es una parte de la metodología.

Si bien es cierto las herramientas para auditar aplicaciones pueden encontrar vulnerabilidades, aún no tienen el nivel esperado para dejar recaer en ellas la mayor parte de las pruebas. Desafortunadamente pueden existir personas que se dediquen al negocio de la seguridad y únicamente realicen pruebas con dichas herramientas. Ha diferencia de como opina Joaz Rivera, creo, que si no tienes el conocimiento para hacerlo manualmente, tienes dos opciones: investigas y aprendes o no hagas tu el testeo.

Estudiando sobre seguridad Web, y probando ciertas herramientas de análisis de vulnerabilidades (comerciales y open source) he encontrado manualmente vulnerabilidades que no fueron detectadas por dichos scanners. Aunque las herramientas han encontrado otras que yo no había visto.


En conclusión las herramientas de análisis de vulnerabilidades deben ser una parte de la metodología de pruebas y las vulnerabilidades que dichas herramientas reporten, deben ser siempre verificadas de forma manual.


Saludos.

José L. Matus.

--
José Luis Matus M.
Linux User #441140

[Joaz Rivera]

Muy bien,

Ahora, como funciona la mayor parte de las herramientas?

Basadas en algoritmos de detención de secuencias erróneas de SQL y validación de varibales, lo que hace el mayor numero de típicos ataques de sql injection.

Por ej, el 97% de ataques que hay con éxito en Nicaragua incuyendo el de estesa, ibw e ideay (aunque este ultimo quien sabe si diga que lo atacaron), fue por “babosadas” de validación de variables usando sql injection.

Como dice Jose Matus, no se aun de alguna empresa que brinde servicios de seguridad informática en Nicaragua, ustedes?

[Igor Guerrero]

Me pregunto... no les da pena? defender a PHP cuando saben que es algo practicamente indefendible?

Si no saben seguridad usen un Web Application framework te que oblige a sanitificar los datos enviados por el usuario y ya esta...

Y el que diga: "No es cierto!, PHP rulz!" es porque no sabe programar en otra cosa. Y si conoce cosas como Rails o Django o ASP.NET MVC, y todavia prefiere PHP, pues, tiene serios problemas.

2009/1/23 Joaz Rivera <in...@joazrivera.com>

--
Igor.

http://www.igorgue.info

[Jose Matus]

De nuevo se desvió el tema.

De una aplicación para auditar codigo fuente de PHP  pasó a  discutir sobre la calidad de PHP.

Una pregunta?? Ya salió el release oficial de MVC para .NET, la última vez que lei sobre ello estaba en una versión beta.

[Igor Guerrero]

Todavia no, segun Phil Haacked sale en Febrero el primer release candidate. Ya lo probaste?

stackoverflow.com esta escrito en ASP.NET MVC

2009/1/23 Jose Matus <jlm...@gmail.com>

De nuevo se desvió el tema.

De una aplicación para auditar codigo fuente de PHP  pasó a  discutir sobre la calidad de PHP.

Una pregunta?? Ya salió el release oficial de MVC para .NET, la última vez que lei sobre ello estaba en una versión beta. 

--
Igor.

http://www.igorgue.info

[Jose Sanchez]

Ok

 

Me voy a salir un poco del tema de seguridad para ir un poco más allá con lo que a testeo se refeire.

 

Sin ánimo de causar polémica, creo que las buenas prácticas en programación no dependen del lenguaje en si, si no más bien de la madurez del programador que asuma codificar a consciencia, y aun así siempre habrá brechas por cubrir. Algunos framework ofrecen funcionalidades inherentes a la detección automática de brechas de seguridad (como Struts o .Net), eso no significa que el programador, solo por usar alguno de esos framework, sea mejor, o que su código esté libre de errores e incluso de brechas de seguridad.

 

En general, el testeo y las buenas prácticas de programación ni siquiera están relacionadas con la posibilidad de que otro programador o usuario pueda hackear nuestro código. Les doy un ejemplo sencilo:

 

http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

 

"In the failure scenario, the primary technical causes are the Operand Error when converting the horizontal bias variable BH, and the lack of protection of this conversion which caused the SRI computer to stop."

Fíjense como un simple error de conversión de datos (overflow) hizo que la cosa fallara. Y estamos hablando de gente de la NASA. En resumen, un buen testeo no puede presuponer que dado que usamos un Framework estamos protegidos. Un framework, por ejemplo (y es bueno que hayan mencionado Rails... por Ruby on Rails), no garantiza que la integridad referencial de datos esté correcta (quienes conocen Ruby on Rails, saben que generalmente el framework maneja la integridad de datos, no la base de datos), entonces cualquier travieso puede entrar a la BD y crear registros huérfanos... por mucho que el framework pueda venir a "repararlos" después... en este escenario una integración de aplicaciones a nivel de base de datos será propensa a falla. Un framework tampoco detecta o previene race conditions, algo que muy posiblemente ocurra en aplicaciones Web, por la posibilidad de concurrecia de usuarios.

 

En resumen, es un buen tema esto del testeo de las aplicaciones, independientemente del lenguaje de programación. Algo seguro es que no se puede delegar todo al software de testeo o a la fortaleza del framework, esto sería como escribir una carta confiado plenamente en el corrector automático de ortografía (para los que usamos MS-Word). La sintaxis podría estar correcta, pero la semántica.... eso es otra cosa.

 

Les dejo un link interesante sobre los 25 errores más comunes en la programación:

 

http://www.sans.org/top25errors/

 

Saludos

 

Tito

 

Ps. Gracias Noel por la bienvenida. Un gusto saludarles a todos.

 

 

El 23 de enero de 2009 14:31, Igor Guerrero <igf...@gmail.com> escribió:

[Igor Guerrero]

Bueno el tema se desvio, pero es que no es "debatible" en mi opinion ;)

La mayoria de programadores en PHP les gusta hacer las cosas "from scratch" y por eso cometen errores, yo confio en la gente que diseña los frameworks que usa Google por ejemplo Django.

Claro que testing es importante, pero no es lo mas importante, testing importa para mantener la calidad de tus productos, pero no para incrementarla, por lo tanto si quieres tener mejor calidad contrata mejores programadores, alguien que programa en PHP from scratch y no usa un framework... que hace conecciones manuales en el "header" del su "codigo" HTML y ademas concatena cadenas para formar sentencias SQL para conectarse a la base de datos, NUNCA va a ser un buen programador.

Ejemplo simple, Django:

Tiene un ORM: por lo tanto te evitas concatenar cadenas para formar consultas SQL que es lo que basicamente permite las SQL injections, en Django nunca escribes consultas (al menos que realmente quieras), yo no escribo consultas, es aburrido es repetitivo DRY

Autoescapa los datos: Autoescapa los datos que el usuario manda por los forms, autoescapar es hecho automatico nada de codigo.

Las urls son basadas en Regex y definidas, no en el sistema de archivos: lo que evita inyecciones de codigo.

No les digo que sea perfecto, pero uff es mucho mejor que PHP.

Y no voy a hablar de los lenguajes el que compare Python con PHP necesita ayuda.

2009/1/23 Jose Sanchez <xol...@gmail.com>

Ok

 

Me voy a salir un poco del tema de seguridad para ir un poco más allá con lo que a testeo se refeire.

 

Sin ánimo de causar polémica, creo que las buenas prácticas en programación no dependen del lenguaje en si, si no más bien de la madurez del programador que asuma codificar a consciencia, y aun así siempre habrá brechas por cubrir. Algunos framework ofrecen funcionalidades inherentes a la detección automática de brechas de seguridad (como Struts o .Net), eso no significa que el programador, solo por usar alguno de esos framework, sea mejor, o que su código esté libre de errores e incluso de brechas de seguridad.

 

En general, el testeo y las buenas prácticas de programación ni siquiera están relacionadas con la posibilidad de que otro programador o usuario pueda hackear nuestro código. Les doy un ejemplo sencilo:

 

http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

 

"In the failure scenario, the primary technical causes are the Operand Error when converting the horizontal bias variable BH, and the lack of protection of this conversion which caused the SRI computer to stop."

Fíjense como un simple error de conversión de datos (overflow) hizo que la cosa fallara. Y estamos hablando de gente de la NASA. En resumen, un buen testeo no puede presuponer que dado que usamos un Framework estamos protegidos. Un framework, por ejemplo (y es bueno que hayan mencionado Rails... por Ruby on Rails), no garantiza que la integridad referencial de datos esté correcta (quienes conocen Ruby on Rails, saben que generalmente el framework maneja la integridad de datos, no la base de datos), entonces cualquier travieso puede entrar a la BD y crear registros huérfanos... por mucho que el framework pueda venir a "repararlos" después... en este escenario una integración de aplicaciones a nivel de base de datos será propensa a falla. Un framework tampoco detecta o previene race conditions, algo que muy posiblemente ocurra en aplicaciones Web, por la posibilidad de concurrecia de usuarios.

 

En resumen, es un buen tema esto del testeo de las aplicaciones, independientemente del lenguaje de programación. Algo seguro es que no se puede delegar todo al software de testeo o a la fortaleza del framework, esto sería como escribir una carta confiado plenamente en el corrector automático de ortografía (para los que usamos MS-Word). La sintaxis podría estar correcta, pero la semántica.... eso es otra cosa.

 

Les dejo un link interesante sobre los 25 errores más comunes en la programación:

 

http://www.sans.org/top25errors/

 

Saludos

 

Tito

 

Ps. Gracias Noel por la bienvenida. Un gusto saludarles a todos.

--
Igor.

http://www.igorgue.info