blank
6
Sep

La primera barrera de seguridad comienza en el frontend

La mayoría de las aplicaciones protegen sus bases de datos, sus aplicaciones de backend, sus apis… pero, ¿alguien protege el frontend de sus aplicaciones? ¿Puedo sufrir ataques por esta vía?

Después de haber trabajado para muchos clientes pequeños, medianos y grandes he escuchado, de tanto personas de negocio como de técnicos “expertos”, que el frontend solo el pinta y colorea, que solo importa la seguridad del backend, no hace falta incluir test de calidad, etc. Pero la realidad que nos encontramos cuando un usuario accede a nuestra aplicación, la interfaz móvil o web, será la primero  con lo que trate.

Los dos conceptos que deberemos tener en cuenta a nivel de seguridad en nuestro frontal son:

  • Huecos e información de nuestro sistema
  • Ataques directos a nuestro frontal

blank

Cuando hablamos de estos huecos e información, nos estamos refiriendo, a aquellos ataques que irán para otras partes del sistema, por ejemplo base de datos, pero que podrán realizarlos u obtener información, porque no tenemos protegido ni desarrollado adecuadamente nuestro proyecto. El ejemplo más claro, sería como si nuestro frontal fuese los muros que protegen nuestra casa, y por un lado nos dedicásemos a poner grandes ventanales sin cortinas y además, algún agujero que otro por las paredes.

Cuando hablamos de los ventanales, nos estaríamos refiriendo a la información que podría obtener el usuario a través del navegador de las versiones de nuestro servidor, apis abiertas, estructura del backend, ubicación base de datos, etc. Con esto, el frontend no sufrirá ataques pero sí que permitiría que se pudiesen descubrir más fácilmente, vulnerabilidades de nuestro sistema.

En cuanto a los huecos del muro, nos estaríamos refiriendo por ejemplo a un SQL Injection a través de nuestros formularios. Lo ideal es que desde nuestra web, tratemos y validemos todos los datos, antes de enviarlos al backend, para evitar estos y otros muchos problemas. Aunque esto no quita, que también el back deberá haber tenido en cuenta todas las posibilidades, para evitar que la base de datos se corrompa, que nos realicen ataques al servidor, etc. Es decir, lo que pretendemos hacer desde el desarrollo de la web, es no dejar entrever las posibilidades de ataque, filtrar la mayoría de los problemas que podrían llegar al backend  y dar más estabilidad a nuestra aplicación.

En cuanto a los posibles ataques directos a nuestra web, los casos más obvios que nos podríamos encontrar, son:

  • Obtención de información
  • Errores no controlados en nuestra aplicación
  • Vulnerabilidades en secciones

La gran ventaja que tenemos hoy en día, es que algunos de los frameworks / librerías de JS con los que podemos trabajar, llevan integrados sistemas de seguridad para gestionar parte de estas vulnerabilidades. A pesar, que la otra parte, son buenas prácticas de desarrollo.

En el caso de que estemos desarrollando una nueva aplicación o deseemos revisar una aplicación que ya tengamos desplegada, lo más eficiente, sería utilizar algunas de las herramientas libres o de pago, que nos analizarían una parte de estas vulnerabilidades. Aunque deberemos tener en cuenta, que dependiendo la arquitectura y los frameworks que hayamos utilizado, deberemos optar por unas opciones u otras. Un ejemplo de ello sería por ejemplo WordPress, donde tendríamos herramientas específicas para analizarlo, como por ejemplo:

Pero no hay que olvidar, que estas herramientas solo analizan los errores generales, y que si tenemos un proyecto lo suficientemente grande e importante, deberemos tener a algún especialista revisando el proyecto manualmente.

Leave a Reply