Que es un Token

Lo primero que debemos de entender, es que es un token, pues será un concepto fundamental para entender el resto del artículo.

Un token es una cadena alfanumérica con caracteres aparentemente aleatorios, como el siguiente:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

o el siguiente:

24353689

Estas cadenas de texto, pueden no aparentar un significado, sin embargo, tiene un significado real para el servidor o institución que lo emitió, el cual puede entender y así, validar al usuario que intenta acceder a la información, e incluso, puede tener datos adicionales.

Te dejo un video donde explico que es un Token:

Un caso simple de tokens, es el dispositivo que dan los bancos para realizar transacciones desde internet, este token te genera un valor numérico que luego tenemos que ingresar al sistema, para que de esta forma, el portal pueda asegurarse de que efectivamente somos nosotros y no un impostor.

En el caso de los tokens bancarios, no se almacena una información real dentro del Token, sino que simplemente es un valor generado que luego puede ser validado por el banco como un valor real generado por nuestro token. Sin embargo, con JWT podemos enviar cualquier dato del cliente dentro del token para que el servidor pueda obtener mucha más información de nosotros.

Que son los JSON Web Tokens

Bien, una vez que comprendemos que son los Tokens podemos decir que los JWT son un tipo de token el cual engloba una estructura, la cual puede ser desencriptada por el servidor y de esta forma, autenticarnos como usuario en la aplicación.

Veamos la estructura de un JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Observemos que la cadena está dividida en 3 secciones separadas por un punto. Estas tres secciones tienen un significado:

1. HEADER: la primera parte, corresponde a los Header, y se almacena por lo general el tipo de token y el algoritmo de encriptamiento.
2. PAYLOAD: La segunda parte, contiene los datos que identifican al usuario, como puede ser su ID, nombre de usuario, etc.
3. FIRMA: La tercera parte es la firma digital, la cual se genera con las secciones anteriores y sirve para validar que el contenido no haya sido alterado.

Ejemplo del Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Ejemplo del Payload

{
  "id": "1234567890",
  "name": "Oscar Blancarte",
  "rol": “admin”
}

La firma por otra parte es el header y el payload en base64 y después encriptado.

Puedes leer más de JWT en su página oficial

Como se utiliza los JWT

Como ya hablamos, los JWT se utilizan para autenticar a los usuarios, para ello, el usuario requiere de un login tradicional como es el usuario y password. Una vez, que el sistema de Backend valida que el usuario y contraseña son correctos, este retorna un token al usuario. Este token lo deberá guardar el cliente, pues de aquí en adelante, todas las peticiones que realice al servidor, deberá llevar el token.

El token es por lo general almacenado en Cookies o en el LocalStorage del navegador, y cuando es requerido enviar un request al servidor, se recupere y se envía como header.

Un dato interesante del token es que no requiere que el servidor lo almacene para compararlos cuando lo envíe el cliente, pues el token por si solo puede ser auto validado, y como tiene un payload, es posible determinar de quien es el token. Veamos el siguiente payload:

{
  “userID”: 12345,
  “username”: “oblancarte”,
  “rol”: “admin”
}

Cuando el servidor desencripte el token, podrá recuperar este payload y con ello, podrá saber que usuario es e incluso, es posible guardar datos adicionales como el rol o cualquier dato en formato JSON.

Otro dato interesante del token es que expira, es decir, el token solo es válido por un tiempo determinado. Por lo que el usuario deberá volverse a logear una vez que el token expire.

Veamos cómo funcionaría todo el ciclo de vida de un JWT

Ya hemos hablado de como JWT funciona, pero ahora entraremos a ver como es la interacción que tiene un usuario al autenticarse por medio de JWT, para lo cual veamos la siguiente imagen:

Los pasos son los siguientes:

1. El usuario requiere de una autenticación tradicional con el servidor, es decir usuario y password (o cualquier otro tipo de autenticación).
2. El servidor validará que los datos introducidos sean correctos y generará un Token.
3. El servidor enviará el token al usuario y este lo tendrá que almacenar de cualquier forma.
4. Una vez con el token, el usuario realiza una petición al servidor, enviando en el header el token previamente generado.
5. El servidor validará que el token sea correcto, desencriptandolo mediante la misma llave que utilizo para encriptarlo.
6. Si el token es correcto, entonces el servidor retornará los datos solicitados.

Cabe mencionar que los puntos 4,5 y 6 se pueden repetir indeterminado número de veces hasta que el token caduque, cuando esto pase, entonces será necesario reiniciar desde el paso 1.

Como implementar un JWT

Existe una serie de librerías que nos permite crear un JWT, y todo dependerá del lenguaje que utilicemos. Sin embargo, quiero mostrarte como crear un JWT con NodeJS.

Lo primero, es que será necesario importar el módulo jsonwebtoken:

npm install –save jsonwebtoken

Generación del Token

ya con la dependencia instalada podemos crear el token de la siguiente manera:

var jwt = require('jsonwebtoken')

function generateToken(user) {
  var u = {
   username: user.username,
   id: user.id
  }
  return token = jwt.sign(u, ‘password’, {
     expiresIn: 60 * 60 * 24 // expires in 24 hours
  })
}

Lo primero que haremos será crear una función que reciba el objeto usuario o cualquier otro objeto que contenga la información requerida para la autenticación. Luego mediante el objeto usuario, creamos el objeto u, el cual solo contiene el username y el ID del usuario. Este objeto se convertirá en el payload del JWT, es decir la segunda parte del token.

Seguido, procedemos a crear el token mediante el módulo jwt, el cual nos proporciona el método sign que recibirá el payload y un password, este password deberá ser secreto, pues con él, podremos crear y desencriptar los tokens. Finalmente, el tercer parámetro son las opciones, aquí podremos seleccionar el algoritmo de encriptación, la fecha de expiración, etc.  En este ejemplo dejamos la configuración por default, pero agregamos que el token sea válidos solo por 24 horas.

Finalmente, el token es retornado al cliente.

Validación del token

Hasta este punto solo hemos visto la parte de la generación del Token, pero falta la segunda parte, en donde tenemos que validar que el Token que el cliente nos manda, es válido.

Para validar el Token podemos utilizar un Middleware de Express que valide de forma automática todas las URL que inicien con /secure. El middleware se ve de la siguiente manera:

router.use('/secure',function(req, res, next) {
  var token = req.headers['authorization']
  if (!token) {
    res.status(401).send({
      ok: false,
      message: 'Toket inválido'
    })
  }

  token = token.replace('Bearer ', '')

  jwt.verify(token, ‘password’, function(err, token) {
    if (err) {
      return res.status(401).send({
        ok: false,
        message: 'Toket inválido'
      });
    } else {
      req.token = token
      next()
    }
  });
});

Podemos ver que en la primera llínea inicializa el middleware, luego en la segunda línea obtenemos el token del header “authorization”. Si el token es Null regresamos un 401 indicando que no el cliente no tiene privilegios.

Los token generados por JWT se crean con la palabra “Bearer” al inicio del token, por lo que en la línea 10 quitamos esa parte del token, seguido, en la línea 12 realizamos la validación del token mediante el método verify.

Este método recibe el token como primer parámetro, como segundo parámetro, mandamos el password para desencriptar el token. Finalmente se envía como tercer parámetro una función Callback una vez que el token sea validado.

Si todo salió bien, el token estará en la variable token, en caso contrario, tendremos el error en la variable err.

Conclusiones

Como pudimos ver, los tokens son una magnifica forma de administrar la autenticación de los usuarios, pues permite crear de forma fácil, un mecanismo para comunicarse de forma segura entre el cliente y el servidor, además, de que permite mantener autenticado a un usuario por un tiempo determinado, evitando tener que iniciar sesión cada vez que entre a nuestra aplicación.

The post Autenticación con JSON Web Tokens appeared first on Oscar Blancarte - Software Architecture.

Probablemente hallas escuchado el termino SQL Injection  o Inyección de SQL y es que es uno de los ataques más frecuentes a los sistemas informáticos en la actualidad. Pero que es exactamente SQL Inyección y cómo es que un Hacker puede aprovechar esta vulnerabilidad para atacar los sistemas. Pues estas preguntas las resolveremos en este artículo.

La inyección de código es el método por medio del cual es posible infiltrar código SQL a través de los parámetros que utilizan las aplicaciones para generar las consultas en el BackEnd. La inyección es posible debido a al descuido o la ignorancia a la hora de escribir el código, dejando vulnerable a la aplicación para recibir “parámetros” que en realidad son sentencias de SQL adicionales, que luego son ejecutadas en la base de datos si el conocimiento de los administradores del sistema.

Este tipo de ataques se da en aplicaciones que generan las instrucciones SQL al vuelo o cuando se concatenan los parámetros a una instrucción base sin las debidas precauciones. Pero para entender mejor como es que se da este tipo de ataques es necesario conocer la anatomía de una instrucción SQL, para lo cual veamos la siguiente imagen:

Las instrucciones SQL generadas al vuelo por lo general parten de instrucción Base la cuales es una instrucción casi terminada a la cual solo se le concatena en el WHERE el parámetro de filtrado. La instrucción SQL por lo general está definida en el BackEnd, mientras que el parámetro es establecido desde el FrontEnd, de tal manera que el usuario puede manipular este parámetro para enviar no solo el valor esperado, sino que además agrega instrucciones SQL adicionales que serán ejecutadas después de la instrucción Base. Veamos cómo sería una consulta clásica de un usuario de la base de datos por medio de su nombre:

En la imagen vemos en Azul lo que corresponde a la consulta base, esta sección por lo general es fija en el código y solo espera el parámetro para ser concatenado. Tras la concatenación se generaría una consulta completa para consultar a los usuarios que se llamen “oscar”. Hasta aquí todo bien, pero que pasaría si en lugar de mandar solo el parámetro “oscar” mandaran “oscar’; delete from users;”, tras concatenar este parámetro tendríamos el siguiente resultado:

Select * from users where name=’oscar’; delete from users;

Veamos que aquí ya tenemos dos instrucciones completas, por una parte, estamos realizando la consulta del usuario, pero en una segunda instrucción estamos borrando todos los usuarios, por lo tanto, el resultado sería catastrófico para la aplicación.

En este escenario analizamos un delete sobre la base de datos, pero se puede emplear para realizar consultas, insertar registros o actualizarlos. Algunos ejemplos pueden ser actualizar un usuario para darle más privilegios o insertar un nuevo usuario. Lo más importante de este ataque es que tenemos a nuestra merced absolutamente toda la base de datos, al menos hasta donde el usuario de la base de datos empleado para realizar las consultas no lo permite, de esta forma podríamos incluso limpiar todas las tablas o borrarlas.

Ejemplo de SQL Injection :

Para dejar mucho más claro cómo es que un hacker puede aprovecharse de esta vulnerabilidad para atacar un sistema informático, analizaremos un escenario muy común en las aplicaciones, el login o autenticación de usuario, el cual es un formulario muy simple como el que veremos a continuación:

En esta pantalla el usuario introduce su email y su password, presiona enter y la aplicación autentifica al usuario y le permite continuar en la aplicación, pero que pasa por dentro cuando presionamos el botón login.

Primero que nada, del lado del backend abra una instrucción base como la siguiente:

String statement = “Select * from users where email = ‘“ + email + “’ and pwd= ‘“ + password +”’”;

Observemos que la instrucción base es un String el cual está esperando los valores de los parámetros para seguido ser ejecutada. En un caso normal un usuario escribiría su email y su correo, por ejemplo micorreo@gmail.com/1234 y esto generaría una instrucción SQL como esta:

Select * from users where email = ‘micorreo@gmail.com’ and pwd = ‘1234’

Se ejecutaría en la base de datos y nos retornaría los datos del usuario. Pero qué pasa si en lugar de mandar los parámetros esperado, agregara algo más, por ejemplo: micorre@gmail.com/1234’;delete from users where email like ‘%

Veamos que el email es correcto, pero el password, además de tener un valor válido agrega un delete a la tabla de usuarios y tras realizar la concatenación tendríamos el siguiente resultado:

Select * from users where email = ‘micorreo@gmail.com’ and pwd = ‘1234’; delete from users where email like ‘%’

Lo que provocaría la consulta del usuario, seguido del borrado de todos los usuarios, colapsando todo el sistema.

Como prevenir un ataque de SQL Injection :

Básicamente existen dos formas de prevenir estos ataques los cuales nuestros a continuación:

Instrucciones SQL preparadas:

Esta técnica consiste en utilizar ayudas del API de nuestro lenguaje de programación para crear instrucciones SQL preparadas, las cuales ya tiene las instrucciones previamente definidas junto con los parámetros que pueden recibir, impidiendo que instrucciones adicionales puedan ser ejecutadas en Java se implementaría de la siguiente manera:

PreparedStatement statement = con.prepareStatement("select * from users where email = ? and psw = ?"); 
statement.setString(1, email); 
statement.setString(2, pwd); 
ResultSet results = statement.executeQuery();

Escape de los parámetros:

Esta técnica consiste básicamente en convertir los caracteres especiales de SQL en simples String, para que de esta forma todos los parámetros sean interpretado como un solo String. Veamos un ejemplo en Java:

String sql = “select * from users where user = ‘” + user.replace(“\\”, “\\\\”).replace(“‘”, “\\'”) + “‘;”;

El resultado de este String será que todos los parámetros sea solo un String, de esta manera si se inyecta código SQL este solo será parte del where y no se ejecutara como una instrucción adicional.

Conclusiones:

La técnica de SQL Injection es de los ataques más utilizados en la actualidad y es que la gran mayoría de las aplicaciones que hoy están en funcionamiento son propensas a ser atacadas de esta manera, por lo que la mejor defensa contra este ataque es entender cómo funciona para poder prevenirlo.

The post sql injection, tu página esta en peligro appeared first on Oscar Blancarte - Software Architecture.

Cada día las aplicaciones tiene mayor necesidad de intercambiar mensajes con el fin de integrar aplicaciones o de comunicar algo a otras aplicaciones, este tipo de intercambio de mensajes ha crecido a un mas con la llegada de la arquitectura orientada a Servicios(SOA), ya que ha creado un ambiente propicio para que las aplicaciones intercambien mensajes de un punto a otro.

Sea cual sea la el motivo por el cual un mensaje es enviado de un punto a otro es indispensable asegurarnos que los mensajes sean enviados en un canal seguro y que el mensaje enviado sea el mismo que se reciba del otro lado sin ninguna alteración, también existen escenario en los que los mensajes contienen información altamente confidencial como datos de nuestros clientes o cuentas bancarias por lo que somos responsables de asegurarnos que la información continué siendo confidencial.

La pregunta aquí es, que mecanismos podemos implementar para que nuestros mensajes sean enviados en un canal seguro, el cual impida que nuestro mensaje sea alterado o descifrado por terceras personas.

Antes de contestar estas preguntas es importante entender que es la Confidencialidad, Integridad y Autenticidad en mensajes por lo que empezaremos con definir estos términos:

• Confidencialidad: Es la capacidad de un mensaje para mantener oculto su contenido de tal forma que si una tercera persona ve el mensaje no pueda interpretar su contenido.
• Integridad: Se refiere a que los elementos mensajes, datos, documentos, y otros formas de contenido no han sido modificados en tránsito o en reposo.
• Autenticidad: Se refiere a garantizar que el mensaje ha sido enviado por quien dice ser.

Puede que estos tres términos no nos queden muy claros por lo que a continuación hablaremos mas a detalle de cada tema.

Confidencialidad:

La confidencialidad de la información es un tema que tenemos que tener muy presente ya que cada vez que enviamos información por la red estamos exponiéndola a que otras personas no autorizadas puedan interceptarlas y hacer con ellas mucho daño.

En la imagen anterior podemos ver que un mensaje es enviado de un punto A a un punto B, sin embargo el mensaje no se encuentra cifrado ni se envía por un canal seguro, por lo que podrías ser fácilmente interceptado por una tercera persona.

Esta tercera persona podría tener solo curiosidad de ver que hay en el mensaje o podría estar intencionalmente interceptando estos mensajes para hacernos algún daño, en este punto ya hemos perdido la confidencialidad de los datos ya que esta persona ha podido ver la información que hemos enviado.

Una de las forma de evitar esto es enviar el mensaje por un canal seguro como https o SSL lo cual hace que nuestro mensaje vaya cifrado desde que sale de nuestro servidor hasta que llega al servidor destino, de esta forma es mucho mas difícil que nuestro intruso pueda recuperar el mensaje original y revelar la información que este contiene.

Como podemos apreciar en la imagen, nuestro intruso recibe una copia del mensaje cifrado por lo que sera prácticamente imposible que descifre su contenido.

Otra alternativa es cifrar el contenido del mensaje y enviar el mensaje por un canal seguro como en el punto anterior, esto nos garantiza tener una seguridad mucho mas fuerte ya que si el intruso logra por alguna razón descifrar el mensaje del canal seguro se presentara con el problema de que el mensaje descifrado esta nuevamente cifrado pero esta vez a nivel del contenido.

Existen distintos mecanismos de cifrado que nos permitirá enviar mensaje cifrados de un punto a otro y tener la capacidad de descifrar nuevamente el mensaje una vez que llegue a su destino, uno de los algoritmos de cifrado mas utilizados es RSA.

Autenticidad:

La autenticidad es algo muy serio cuando hablamos de mensajes ya que de esta forma certificamos que la persona que nos envió el mensaje no es un impostor que se hace pasar por otra entidad. Este tipo de escenarios es muy común cuando nuestro impostor trata de hacer algún daño a nuestros sistemas enviando mensajes para realizar ciertas tareas en nombre de otra entidad.

Para prevenir este tipo de ataque es importante que las dos partes sea identificadas antes de que un mensaje sea enviado, para esto se utilizan un intercambio de llaves, son creadas dos llaves, una publica y una privada, la privada nos servirá para cifrar los mensajes, la publica nos servirá para descifrar el mensaje  y validar que el mensaje enviado aya sido enviado por la persona que tiene la llave privada.

De esta forma, cuando un mensaje sea enviado de un punto A a un punto B, el punto A enviara el mensaje cifrado con la llave secreta y lo enviara al punto B, el punto B descifrara el mensaje enviado por A y validara que el mensaje fue enviado por A.

En la imagen podemos apreciar el proceso por el cual un punto A y un Punto B hacen un intercambio de llaves, los pasos son los siguientes:

1. El servidor A crea un par de llaves, una publica y una privada, la privada se la quedara el y sera el único que sepa de la existencia de esta llave, la publica por otra parte es enviada al punto B con el fin de que este sea capas de descifrar los mensajes que vienen de A y a si asegurarse de que A fue el que realmente envió el mensaje.
2. El servidor A envía un mensaje B y lo cifra con la llave privada que creo en el primer paso.
3. B recibe el mensaje y utiliza la llave publica para descifrar el mensaje.
4. Mediante el proceso de descifrado el servidor B puedo estar seguro de que A fue quien realmente envió el mensaje.

Integridad:

La integridad por otra parte tiene como objetivo identificar que un mensaje no ha sido manipulado por una tercera persona con el fin de realizar alguna acción en nuestro nombre.

Existe el escenario en que el intruso logra descifrar el mensaje no solo con el fin de conocer su contenido, si no que a demás esta interesado en hacer algún daño haciéndose pasar por otra nosotros y enviar el mensaje que ha capturado pero haciéndole algunas modificaciones adicionales con el fin de provocar mas daño.

En la imagen vemos como nuestro impostor no solo intercepto nuestro mensaje si no que a demás creo un mensaje nuevo basado en el mensaje capturado para enviarlo al destinatario haciéndose pasar por el remitente original. Este nuevo mensaje llegara al destinatario y este pensara que fue enviado por nosotros, esto llevara a que el mensaje sea procesado por el destinatario realizando todos los cambios que este demande.

Para evitar este tipo de problemas es necesario incrustar un sello electrónico dentro del mensaje, este sello es creado combinando la totalidad del mensaje o una parte significativa en una cadena la cual deberá ser pasado por un algoritmo de digestión como MD5, SHA-1, SHA-2 con el fin de crear una cadena mucho mas reducida, esta cadena deberá ser cifrada mediante un certificado de sello digital.

En la imagen podemos ver un ejemplo de un mensaje en XML el cual tiene datos de los clientes, debajo tenemos la cadena original generada a partir del la información del mensaje, notemos que no utilizamos todo el mensaje si no solo sus datos, y al final tenemos la cadena original tras pasar por el proceso de digestión MD5, en este punto solo nos quedara hacer el cifrado de la cadena mediante nuestro certificado de sello digital para tener un verdadero sello digital que garantice la integridad del mensaje.

Finalmente nuestro mensaje quedaría de la siguiente manera:

Cuando el destinatario tome el mensaje, validara que la cadena fue generada con la misma información que contiene el documento. Si un impostor altera el contenido del mensaje no tendrá las llaves para crear el sello electrónico valido, por lo que el destinatario sabrá de inmediato que el mensaje ha sido alterado y su integridad ha sido violada.

En la imagen podemos apreciar como el mensaje original llega al punto B y este de inmediato valida que el sello digital corresponde con la información enviada, por otra parte el intruso crea un nuevo mensaje alterando el contenido del mensaje original, sin embargo, el nuevo mensaje seguirá teniendo el sello original ya que el intruso no tendrá los certificados para crear un nuevo sello basado en la información que altero, El server B detectará esta irregularidad y de inmediato rechazará el mensaje.

Conclusión.

Como ves, existen muchos riesgos cuando de mandar mensaje se trata, por lo que es importante determinar que nivel de seguridad debemos implementar al enviar nuestros mensajes, es por eso que es importante conocer los riesgos y saber las estrategias a tomar para prevenir este tipo de situaciones.

También es importante destacar que estas técnicas son perfectamente combinables para crear un envió mucho mas seguro, por lo que podríamos tener mensajes que contengan sello digital, se envíen cifrados y sobre un canal seguro. esto desde luego logra que nuestro mensaje sea Confidencial, Integro y sea Autentico.

Si te gusto este post no dudes en recomendarlo ya que esto me ayudara a seguir creando mas y mejor material.

The post Seguridad – Confidencialidad, Integridad y Autenticidad en mensajes appeared first on Oscar Blancarte - Software Architecture.