Seguridad en las APIs – El caso snapchat

En esta economía globalizada que nos ocupa, y a veces nos preocupa, uno de los elementos en los que más se trabaja es en la construcción de una marca, la publicidad, el marketing, y como no la construcción de un producto. Un gran esfuerzo que muchas veces es tirado por tierra por un error que cause un gran impacto mediático.

Habitualmente cuando hablamos de productos que involucran un API, este impacto mediático suele venir por un problema de seguridad en esta API. Datos robados, información de usuarios desvelada, seguridad comprometida, caída del servicio, son algunos ejemplos de algo sobre lo que estamos acostumbrándonos a escuchar.

En el último año snapchat, el whatsapp americano, nos está proporcionando una fuente inagotable de noticias, y habitualmente desagradables.

Primero fueron advertidos por parte de la comunidad de que el diseño de su API podría causar fugas de información, dicho y hecho al pasar de los meses los números de teléfono de sus usuarios fueron extraídos usando su API, y un porqué no decirlo una infinita paciencia para descargar tanta información.

¿Es esto tan difícil de proteger? Situar una capa de seguridad por delante de la capa de negocio, que preventa la salida de información confidencial, grandes cantidades de información no es una tarea complicada con un API Gateway. 4,6 millones de usuarios a mi me parece un numero suficientemente elevado como para tomarlo en cuenta.

Aparentemente filtrar los números de teléfono de todos los usuarios de un servicio no parecía algo suficientemente jugoso, con lo que nos hemos desayunado con otro fallo de seguridad, esta vez algo más picante.

16 Gb de fotos intimas de miles de personas anónimas (200.000) puestas a disposición de todo aquel que tenga un poco de curiosidad.

Lo curioso es que desde snapchat sólo echan balones fuera, cuestión que si no fuera por su trayectoria, sería más creible.

En este caso, el problema parece la gestión de los accesos al API, que posiblemente no se estaba realizando de una forma suficientemente segura. ¿Seguiremos relacionando esta marca con fallos de seguridad, esperemos que no?

Advertisements

¿Qué es un Web API?

I’ve translated this post in my new site, you can find it under What’s a REST API?.
Siempre que veo algún tipo de presentación, demo, evento o similar relativo a las Web APIs en todas las ocasiones se define un API (Application Programming Interface) como aquél conjunto de funciones y procedimientos que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción (fuente wikipedia ).

Lo cual está muy bien, pero solamente define una parte de lo que actualmente entendemos como API, además de todas las implicaciones del término API actualmente. Por ello yo lo tiendo a llamar Web APIs.

Un Web API REST, es un conjunto de funciones y procedimientos de creación, consulta, actualización y borrado (CRUD – Crear, leer, actualizar y borrar) sobre objetos de negocio. De esta forma se expone el objeto de negocio sobre una cierta url (http://example.com/v1/user) y con distintos métodos ( PUT – Crear, GET – Leer, PUT – Actualizar, DELETE – Borrar) se opera sobre estos objetos de negocio. Habitualmente este conjunto de funciones se exponen fuera de la compañía para permitir ciertas operaciones de B2B, lo que dicho de otra forma no es más que facilitar el acceso a los servicios de la compañía para las empresas con las que la nuestra hace negocio.

Con el boom de la Web 2.0 más y más sitios ofrecen un API que permite realizar ciertas funciones o procedimientos. Por ejemplo tomando el API de Twitter, se pueden publicar tweets, y extraer informaciones como tweets filtrados por ciertos parámetros, o incluso estadísticas. Lo cual ha permitido la creación de más negocio sobre estos servicios (APIs), en sitios que integran Twitter, Facebook, Linkedin,y otras redes sociales para poder hacer seguimiento por ejemplo de campañas publicitarias.

Entre las preocupaciones de exponer estos objetos de negocio a terceros, están saber cómo debo dimensionar mis sistemas para dar cabida a esta nueva vía de negocio, cuál de mis interlocutores de negocio hace más uso del API, medir este uso, ¿cómo autorizo a los usuarios de mi plataforma a consultar, crear, modificar y borrar desde la plataforma de un tercero?, y sobretodo prevenir que haya accesos no autorizados, ni extracción de información confidencial (ya sea por un interlocutor de negocio, o por un hacker de la competencia).

Sobre la base de las preocupaciones más básicas comentadas, se han ido desarrollando mecanismos para la identificación de consumidores mediante tokens, herramientas de monitorización y reporting automático sobre esta monitorización, mecanismos de autenticación ( OpenID ) y autorización ( OAuth ), y mecanismos para definir distintas políticas de seguridad sobre las APIs expuestas.

No obstante este modelo, ni está presente en todas las compañías, ni creo que sea el modelo idóneo en los próximos años. En los próximos posts pretendo hacer una distinción entre este modelo de acceso directo a los datos, y otros modelos en los por ejemplo que se distingue entre un API pública (public API) y otras APIs privadas (prívate APIs).

Protección de APIs frente a Inyección de código

Una de las amenazas a las que cualquier API está expuesta es el ataque de inyección (sql injection, ldap injection ), que no por conocido deja de estar entre la lista de ataques que mejores resultados producen a la hora de obtener acceso a grandes cantidades de información, o la mejor forma de destruir la información existente.

¿De qué forma podemos detectar que al recibir una llamada a un método esta incluye algún contenido malicioso que pueda ocasionar daños al servicio expuesto?

Debemos tener en cuenta que el contenido malicioso puede encontrarse en cualquier cabecera http, en la query string, o en el propio contenido de la petición.

El mecanismo habitual es contrastar con un conjunto de expresiones regulares que definan los diferentes casos de inyección: select * from users, delete from users, ‘ or 1=1–, ‘ or ”=’.

Una vez definido el conjunto de expresiones regulares el objetivo es aplicarlo a las distintas llamadas al API que queremos securizar.

Algún ejemplo de expresiones regulares, para los casos que comento, serían:

delete from users

       (?i)\s*delete\s*\w*\W*\s+from

‘ or ”=’

       (?i)’\s+or(‘|”|\s+)

¿Pero cuál es exactamente la base del problema?

Normalmente cuando accedemos a una base de datos tenemos diversas formas de hacerlo:

a)      Creamos una consulta, le añadimos el parámetro que hemos recibido en la llamada al método del API, y posteriormente la ejecutamos.

String query = “SELECT user FROM users WHERE user_name = ” + request.getParameter(“customerName”);

 

b)      Usamos un prepared statement, al que pasamos como parámetro aquél que hemos recibido en la llamada al método del API, y posteriormente lo ejecutamos.

String cName = request.getParameter(“customerName”);

String query = “SELECT user FROM users WHERE user_name = ? “;

PreparedStatement pstmt = connection.prepareStatement( query );

pstmt.setString( 1, cName);

 

c)       Utilizar procedimientos almacenados en la base de datos, a los que llamamos desde nuestra API.

        String cName = request.getParameter(“customerName”);  CallableStatement cs = connection.prepareCall(“{call sp_getAccountBalance(?)}”);        cs.setString(1, cName);

 

El defecto que plantea utilizar la primera opción, que es la más usada, es que permite que cualquiera que sea el contenido del parámetro “customerName” va a ser usado dentro de la query que se lanza ( select * from xxxx, drop table yyy, … ), y sólo los privilegios que dicho usuario tenga dentro del gestor de base de datos le frenarán de parar el motor de base de datos, o cualquier otra fechoría.

Aunque siempre debe verificarse que los parámetros no contengan ninguna inyección de código, las opciones b y c son más seguras y sólo depende del diseño de la solución el usar una u otra.

¿Cuál es la recomendación? Utilizar una solución de seguridad perimetral que impida que dichas llamadas a los métodos del API crucen siquiera la DMZ, y a su vez detectada la amenaza notificar al SIEM para que sirva de punto de detección de otros patrones.

API Workshop en Madrid – 10 de Julio

Después de participar en varios API Workshops en la región europea, nosotros los estamos llamando Tech Labs, el próximo 10 de Julio tendrá lugar el API Workshop en Madrid.

¿Pero que es un API Workshop? Es un evento diseñado desde el punto de vista más práctico, y con la intención más clara de que los participantes puedan configurar ellos mismos su solución a un problema. Por eso también lo denominamos tech lab, o laboratorio de tecnología.

Durante una mañana, centramos el tema principal del API Workshop entorno a la economía de las APIs, la realidad del B2B respecto a las APIs y servicios web, la gestión de comunidades de desarrolladores (B2D – Business to Developer).

Después de las presentaciones lo más importante va a ser el utilizar los puestos disponibles para la configuración de los distintos casos de uso que proponemos durante la sesión:

  • Gestión de APIs, la exposición de un API existente, con el gobierno de su uso desde el punto de visto de monitorización de explotación, identificación de aplicaciones usuarias, y control del ciclo de vida.
  • Securización de WebServices, encontramos muchos casos de mezcla de lógica de negocio y seguridad, en este caso de uso establecemos una capa de seguridad sobre servicios web existentes de forma que establecemos un PEP (Policy Enforcement Point).
  • Conexión con la nube, integrar tus aplicaciones en el datacenter con aquellas soluciones existentes en la nube puede ser un caso de uso encima de tu mesa hoy. Nuestros participantes configurarán un escenario de acceso a Salesforce.com.
  • Si gestionar los servicios (APIs o SOAP / WOA o SOA) existentes es un problema para ti, podrás aprender a utilizar la tecnología de API Gateway para gobernar tus servicios existentes y establecer un sistema de cuotas sobre ellos.

 Y como puedes leer, todo desde un punto de vista meramente práctico, con ejemplos de la vida real, y una exposición sobre casos de usos reales de hoy en día.

Si quieres participar en un evento de estas características puedes Registrarte gratis para el API Workshop.

 

 

 

Integración con la nube

Es uno de esos temas que durante los últimos años me han tenido bastante humm digamos atareado, la integración de aplicaciones.

La integración de aplicaciones está siempre en el centro de lo que hago, y a ciencia cierta que con el advenimiento de la nube plantea nuevos retos y no menos quebraderos de cabeza a un arquitecto empresarial.

 

Los formatos

Uno de estos retos es la utilización de aquellos formatos de mensaje que sean compatibles en ambos lados de las aplicaciones a integrar, en nuestro caso particular nos encontraremos con aplicaciones en la nube que nativamente exponen un interfaz en formato JSON, que nos facilita sobretodo la integración. Si nos detenemos a hacer un cálculo en base al número de transacciones por segundo, contra el tamaño medio de ellas, podemos darnos cuenta de la gran ventaja contra el otro formato habitual en la nube, XML.

Dentro de las aplicaciones que tendremos dentro de las instalaciones de la empresa, en algunos afortunados casos tendremos una capa normalizada en formato JSON, que nos permita hacer una integración sencilla con la nube. En otros casos el interfaz será XML, y con una pequeña transformación de formato podremos tener la integración entre ambos mundos finalizada de una forma rápida.

Hay un tercer caso, si nos ceñimos puramente al formato de los datos, en el que el formato de los datos es texto plano, bases de datos, o cualquier combinación de todos los anteriores. A veces esta complicada arquitectura de datos nos hace ver el firewall como una barrera para enfrentarnos al exterior, más que aquella barrera que nos protege de los intrusos.

Nada más lejos de la realidad, es entonces cuando la figura de una capa de mediación que siendo capaz de trabajar nativamente en el formato JSON, nos permita exponer aquellos servicios web SOAP, servicios REST, servicios EJB, servicios expuestos como procedimientos de bases de datos, o incluso servicios del Mainframe. Entender todos aquellos formatos, y exponerlos como una única capa normalizada nos facilita enormemente la integración de datos entre ambos lados del firewall.

 

¿Quién es Quién?

El segundo reto, de otros muchos que seguiré comentando, es la gestión de las identidades entre ambas aplicaciones a integrar. Dependiendo del caso de uso, tendremos una serie de usuarios de una aplicación en la nube, que no necesariamente tienen que corresponder con los mismos en las aplicaciones internas. En este caso, ser capaz de entender ambos sistemas de gestión de identidad, y poder realizar la mediación entre ambos para poder realizar una más que necesaria federación de identidades.

 

¿Cuál es la ventaja principal para un usuario?

Más allá de la conveniencia para un arquitecto empresarial, o para la gestión de TI, el propósito principal es tener una única visión para los usuarios finales, independientemente de dónde se encuentre la aplicación, e incluso de si la aplicación final es una conjunción de dos aplicaciones como es el caso. Y sobre todo para un usuario, sin tener que recordar diferentes contraseñas y para el que al final la gran ventaja es que las aplicaciones sobre las que trabaja le presentan un único interfaz, utilizando aquellos servicios que los arquitectos empresariales han designado a tal efecto.

 

IoT ya no es el futuro, el futuro está aquí

Leyendo sobre Internet Of Things (IoT), internet de las cosas, me viene a la memoria todo aquello que ya dijimos sobre el futuro hace no tanto. Como que en el año 2000 todos iríamos en coches voladores, usaríamos trajes brillantes, o similares.

Y la cuestión es si, ¿estamos esta vez en la misma tesitura con los 25 billones (americanos imagino) de dispositivos conectados en 2015 que Cisco prevé? . Ejem, y para 2020 Gartner prevé 26, mientras Cisco ya va por los 50 billones.

Si que parece que millón arriba, millón abajo, la idea cuaja y que cada vez una proporción mayor de los dispositivos están conectados a la red de redes, construyendo así una red de cosas, incluso algún avezado hacker ya añadió a su red de dispositivos (BotNet) un frigorífico para hacer algún tipo de ataque DDoS.

Leo en Forbes, y me gusta, acerca de distintas aplicaciones médicas para un internet de las cosas, una red en la que los elementos cotidianos que tenemos nos envían mensajes de distintos tipos.

  • Inyector de insulina que me avise cuando me toca la próxima inyección, o que lleve la cuenta de las que me he ido poniendo.
  • Monitores de bebés, tener una cosa en internet que me avise de que mi peque está teniendo dificultad para respirar, o que tiene fiebre me parece algo tan necesario, y sobre todo, que me avise a mi móvil en vez de a este dispositivo que nunca sé donde enchufar.
  • Gestor de pastillas, un gadget que se me antoja necesario para una población cada vez más necesitada de medicamentos, y cada vez más enganchada a internet. Aunque el invento en sí es una pastilla que ella sola informa de su ingestión, el hecho de que mi gestor de pastillas me avise que hace unas horas que no lo abro, cuando debería haber tomado mi dosis de antibiótico me parece muy útil también.

Y seguro que muchos más gadgets y aplicaciones para asistencia, pero sobretodo un eficaz sistema de Web APIs con el que poder controlar y gestionar los datos privados de estas herramientas tan personales, así como controlar los accesos a estos nuevos gadgets, y la información que proporcionan.

Otra de las cuestiones importantes, es de si es posible generar las APIs que deben ser consumidas por las aplicaciones finales, que normalmente se van a encontrar en la palma de la mano del usuario final [móvil, tablet, phablet, …], y que deben proveer el necesario control y gobierno, así como la protección frente a los ataques más rabiosos.

Disponer de una adecuada estrategia de gestión de APIs, con la necesaria seguridad, es posible y controlar las apps que están consumiendo las APIs expuestas, así como los procesos empresariales subyacentes, es hoy en día una realidad más allá de los sueños más futuristas que tuviéramos en los 80.