Cuando me refiero a Falsa Seguridad quiero decir que muchas veces se piensa que la aplicación está segura pero en realidad no existe seguridad alguna. En este artículo te voy a enseñar algunos ejemplos de lo que es falsa seguridad y como evitarla.
Todo lo que pasa por la red no es seguro
Lo primero que tienes que tener en cuenta, es que todo lo que pasa por una red puede ser interceptado por alguien dentro de esa red. En el caso de internet, la red más grande de todas, puede ser interceptado por cualquier persona que esté conectada.
Para mostrar un ejemplo de como los datos pasan por la red te propongo el siguiente esquema:
Este esquema es bastante simple pero funcionará perfecto para lo que queremos explicar.
Red 1 y Red 2
Antes de explicar, el esquema global, es necesario que entiendas que representan las redes 1 y 2.
La red de tu casa
Estas redes podrían representar la red de tu casa, en la que tienes una o más PC’s y probablemente un router con el que te conectas a internet. Probablemente no tengas un servidor o tal vez si. En esta red, al estar detrás de un router que probablemente tiene un router, estás más o menos protegido de los posibles ataques desde internet.
Probablemente, dentro de esta red, los usuarios son tus familiares más cercanos por lo que la información que viaja por aquí (sin salir de internet) como por ejemplo transferencia de archivos dentro de la red local están seguras ya que a tus familiares no les importa robar tu información. Dentro de esta red, podemos decir que tu información está segura.
La red de tu centro laboral o de estudios
Las redes 1 y 2 también pueden representar la red de tu centro de trabajo o centro de estudios. Probablemente tenga muchas más PC’s y tal vez más de un servidor que puede ser una intranet o algo por el estilo.
En esta red, tu información está segura en lo que respecta a internet pero no de los mismos usuarios de la red. Me explico, supongamos que en tu empresa hay un empleado descontento que simplemente quiere fastidiar. Si quisiera podría interceptar los mensajes entre tu PC y el servidor dentro de tu red para obtener tu información que puede incluir desde tu pelicula favorita hasta tu clave del banco.
Otro ejemplo sería, en tu centro educativo, tal vez un alumno desea interceptar un mensaje que pasa por la red para obtener la clave del profesor y cambiar sus notas.
En general, en esta red la protección es exactamente la misma que existe en tu casa con la única diferencia de que al haber más usuarios existe mayor posibilidad de que alguien quiera robar información.
En principio, como todos los usuarios pertenecen a la misma empresa o centro educativo puedes decir que existe cierta moral y no se va a intentar robar información (ojalá fuera cierto) pero te sorprenderías al saber que la gran mayoría de ataques informáticos se realizan dentro de las mismas empresas y no desde fuera.
La red de tu servidor web
Estas redes también pueden representar la red dónde está alojado tu servidor web (hosting) o inclusive las redes de empresas como Google, Microsoft, Yahoo y Facebook. Probablemente, en estas redes no existan muchas PC’s sino que solo existan servidores. Si este fuera el caso, la información que viaja por la red interna estaría muy segura ya que, al no haber usuarios en esta red no habría nadie que pueda robar información mientras se transmiten los datos.
Ahora, si la red representa un servidor web público como los mencionados anteriormente, probablemente tenga una comunicación con Internet lo que me lleva al siguiente punto.
La red Internet
La red de internet, funciona en un esquema más grande, pero casi de la misma manera. En el esquema de las redes 1 y 2 hemos visto que una serie de PC’s y servidores están conectadas entre sí haciendo posible la comunicación entre ellas. En la red internet sucede lo mismo, con la única diferencia de que ya no son simples PC’s sino redes completas que se conectan a internet.
El problema con la seguridad, sigue siendo el mismo que con las redes 1 y 2, la gran diferencia es que ahora el mundo entero está conectado a esta red y las posibilidades de que alguien robe información son bastante mayores.
Que debemos proteger
En realidad, deberíamos proteger todo lo que enviamos por una red pero tienes que ser capaz de analizar la situación y decidir si vale la pena o no pasar horas asegurando algunas partes de tus aplicaciones o no.
Por ejemplo, si vas a hacer una aplicación web que corra en una PC (servidor) de tu casa para que tus familiares cercanos guarden su información personal como contactos, cuentas bancarias, contraseñas, etc. Debes darte cuenta de que esta información viajará por la red sin ningún tipo de seguridad pero como solamente tus familiares tienen acceso a dicha red, es muy poco probable que alguien se robe esa información. En todo caso, lo más fácil sería entrar directamente al servidor que está en el estudio de tu casa y sacar la información directamente desde ahí.
Otro ejemplo, si vas a hacer una aplicación para tu empresa en la que la gran mayoría de usuarios son de confianza y tienen cero conocimientos de computación, probablemente tampoco valga la pena perder mucho tiempo encriptando la información que pasa por la red ya que lo más probable es que nadie sepa como interceptarla. Lo que si te debería interesar es guardar la información sensible de forma encriptada en el servidor para que si algún día alguien se roba el servidor entero, no pueda leer esa información.
Para que quede un poco más claro. Supongamos que tengo una intranet que guarda información sensible acerca de mi empresa y empleados. Podría perder mucho tiempo haciendo una aplicación que al momento de que el usuario guarda un dato en el sistema este se encripte para que viaje por la red de forma ilegible, luego llegue al servidor y se almacene. Sin embargo, la clave de forma ilegible pasará por la red en menos de 1 segundo y probablemente nadie la esté interceptando. Por otro lado, supongamos que alguien logra ingresar a tu servidor (hacker). Probablemente tenga mucho más de 1 segundo para analizar la información. Si esta está encriptada puede ser que nunca llegue a obtener nada importante pero si no lo está lo hará en cuestión de minutos. Este tipo de conceptos tienes que tener en cuenta al momento de proteger tus aplicaciones.
En Internet, la cosa cambia bastante ya que hay mucha gente que está interceptando los mensajes que viajan por la red. Si interceptan estos datos puede ser que obtengan información sensible para tí.
Por ejemplo, si haces una aplicación web que sea pública para los usuarios de internet tienes que preocuparte de muchos aspectos que probablemente no sean necesarios en una intranet o red local. En este artículo voy a tratar este tipo de conceptos en base a un simple ejemplo de autenticación.
Casos de falsa seguridad
La falsa seguridad la voy a explicar con un ejemplo simple que vemos todos los días Autenticación (Ingresar a un sistema mediante un Usuario y Contraseña). Este ejemplo aplica en internet como en las redes locales, con la única diferencia de que los usuarios son diferentes (como explicamos anteriormente).
El esquema de autenticación es bastante simple y en diagrama anterior estaría representado como que la Red 1 es la máquina del usuario y la Red 2 es el servidor donde está nuestra aplicación. Aquí va el esquema:
- El usuario solicita desde su navegador la página de login del sistema, por ejemplo http://servidor/login
- El servidor responde proporcionándole una página web dónde podrá ingresar su usuario y contraseña.
- El usuario ingresa su usuario y contraseña y da clic en Ingresar.
- El sistema recibe el usuario y contraseña, verifica si los datos son correctos (suponiendo que si) y devuelve una página con la información de la cuenta. En este momento el servidor se olvida del usuario (así funcionan las peticiones HTTP) pero le entrega una clave al usuario que lo identificará en su siguiente petición (por lo general un Cookie. Si no sabes que es un cookie te recomiendo leer Cookies con PHP y Javascript. También se puede hacer a través de sesiones que son un poco más difíciles de modificar que los cookies pero en el fondo funcionan igual).
- El usuario realiza otra petición al servidor (para ver otra página de su cuenta). Junto con la petición se envía el cookie que lo identifica.
- El servidor revisa el cookie que lo identifica y le proporciona la información.
Listo! Este es el esquema que vamos a manejar. Vamos a asumir ahora que nosotros estamos desarrollando toda la aplicación del servidor.
Comenzaré con lo más básico e iré avanzando hasta llegar a un nivel de seguridad aceptable, en cada caso trata de analizar cuál es la vulnerabilidad que se presenta antes de leer la respuesta.
Caso 1
El caso 1 es el más estándar. Mi página de login es un HTML que tiene un formulario estándar para ingresar usuario y contraseña. En el servidor recibo estos datos, los valido y los comparo contra mi base de datos para ver si son correctos.
| Cliente (Usuario) | Servidor |
|---|---|
|
|
|
En este caso, espero que la falla de seguridad sea obvia ya que no hemos implementado ningún mecanismo de seguridad. ¿Sabes cuál es?
Respuesta: Los datos carlos y abc123 viajan por la red sin ser encriptados por lo que cualquier persona puede verlos y después ingresar al sistema como si fuera carlos.
Solución: Tengo que asegurarme de que los datos viajen encriptados por la red.
Caso 2
Ahora vamos a proteger los datos carlos y abc123 para que viajen encriptados por la red y en el servidor se desencripten para poder compararlos contra la base de datos.
| Cliente (Usuario) | Servidor |
|---|---|
|
|
|
La información ahora viaja por la red encriptada. ¿Cuál es el error de seguridad?
Respuesta: El algoritmo de encriptación está en el lado del cliente por lo que cualquier persona puede ver mi algoritmo y por lo tanto saber como se encriptaron los datos. Si puedo obtener la cadena encriptada que pasa por la red y se como se encriptaron los datos, puedo revertir el proceso y obtener el usuario y contraseña. Dependiendo de la complejidad del algoritmo puede ser fácil o difícil revertirlo pero siempre existe la posibilidad de hacerlo.
Solución: Ocultar mi algoritmo de encriptación y fortalecerlo. Para esto, la mejor solución es hacer que las páginas con información sensible como lo es una pantalla de login se ejecuten sobre HTTPS en lugar de HTTP. Las peticiones sobre HTTPS realizan la encriptación mediante certificados firmados lo cual permite contar con un sistema de seguridad muy potente y cuyo algoritmo de encriptación no es visible.
Podrías estar tentado a poner todas tus páginas sobre HTTPS para que toda la información viaje encriptada pero esto NO sería lo óptimo ya que la diferencia en tiempo de respuesta entre HTTP y HTTPS es significativa. En HTTP la información viaja tal cual por lo que puede ser procesada de forma inmediata mientras que en HTTPS se tiene que encriptar y desencriptar los datos para cada página y esto consume muchos recursos.
Te recomiendo que investigues acerca de HTTPS y como instalarlo en tu servidor. Si utilizas un hosting probablemente tengas que pagar un poco más de dinero para poder hacer uso de HTTPS.
Caso 3
En este caso voy a suponer que no usas HTTPS pero has implementado un algoritmo imposible de revertir (ni siquiera tu puedes) y hasta has hecho que tu algoritmo de encriptación sea imposible de leer desde tu página HTML.
Inclusive, podría ser el caso de que tu servidor solo tiene un servicio web el cual utilizas desde una aplicación de escritorio (.exe). Si este fuera el caso significa que tu servidor no tiene una página web, tu algoritmo de encriptación está bien protegido dentro de tu ejecutable y hasta puedes utilizar un algoritmo muy seguro para encriptar.
| Cliente (Usuario) | Servidor |
|---|---|
|
|
|
Como puedes notar, al no poder reversir el algoritmo, mi base de datos almacena solamente los valores encriptados por lo que tengo que comparar los valores encriptados contra los valores encriptados de la base de datos. En teoría, esto es aún más seguro ya que en mi servidor los datos se están almacenando encriptados. ¿Cuál es el error de seguridad?
Respuesta: En realidad, este error es tan crítico como regresar al caso 1 en el que no hay seguridad. Supongamos que intercepto el usuario y contraseña encriptados que viajaron por la red. Obviamente NO puedo convertir estos valores en carlos y abc123 pero no lo necesito ya que el servidor compara los datos encriptados contra la base de datos.
Dicho esto, lo único que tengo que hacer es hacer un programa que mande el usuario y password sin encriptar. En este programa ingreso p$sk3%3sfp; como valor para el usuario y po459(/2as”5 como el valor para la contraseña. Como estos valores no se van a encriptar van a llegar al servidor tal y como los escribí. Como es un usuario válido me aparecerá la pantalla que dice Carlos, bienvenido al sistema entonces ya sé que el usuario es carlos y en la página de opciones puedo cambiar la contraseña.
Solución: Utilizar HTTPS como expliqué en el caso 2.
Caso 4
A partir de este caso voy a asumir que tu página de login ya funciona con HTTPS y por lo tanto está tan segura como es posible.
Además a partir de este caso, voy a trabajar los puntos desde el 4 hasta el 6 de la estructura de Autenticación descrita previamente. Los puntos del 4 al 6 son en los que el servidor ya identificó al usuario y ha colocado un COOKIE en la máquina del usuario para que no necesite autenticarse la siguiente vez.
A pesar de que no es la forma de trabajo correcta, voy a asumir que todas tus páginas trabajan sobre HTTPS por lo que puedo transmitir datos sin encriptar pero al estar bajo HTTPS se encriptan y desencriptan de forma automática.
En este caso se coloca el cookie de autenticación en la máquina del usuario y este solicita otra página.
| Cliente (Usuario) | Servidor |
|---|---|
|
|
|
|
|
En este caso, el cookie no está encriptado pero como he asumido que trabajas sobre HTTPS el cookie viaja encriptado y automáticamente se desencripta al llegar al lado del cliente o servidor. ¿Cuál es el error de seguridad?
Respuesta: A pesar de que el cookie solo se encuentra en la máquina del cliente, no sabemos en que lugar físico está. Supongamos que está en una cabina de internet o en una PC en el aeropuerto y este se olvida de cerrar su sesión. Otra persona puede usar esa máquina y ver que existe un cookie donde se ve claramente el usuario y contraseña.
Solución: Hay que encriptar el cookie a pesar de que esté viajando encriptado. Es más, en realidad la contraseña nunca debió estar almacenada en el cookie ya que por más de que el algoritmo de encriptación no está en el cliente tiene que ser reversible para poder interpretar quien es y ofrecer el contenido pertinente. Si la encriptación es reversible existe la posibilidad de que se pueda obtener la contraseña del usuario.
Caso 5
En este caso voy a asegurarme de que el cookie esté encriptado antes de mandarlo al usuario. De esta forma si alguien tiene acceso al cookie no podrá saber que usuario es. Además ya no voy a mandar la contraseña para que nadie la pueda obtener en el caso de que reviertan la encriptación.
| Cliente (Usuario) | Servidor |
|---|---|
|
|
|
|
|
Aparentemente ya está la seguridad al máximo porque la data viaja encriptada y el cookie que se guarda en el lado del cliente también está encriptado. ¿Cuál es el error de seguridad ahora?
Respuesta: El cookie, está encriptado por lo que no sé a que usuario le pertenece. Pero basta que cree un cookie exactamente igual en mi PC y solicite una página al servidor. El servidor se encargará de determinar que es el usuario carlos y me dará la página con la información de él sin necesidad de colocar la contraseña de carlos.
Solución: El cookie solo debería ser válido por un periodo corto de tiempo como por ejemplo uno o dos días. No podemos depender del tiempo de expiración natural del cookie que obliga al navegador a eliminarlo ya que si hacemos esto es posible que el atacante simplemente vuelva a crear el cookie. Entonces lo que tenemos que hacer es poner la fecha de expiración com un valor adicional en el cookie.
Adicionalmente, también podemos colocar algún tipo de información acerca de la petición original (como por ejemplo el IP o el número de sesión) para asegurarnos de que el usuario esté en la misma máquina que en la que se autenticó.
No recomiendo poner el IP ya que muchos usuarios tienen IP’s dinámicos que cambian cada cierto tiempo. Si este fuera el caso, el usuario tendría que autenticarse cada cierto tiempo y sería incómodo para él. Es mejor poner el número de sesión que es generado mediante una combinación de valores acerca de la petición. Averigua como obtener el ID de sesión en el lenguaje que estás usando.
Caso 6
En este caso, voy a colocar la fecha de expiración del cookie y también el ID de la sesión que identifica a la máquina que realizó la petición.
| Cliente (Usuario) | Servidor |
|---|---|
|
|
|
|
|
En este caso, si alguien llegara a obtener el cookie tendría dos limitaciones que me ofrecen bastante seguridad. Tendría como máximo dos días para utilizar este cookie (suponiendo que ese es el tiempo que he decidido que debe durar el cookie) y tendría que usar la misma máquina que utilizó el usuario carlos. Esto reduce bastante la vulnerabilidad debido a que el atacante necesita sentarse en la misma máquina en la que se sentó carlos en un lapso menor a dos días y asumiendo que carlos se olvidó de cerrar la sesión.
Aparentemente nuestra aplicación es bastante segura pero tengo que preguntar ¿Cuál es el error de seguridad?
Respuesta: Mi algoritmo de encriptación sigue siendo reversible, así que alguien puede descubrirlo. (Son pocas las probabilidades pero las hay). Supongamos que eso pasa y el atacante hace un pequeño programa que permita realizar la misma encriptación que nosotros utilizamos en nuestro servidor. Si este fuera el caso, entonces podría generar un cookie con los valores que quisiera. Por ejemplo podría crear un cookie en donde el usuario fuera admin, la fecha de expiración que sea de acá a 10 años y la sesión la puede sacar del cookie que se genera cuando el ingresa con su cuenta normal.
Con esto tendría acceso a la cuenta de administrador y podría hacer lo que quiera.
Solución: Necesitamos un algoritmo de encriptación que no sea reversible. El problema está en que si no es reversible no podemos obtener el usuario, la fecha de expiración ni el ID de la sesión. Entonces la solución es combinar un método reversible con uno no reversible como se muestra en el siguiente caso.
Caso 7
En este caso se agrega un valor más al cookie que representa una cadena encriptada irreversible a partir de la cadena generada por el cookie con la encriptación reversible. En el ejemplo se entiende mejor:
| Entidad | Pasos |
|---|---|
| Servidor |
|
| Cliente |
|
| Servidor |
|
Como puedes notar, ya no importa si el atacante descubre el método reversible de encriptación porque si altera los valores, el extra no coincidirá haciendo inválida la petición.
Este ya es un nivel aceptable de seguridad y lo dejaré ahí.
Conclusión
Existen muchos más aspectos que considerar en seguridad y yo solo he tocado la superficie. Pero creo que he cumplido mi objetivo, que es enseñarte cómo debes mirar a tus aplicaciones para ver dónde están las vulnerabilidades y como puedes hacer para solucionarlas.
Espero que el post te guste y te sirva para hacer aplicaciones más seguras. Ten en cuenta de que la encriptación no es nada si no piensas lo que estás haciendo. Mantente actualizado en cuanto a temas de seguridad ya que cada día salen cosas nuevas.
Artículos similares
Excelente articulo, ya que como dices al final, lo importante no es solo aprender a encriptar, y/o inventar métodos aparentemente infalibles; si no pensar un poquito a cerca de lo que se está haciendo. De nada vale tanta seguridad sino se le pone un poco de lógica.
Muy buena la información, realmente se puede llegar a aprender bastante sobre esto, si se sabe enseñar como vos.
Muy buen post, me hizo pensar en las grandes probabilidades que tiene una persona que está conectada a internet de tomar la identidad de otra y hacer practicamente lo que sea, pero sin duda no podemos dejar todo a la maquina, sino dejariamos el server o la pc desatentid@ sin ningun problema, debemos de usar mucho la lógica-ilógica humana que nos caracteriza, eso es lo único que nos separa de pensar en miles de soluciones lógicas en milisegundos, o de pensar en la mejor solución lógica-ilógica que podria salvar la integridad de un sitema y de muchas personas.
Saludos