El API de Facebook

Un perfil de Facebook está compuesto por varios elementos, todos ellos accesibles mediante el API disponible en el área de desarrolladores de Facebook (http://developer.facebook.com/).Tenemos disponibles librerías en diferentes “sabores”: PHP, Javascript (implementando un metalenguaje llamado fbml), iOS, Android, etc… Pero realmente podemos utilizar cualquier tipo de lenguaje o plataforma, gracias al API Graph (ya hablaremos de ella más adelante). Incluso, yo que soy electrónico, se me ocurre que podríamos acceder a datos de facebook desde plataformas como los Microchip PIC, Arduino, ARM, etc.. así que imaginad la potencia.El API Graph de Facebook es accesible de una manera extremadamente sencilla y abierta, y nos responde con un objeto JSON (qué le vamos a hacer, está de moda…) de la función solicitada. Esto lo podemos probar directamente en nuestro navegador:

1. Accede a tu cuenta de facebook de forma normal
2. Abre una ventana o pestaña nueva de tu navegador (el mismo con el que hayas accedido a fb)
3. Accede a http://graph.facebook.com/tioruben
4. Podemos ver un bonito objeto JSON con la info que hay disponible sobre mí, en este caso.
5. Cambia /tioruben por /tunombredeusuario o por /nombredeuncolega y verás que tenemos disponible info básica de cualquier persona o página de Facebook

Ya entraremos en detalles con el API Graph, dado que para conseguir más información (como los contactos o los post en el muro) debemos registrarnos como developers y registrar nuestro app (lo haremos en el próximo capítulo). Con ello nos darán un “access_token” que, con el permiso del usuario, nos ofrecerá el resto de la información que deseemos.

Anatomía de Facebook desde el punto de vista del API

Antes de ponernos manos a la obra hay que tener bien claro cómo se estructura esta red social. Seguro que muchos usáis facebook a diario, pero para desarrollar hay que ver el asunto desde otra perspectiva. Para Graph todos los elementos de Facebook son objetos de programación, a los que podemos acceder a sus propiedades y métodos. Estos objetos pueden ser de diferentes tipos:

• Usuarios
• Páginas
• Eventos
• Grupos
• Aplicaciones
• Mensajes de Estado
• Fotos
• Álbumes
• Imágenes de perfil
• Vídeos
• Notas
• Checkins

Como supongo que hayáis podido deducir, los objetos pueden contenerse unos a otros. Con lo que un Usuario puede contener varios eventos (a los que ha sido invitado), Imágenes de perfil, Álbumes, etc.. A su vez un Evento puede contener a varios objetos Usuario. ¿Vais viendo la potencia del asunto? ¡¡¡Y todo esto además en JSON!!!

Aclarando conceptos

Cuando me decidí a mirar esto de las apps de Facebook, yo únicamente pensaba en esas aplicaciones que corren dentro del entorno de fb, pero al ver la documentación, me dí cuenta que las posibilidades son muy superiores. Podemos utilizar el API php para hacer un app sin correr en entorno fb, pero accediendo a los datos. Además podemos utilizar el botón de “login with facebook” para poder logear a gente en nuestra aplicación utilizando las credenciales de Facebook. Podemos establecer un foro de me gusta/discusión sobre cualquier página web… es posible hacer realidad cualquier sueño de los del departamento de marketing.

Una de las cosas que deben quedar claras es que la aplicación no correrá en facebook, sino en nuestro servidor. Podemos integrarla en facebook mediante el uso del “canvas” que veremos en siguientes post. Este “canvas” no es más que un iframe en el que se carga la aplicación alojada en nuestro server, y mediante HTTP POST se envían los datos de autorización del usuario. Por tanto, es necesario tener un hosting (preferiblemente con PHP) para realizar nuestra aplicación. Sin embargo, Facebook sí que nos deja utilizar su API Javascript (ya veremos el objeto Javascript FB como mola), y algunos recursos gráficos (por aquello del look’n'feel).

En el próximo capítulo

En el próximo post veremos cómo registrarnos como developers y registraremos nuestra primera app para obtener objetos del API Graph más interesantes.

Es un proyecto que comenzamos hace un año presentando distintas propuestas entre la que fue elegida una solución programada a medida.

La nueva web cuenta con la información referente a todas las áreas del ayuntamiento, una agenda de eventos, perfil del contratante, área de noticias, tablón de anuncios, buzón ciudadano, encuestas, webcams, etc.

Se puede visitar en la dirección: www.vilademuro.net

Gracias a Dios en la edición de Internet no sale la foto de la edición impresa que no me hace justicia. : )

Enlace a la entrevista:

http://www.laverdad.es/alicante/v/20101216/orihuela/antes-gente-gastaba-dinero-20101216.html

Foto: alt1040

Hoy, como casi todos los días, me he puesto el “Hoy por Hoy” de la SER como acompañamiento en mi jornada matinal. Entre la actualidad del día, se encontraban unos datos “preocupantes” sobre la piratería en los libros electrónicos. Si no me equivoco, el origen de la noticia está en una generada por Europa Press. Pero el tema es que el grupo Prisa en pleno: SER, El País y Cuatro/CNN+ han tomado las de Villadiego con el tema (claro, a Santillana le habrá “picado”). El enfoque que le dan al tema, además de lo de siempre, es que la piratería de libros coincide con el lanzamiento de dispositivos como el iPad. Al leer además el post de Microsiervos sobre el reportaje de El País, me he animado a escribir el primer post de opinión en Green Estudio.

La verdad es que es muy fácil echar mano de estadísticas para lanzar una idea determinada que nos interese, y creo que nosotros, como usuarios, debemos ser críticos a la hora de “procesar” la información que recibimos. El sector español del negocio de los contenidos, tanto culturales, como prensa, audiovisuales, radio, etc…  creo que necesitan menos guionistas y más I+D. Su posición respecto a las nuevas tecnologías me recuerda a la reacción de cualquier yayo que te encuentres por el campo cuando le preguntas por el GPS (bueno, yo es que hago senderismo…). ¿Por qué se empeñan en demonizar todos los grandes avances que se ponen al alcance del gran público? ¿Por qué no tratan de estudiar esos avances y tratan de utilizarlos como medio de negocio?

Imagen: nanduti.com.py

Para ilustrar esto, tengo un clarísimo ejemplo en Estados Unidos: Blockbuster y NetFlix. Supongo que sabéis de qué va el caso, pero lo explico brevemente. Blockbuster es (o era) una gran cadena de alquiler de vídeo/DVD (vamos, un videoclub) con gran penetración en Estados Unidos, México o incluso gran parte de Europa (incluida España). A mediados de 2000 surgió una pequeña empresa Start Up llamada NetFlix, que proponía un revolucionario sistema de distribución audiovisual a través de Internet, con un único pago mensual y acceso a gran cantidad de películas, series, documentales, etc… Blockbuster tuvo la oportunidad de adquirir esta pequeña empresa, pero únicamente se dedicó a criticar su modelo de negocio y vaticinar su quiebra. 10 años después, en Agosto de 2010, Blockbuster avisa: “En Septiembre nos vamos a pique”. Y así fué. Ahora, NetFlix es el líder en distribución de contenidos a través de Internet. Además, su alianza con las grandes productoras audiovisuales como Fox o CBS, ha hecho crecer aún más su volumen de negocio.

Creo que queda bastante claro por dónde va mi opinión, las empresas de contenidos están a la defensiva con el tema de Internet, las TIC y la cercanía  de las nuevas tecnologías al gran público. Ojo, antes de que pique a nadie, no estoy defendiendo la descarga ilegal, símplemente creo que, para detenerla, hay que usar menos leyes y más I+D. Hace unos cuatro años, presenté un proyecto web a un cliente del gremio audiovisual, presenté y, bueno, ya estaba terminado así que no hubo pegas en ponerlo en marcha. En aquella época estaba reciente la compra de YouTube por parte de Google y yo destaqué, al final de la exposición, la importancia de investigar el tema de la distribución de contenidos de pago a través de Internet. Años después, NetFlix es algo habitual en cualquier hogar Estadounidense, grandes productoras comienzan a vender sus productos, bajo demanda, a través de Internet.

Por supuesto no es momento de acabar con el sistema tradicional, pero en vez de echar a Internet y los usuarios de nuevas tecnologías la culpa de su crisis, creo que deben tratar de poner todo ello de su lado. Y hoy, se suben los que faltaban. Los más atemorizados por el tema. Creo que los libros fue lo primero que se pudo piratear en Internet, de hecho muchas editoriales utilizaron el canal de Internet para dar servicios  de valor añadido. Entonces… ¿Qué ha cambiado? la llegada de las (odio el nombre que le han puesto en castellano) “tabletas digitales”. Hace unos años que estaba deseando la llegada de esto, es más, estaba convencido que todo el mundo deseaba la llegada de los libros digitales. Recuerdo que fantaseaba con amigos acerca de la posibilidad de descargarte “tonos” para tu libro… y, sinceramente, estaba convencido que las editoriales aplaudirían la llegada del formato de libro digital.

Estaba convencido, hasta hoy. Meses atrás recibí con alegría la llegada de Libranda, pero rápidamente mis ilusiones se vinieron abajo, al leer varios blogs. Me reconforté pensando “bueno, estamos en España, aquí tardan en funcionar las cosas…”, pero mis esperanzas en el libro digital se terminaron de disipar tras constatar que un libro electrónico era casi igual de caro que uno en papel. Ahora que me estoy poniendo al día con el tema de la impresión, realmente me doy cuenta el gran negocio de las distribuidoras y editoras en España. Pero sigo sin comprender cómo pueden dejar la oportunidad de, aunque sea, dar una oportunidad a las nuevas tecnologías.

Menos mal que hay alguna empresa que sí ha decidido dar a Internet la posibilidad de ser un canal de venta: Chello Multicanal. Esta productora/distribuidora de canales temáticos, ha decidido probar con Canal de Historia la distribución de contenidos bajo demanda. La fórmula es bien sencilla, tenemos documentales que puedes ver gratuitamente (generalmente producciones propias), o puedes ver un documental por 0,99 durante 24 horas. La oferta es la misma que la del canal (podrían poner estrenos en exclusiva por Internet), pero con un añadido que poco a poco el público demanda: “cuando yo quiera”. Yo he comprado algún documental (lo típico de que se me olvida y no lo veo por la tele) y, sinceramente, la calidad es muy buena y el precio, más bajo de lo que me esperaba. De la misma casa, está también Canal Cocina, que es pionera en aplicaciones móviles con su app de iPhone. También las productoras nacionales, a través de los canales generalistas, están distribuyendo sus contenidos a través de Internet. Aunque tal vez deban depurar un poco el rendimiento de ello, no se si la “minipublicidad” antes de que comience el vídeo generará suficiente beneficio.

Además, debemos acordarnos de Google y su intención de “atacar” el televisor de nuestro salón, so pena de Sony Internet TV, Apple TV, etc… Si juntamos las dos ideas, podemos tener un sistema de distribución de contenidos económico, cómodo y con un control de audiencias totalmente real. ¿Más beneficios?, pues por ejemplo el tema de los derechos. Ya se podrá hacer un informe totalmente real de audiencia, con lo que los pagos a entidades de derechos pueden ser mucho más justos que en la actualidad (basados en un porcentaje de beneficios).

Usad los comentarios!

En cuanto saque tiempo, lo explico…

Para poder prevenir este tipo de ataques en nuestras aplicaciones, primero debemos saber como actúan:

Twitter, como aplicación, es bastante simple: tienes un campo de texto, escribes, se almacena el escrito en una BBDD y se muestra tu escrito a todos tus “followers”. La verdad, que sin entrar en florituras, se podría hacer algo similar en apenas 30 líneas php. La tecla está en que cuando pones una URL en tu “tweet”, la aplicación de twitter devuelve un enlace, es decir, si pones:

 Mira que foto más bonica: http://www.example.com/foto.jpg

El app de twitter lo convierte en:

 Mira que foto más bonica: <a href="http://www.example.com/foto.jpg">http://www.example.com/foto.jpg</a>

Es decir, twitter reescribe el tweet añadiéndole el <a href=”"></a> para que la URL aparezca como un enlace. Esto no son más que unas líneas en PHP. Hasta aquí todo bien, pero, ¿Qué pasa si en vez de una url enviamos algo en javascript? Esto fué lo que hizo el usuario @rainbow en twitter para poder cambiar de color “engañó” al app de twitter haciéndole creer que estaba mandando una URL, cuando realmente estaba mandando un código javascript. El código empleado era similar a este:

http://miurl.com/@"onmouseover="algo_de_codigo_javascript()"/

Algo que el app de twitter tradujo como:

<a onmouseover="algo_de_codigo_javascript()" href="http://miurl.com/@">http://miurl.com/"onmouseover="algo_de_codigo_javascript()"/</a>

Como vemos, es un enlace que ejecuta la función algo_de_codigo_javascript() al pasar el ratón por encima. A priori esto no debería ser muy grave, ya que el código se ejecuta en la máquina cliente de los followers del atacante, y los navegadores actuales son relativamente seguros respecto a los scripts que se ejecutan en ellos. Pero estamos en la época de ajax. En twitter, tenemos la posibilidad de retwittear algo que nos interese, y ello hará aparecer un tweet en la lista de followers. Basta con que la función javascript utilice el api AJAX de twitter para que conforme alguien pase el ratón sobre el enlace anterior, retwetee el mensaje a sus followers de forma automática. Ya tenemos los ingredientes de un virus. A esto, el atacante, añadió un par de popups con algo de porno y ya tenía a los desarrolladores de twitter en jaque. Potencialmente, todas las aplicaciones de la web 2.0 (blogs, comentarios en periódicos, redes sociales, etc…) son vulnerables a estos ataques…

…Pero un ataque tan sencillo, tiene una solución y prevención igualmente sencilla: expresiones regulares. Sinceramente, es para mí lo más complicado de la programación. De hecho, no suelo crear yo muchas de ellas (ya que las cosas más comunes suelen existir en librerías de exp. reg.). Básicamente debemos crear una expresión regular que, en el contexto de nuestra aplicación, impida que este tipo de textos sea interpretado como un enlace. Una manera un poco chabacana y en plan cutre-rápido sería algo como esto:

$contenido_del_usuario = str_replace("javascript:","",$_POST['contenido_del_usuario'];

Repito, algo chabacano, ya que si por ejemplo alguien escribe “hola os pongo un ejemplo de javascript: blah blah blah blah” sería sustituido por “hola os pongo un ejemplo de blah blah blah blah”. Lo suyo es utilizar expresiones regulares. En esta dirección: https://fosswiki.liip.ch/display/BLOG/XSS+Prevention podéis encontrar muchas regexp para prevenir ataques XSS en nuestras aplicaciones. Por otro lado, podemos tener en cuenta también una serie de buenas costumbres al respecto:

• Tener siempre activo en el php.ini la opción magic_quotes. Esto escapa todas las comillas introducidas por POST o GET (es decir, convierte ” ‘ ” en ” \’ “) para evitar que sean tomadas como contenido de una propiedad. Ello además impide otros ataques, como el SQL Injection.
• Tratar todos los textos libres del usuario con addslashes();
• Impedir, si no es necesario, que los usuarios introduzcan tags html en comentarios, posts, etc… ello se puede hacer fácilmente con strip_tags(); Además, esta función de PHP permite “dejar paso” a algunos tags, como por ejemplo <b> <u> <strong>, etc…

Respecto a aplicaciones OpenSource tipo WordPress, Joomla, Mambo, PHPBB, etc etc debemos procurar tener éstas actualizadas a la ultimísima versión, ya que suelen ser carne de cañón para los que investigan vulnerabilidades de este tipo. De momento, la mayoría de las versiones estables suelen ser comprobadas para este tipo de vulnerabilidades.

En esta primera entrega sobre prevención de ataques en aplicaciones web hemos visto (para mí) una de las maneras más elegantes de hacking de apps web 2.0. Elegante? sí, ya que en ningún momento se toca nada del servidor, y se pueden desarrollar contramedidas fácilmente. Además, estos ataques suelen ser realizados por hackers, no crackers, con lo que la única intención que suele haber en ellos no es más que la de informar que no se ha tenido en cuenta estas vulnerabilidades. En la próxima entrega hablaremos de una “añeja” forma de hacking web, que es el SQL Injection, ya casi en desuso.

Ataques XSS famosos de los últimos tiempos:

• Twitter
• Facebook
• Presidencia española de la UE (este fue bueno, jajajaja, ni se sabe la de dinero que se gastaron en la web, y encima no tiene en cuenta el XSS…)
• Creo que Tuenti también sufrió alguno
• PayPal (acojona, eh…)
• Orkut
• … y supongo que no habrán más porque no se habrá intentado…