Un muy buen recurso para aquellos que usen PHP. Material bastante interesante.
Category: Seguridad
Artículos y opiniones sobre seguridad Web, SQL Injection, XSS, etc.
Con el slogan "Andes Libres", Anonymous está atacando en estos momentos a distintos sitios del gobierno peruano (mi país). Esto en rechazo a la "TransPacific PartnerShip Agreement", con el cuál se pretende:
- Posición extrema de los derechos de autor
- Intromisión a la privacidad de los usuarios
- Criminilazación y penalización por el uso de contenido de Internet con derechos de autor
- etc...
Los ataques empezaron a las 2:00 pm GMT-5 y hasta este momento varios sitios web del gobierno han caido.
Irónicamente, la primera web en caer ha sido la de ONGEI (Oficina Nacional del Gobierno Electrónico e Informática) que se supone que iba a soportar el ataque ya que su presidente indicó que la organización estaba preparada.
Días atrás otro grupo de hackers peruanos aprovechando vulnerabilidades de distintos sitios del gobierno, accedieron a estos y publicaron información de bases de datos y contraseñas.
Esto deja ver la mínima o nula preocupación del gobierno en invertir en seguridad o buenas prácticas en sus sitios. También muchos peruanos hablan de que estás webs están totalmente desactualizadas o simplemente no sirven.
Para saber más puedes seguir los hashtags: #andeslibres, #anonymous, #sufrocomowebmasterdelestadoperuano; o seguir las cuentas @anonopshispano o @AnonymousPeru
Lista de sitios caidos:
- onei.gob.pe
- mef.gob.pe
- peru.gob.pe
- serviciosalciudadano.gob.pe
Actualización 1:
Anonymous da por completada la fase 2 de Andes Libres
Seguiremos informando...
En la última actualización de seguridad de Worpdress se ha añadido un importante cambio que, posiblemente los desarrolladores de themes o plugins deban tener en cuenta. En el anuncio del lanzamiento no se explica en detalle los arreglos de seguridad. En este post trataré de describir brevemente estos cambios.
El 2007, publiqué un aviso de seguridad; explicaba como se permitía a usuarios no autorizados subir y ejecutar código PHP. El equipo de WordPress solucionó este problema protegiendo éstos para que no sean manipulados por el usuario. Con los años se han añadido elementos de metadatos internos y la solución anterior ya no estaba al día.
WordPress 3.1.3 añade dos nuevas funciones llamadas is_protected_meta y sanitize_meta. Éstos son usados para proteger todos los meta valores que son cambiados por métodos no standard. Como ustedes ya saben, WordPress usa claves que empiezan con un guión bajo. Por tanto, si están usando meta valores personalizados, consideren poner un guión bajo a estos para que usen la protección que es dada por el core, y también para sanitizar los datos antes de guardar y escapar antes de enviar los datos al navegador. De otro modo, incluso si se valida y sanitiza la entrada del usuario cuando se guarda, pueden tener problemas si se asume que tienen datos seguros que vienen del navegador. Estos valores pueen ser modificados usando por ejemplo admin-ajax.php.
Traducido al vuelo de: WordPress Post Metadata Security: Choosing proper post meta key names for your plugins or themes
From now on, I will write some posts in English to reach a wider audience, when I consider it necessary. My apologies if you are not interested at all --- hopefully the people who read our feed will not be bothered. Spanish translations will be published, but that will depend on how much time I have.
That being said, the latest security release of WordPress introduced one important change that, maybe, every plugin or theme developer should be aware of. Since the release announcement does not explain in detail the security fixes, I will describe briefly this change.
Back in 2007, I published an advisory concerning the post metadata. It allowed unauthorized users to upload and run php code. The WordPress core team fixed the issue by protecting them from being manipulated by the user. Over the years, new internal metadata items were added and the protection done by the previous fix, was no longer up to date.
The WordPress 3.1.3 version introduced two new functions called is_protected_meta and sanitize_meta. They are used to protect all internal meta values from being changed via non standard methods. As you may already know, WordPress uses keys that begin with an underscore. So, if you are using custom meta values, consider prefixing it with an underscore to use the protection provided by the core, and also sanitize the data before saving and escape before sending data to the browser. Otherwise, even if you validate and sanitize the user input when saving them, you may run into problems by assuming that you have safe data coming from the database. These values can be modified using for example admin-ajax.php.
No sé si todavía haya alguien que suela darle una mirada a los artículos de este blog, más aún si es alguien que conocía este sitio cuando solía escribir desvariar sobre temas relacionados a la seguridad hace unos años atrás. No sé si he escrito sobre este tema antes, pareciera ser que no tengo muy buena memoria.
Otra vez tomo como ejemplo WordPress*. Por malas decisiones que se hicieron desde el principio (por ejemplo imitar las "magic quotes"), hay muchas vulnerabilidades que hubieran podido evitarse. El problema es que muchas de las validaciones que se hacen sobre los datos enviados por el usuario, se hacen desgraciadamente casi al principio. En un mundo ideal, esto no debería causar ningún problema. Sin embargo, en la práctica hacer este tipo de cosas asegura que a medida que las aplicaciones van evolucionando, aparecerán los problemas. Muchas de estas restricciones pueden ser sobrepasadas utilizando escenarios no previstos. Luego de la publicación de la versión 3.2, que corregirá también problemas de seguridad relativamente graves, iré comentando más a detalle los problemas encontrados.
Aún cuando algunos desarroladores como Mark Jaquith recomiendan que se debe escapar lo más tarde posible (escape late), lamentablemente en este momento es algo difícil de hacer cuando la existen una gran cantidad de plugins y temas que utilizan estas "protecciones".
La lección a retener es que es mejor escapar o validar los datos justo antes de guardarlos o realizar ciertas acciones, y justo antes de enviar el contenido al navegador.
*: Como había mencionado antes, decidí colaborar en la medida de lo posible a WordPress. Actualmente estoy algo alejado de la programación, entonces seguramente habrán más posts usando WordPress como ejemplo.