Tema 03 - Sesión 03, Preparación (24/01/19)

La tercera sesión de esta asignatura será doble y en ella se trabajará con peticiones HTTP, Thingspeak y Python. Con el objetivo de preparar la sesión, se han mandado una serie de ejercicios para terminar de afianzar lo explicado en las sesiones 1 y 2

Ejercicio 01: Envío de datos con formulario

En la URI http://august-outlet-228919.appspot.com/ hay un formulario que permite obtener la letra de un DNI. Se pide: 

a ) Ver qué es lo que ocurre cuando se solicita la URI anteriormente indicada. 

Se obtiene un código 302: redirige a https://august-outlet-228919.appspot.com/html/form.html

 
b) Introducir un DNI válido y ver a qué URI se envía la petición.
La petición se envía a https://august-outlet-228919.appspot.com/obtener Letra. Como tiene espacio, en la petición este se convertirá en un %

c) Obtener los siguientes parámetros:

• Nombre del parámetro asociado al DNI: nan
• Nombre y el valor de los parámetros ocultos adicionales: ezkutua: kalkulatu

d) Editar manualmente en Burp la petición HTTP para obtener la letra y comprobar que la respuesta HTTP contiene la letra en el cuerpo del mensaje.
La petición a enviar será de la forma:

POST /obtener%20Letra HTTP/1.1
Host: august-outlet-228919.appspot.com
Content-Type: application/x-www-form-urlencoded
Content-Length: [largura_mensaje]

nan=22725983&ezkutua=kalkulatu

Donde [largura_mensaje] deberá sustituirse por el valor adecuado en cada caso. Burp lo rellena automáticamente. El valor de nan también deberá modificarse a conveniencia.

Petición de letra

Respuesta entregada por el servidor

Ejercicio 02: Enviar datos en formato formulario a ThingSpeak y recibir una respuesta vacía

Siguiendo la documentación de Matlab para trabajar con ThingSpeak se hace la petición desde Burp Suite. El canal a actualizar es el ya creado durante la sesión número 02. El formato de la petición será:  

POST /update HTTP/1.1

Host: api.thingspeak.com

Content-Type: application/x-www-form-urlencoded

Content-Length: [largura_mensaje]

api_key=[channel_api_key]&field1=[valor_campor_1]&field2=[valor_campo_2] 

• [channel api_key] habrá que sustituirlo entero por el api_key del canal.
• [valor_campor_1] y [valor_campor_2]: se deberán sustituir por lo valores que se quieren subir al canal.
• [largura_mensaje]: se deberá sustituir por la largura del mensaje (depende de cada caso y Burp lo rellena automáticamente)

La respuesta entregada por el servidor así como los datos actualizados en el canal pueden observarse a continuación:

Respuesta del servidor: está vacia

Ejercicio 03: Enviar los datos en formato formulario y recibir una respuesta en formato JSON

De nuevo, la petición será de la forma: 

POST /update.json HTTP/1.1

Host: api.thingspeak.com

Content-Type: application/x-www-formurlencoded

Content-Length: [largura_mensaje]

api_key=[channel_api_key]&field1=[valor_campor_1]&field2=[valor_campo_2]

La respuesta entregada por el servidor así como los datos actualizados en el canal pueden observarse a continuación:

Respuesta del servidor

Ejercicio 04: Enviar los datos en formato JSON y recibir una respuesta en formato XML

Esta vez la petición se hace en formato json, con lo cual cambia un poco su aspecto respecto a las veces anteriores 

POST /update.xml HTTP/1.1

Host: api.thingspeak.com
Content-Type: application/json
Content-Length: [largura_mensaje] 

{"api_key":"[channel_api_key]","field1":=[valor_campo_1],"field2":=[valor_campo_2]} 

La respuesta entregada por el servidor así como los datos actualizados en el canal pueden observarse a continuación:

Respuesta del servidor

Tema 03 - Sesión 02 (17/01/19)

En esta sesión, se ha introducido una nueva herramienta de análisis de datos:

Es una plataforma abierta basada en el principio IoT que hace uso de MatLAB para la recopilación y análisis de datos en la nube, teniendo una opción gratuita y otra de pago.

En nuestro caso se ha elegido la gratuita, que únicamente permite subir datos limitados en cantidad y tiempo, cada 15 segundos máximo. Sin embargo, para nuestro uso educacional es suficiente. El funcionamiento de este sistema es sencillo.

Los dispositivos proncipales son Smart Devices conectados a la red, los cuales recopilan datos de cualquier tipo. Estos datos, se suben directamente a este servidor en la nube, en el cual se pueden visualizar y analizar directamente desde el navegador web. Como añadido, estos datos se pueden descargar a MatLAB para realizar análisis mas detallados.

A continuación, veremos como se suben los datos a la plataforma web:

CHARTS 

Los datos almacenados se organizan de manera muy sencilla en las tablas de datos. Esto es una representación visual que es accesible desde cualquier plataforma, y tiene el siguiente aspecto:

Para introducir los datos aquí, debemos hacer uso de una API específica: 

REST API

Rest API es un entorno de programación de aplicaciones basado en MatLAB que permite realizar ciertas operaciones respecto a la base de datos ThingSpeak. Podemos encontrar diferentes apartados como los siguientes:

En este primer acercamiento, nos vamos a centrar en la subida de datos a la nube. Para ello, se han creado dos tablas vacías e idénticas a las del ejemplo previo.

Se puede realizar mediante dos funciones, GET o POST, pero nos vamos a centrar en POST en este ejemplo. La especificación API define como hay que realizar la petición de envió de datos, la cual se puede realizar de la siguiente manera, empleando el programa BurpSuite, mencionado en anteriores artículos.

Primero se va a apuntar a la dirección web apropiada:

La siguiente va a ser la realización del envío de información, para lo cual empleamos la REST API mencionada previamente. Dicho esto, la petición queda de la siguiente manera: 

Como es una petición de escritura, se adjunta en el cuerpo la clave privada de escritura. Una vez realizado todo esto, se observa el resultado:

Como el valor recibido de la petición es 200, todo esta correcto, y el dato se ha cargado completamente.

Tema 03 - Sesión 01 (15/01/19)

En la sesión del martes 15 de enero se introdujeron los conceptos de HTTP básicos.

MODELO CLIENTE SERVIDOR

HTTP se trata de un protocolo que sigue un modelo cliente-servidor: permite que un cliente indique las operaciones a realizar sobre un recurso que ya se encuentra en un servidor. Es decir, el cliente realiza peticiones, el servidor las procesa y devuelve respuestas.

Las peticiones HTTP van a ir encapsuladas en una conexión TCP, de esta forma se asegura una la entrega de los datos en secuencia y sin errores. Por otro lado, una conexión TCP viene identificada por el par (IP_Origen – Puerto_Origen)-(IP_Destino-Puerto_Destino).

Todas las aplicaciones de un ordenador tienen un puerto, que le permite al ordenador saber a dónde mandar los paquetes que llegan de Internet.

RECURSOS

La razón por la que las acciones se ejercen sobre recursos, es porque estos son la base sobre la que está montado lo que conocemos comúnmente como Internet. Así, una misma página que está formada por multitud de recursos.

Las operaciones/métodos que se pueden realizar sobre un recurso son las siguientes:

• Post: permite escribir.
• Get: Permite leer
• Put: permite actualizar
• Delete: permite borrar   

Cada uno de los recursos sobre los que se ejercen las operaciones está identificado con su propia URI dentro del servidor, que intercambia las representaciones de dichos recursos. El hecho de que se intercambien las representaciones es porque u recurso puede tener más de una representación: una página web no se ve igual en el móvil que en el ordenador, aunque esté formada por los mismos recursos en ambos casos.

TRANSACCIONES

Cada operación ejercida sobre un recurso genera transacciones. Cada transacción es independiente de las anteriores y las siguientes, y por ello en servicios que trabajan con logins se usan las cookies. Estas cookies permiten agregar cabeceras a esas transacciones, de forma que aunque siguen siendo independientes, se sigue manteniendo la sesión. 

Para cargar una página web que a simple vista puede parecer sencillas, se están realizando multitud de transacciones en unos pocos milisegundos. Por ejemplo, solo para cargar la página principal de Google se realizan 9 transacciones-. Sin embargo, para cargar la cuenta de Gmail, se realizan más de 200, que además aumentan de forma constante por estar haciendo peticiones continuas al servidor para mantener la bandeja de entrada actualizada.

PETICIÓN DE UN CLIENTE HTTP

La sintaxis de una petición HTTP es la siguiente: 

Método RequestURI HTTP/1.1
Cabeceras
CRLF*
Cuerpo del mensaje (en octetos**)

La única cabecera obligatoria siempre va a ser Host. Otras cabeceras pueden incluir información sobre preferencias de que el contenido esté comprimido o no, su idioma o formato. En general, el orden de las cabeceras no va a ser relevante para el servidor que lee la petición. Si el recurso solicitado existe en el servidor y se le pueden realizar las acciones solicitadas, a continuación el servidor va a leer las cabeceras. De esta forma podrá devolver el recurso de la manera que mejor se adapte a lo solicitado por el cliente.

RESPUESTA DE UN SERVIDOR HTTP

La sintaxis de la respuesta va a ser la siguiente:

HTTP/1.1 Status Descripción

Cabeceras

CRLF

Cuerpo del mensaje (en octetos)

Se profundizará mas en ello en la próxima sesión.

EJERCICIO BURP 

Para poner en práctica lo explicado en clase, se realiza un sencillo ejercicio en el Burp Suite. El objetivo del mismo es solicitar l página principal de Google. 

El primer paso es configurar el Target, asignando un Host y un puerto. Como es HTTP, no HTTPS, puerto 80.

A continuación, se realiza la petición. El método va a ser GET. Como se quiere la página principal, el recurso será /. El Host es el mismo que el target, y finalmente se deja la línea en blanco necesaria.

Si es correcto la respuesta devolverá un 200.

  

Sobre los códigos de respuesta también se hablará más en la próxima sesión.