REVISTA .SEGURIDAD | 1 251 478, 1 251 477 | REVISTA BIMESTRAL

Recomendaciones antes de liberar tu página web

Proteger tu página web y los datos de tus usuarios es una tarea cada vez más complicada. El desarrollo de páginas web se ha convertido en un gran negocio, pero la alta demanda implica una oferta en aumento que, desafortunadamente, baja la calidad del producto final. La presión de entregar una página web en tiempo y forma hace que los desarrolladores cada vez inviertan menos tiempo en cuestiones que perciben menos “críticas”, como la seguridad o el rendimiento del sitio.

El propósito de este artículo es proporcionar consejos generales de rendimiento y defensa para aplicaciones web. Estas recomendaciones aplican para cualquier tipo de proyecto web, ya sea que esté basada en un gestor de contenidos o en otro tipo de desarrollo. Quizás el único requisito es que sea una página pública a través de un servidor web como Apache, Ngnix, IIS, entre otros.

Las consideraciones de administración de sistemas o desarrollo de aplicaciones dependen en gran medida de los recursos que los actores involucrados tengan a la mano. Un estudio independiente de diseño web o incluso desarrolladores independientes (freelancers), no tienen acceso a los mismos recursos que una universidad o una empresa de mayor tamaño. La tendencia del mercado es la reducción de costos y tiempos, pero es importante tener en cuenta los riesgos e implicaciones de las decisiones que se toman. Incluso si hablamos de una universidad o empresa grande, los equipos de desarrollo web no están necesariamente en contacto directo con los administradores de sistemas. Para estos equipos de desarrollo, las siguientes recomendaciones pueden ser de utilidad.

A modo de ejemplo, hoy en día los servicios de hospedaje web ya incluyen muchas opciones de protección, como servicios de firewall de red, firewall de aplicaciones, protección para DDoS, entre otros; sin embargo, los equipos de desarrollo no tienen acceso a la configuración de estas funciones, las opciones disponibles se reducen a “encendido” y “apagado”.

Figura 1. No siempre es posible acceder a la tabla de reglas de ModSecurity

El servicio de hospedaje es un material de trabajo, más que parte de un proyecto en sí; y no es posible acceder a configuraciones como las que se comentan en artículos previos de la revista .Seguridad [1] y [2], porque los desarrolladores son también clientes del proveedor de servicios de hosting. Esta situación se complica un poco más con servicios de hosting compartido en los que únicamente se tiene acceso a la consola del gestor de contenido, y si hay suerte, a la base de datos. En la mayoría de los casos, hay que trabajar con versiones de software no actualizado o configuraciones de rendimiento sin optimización.

Figura 2. A veces la versión más reciente de PHP disponible es 5.6.X

¿Qué puedo hacer?

Si te has encontrado en esta situación, no todo está perdido. Las siguientes tres consideraciones te pueden ayudar a agregar características de seguridad y rendimiento a tus proyectos con una inversión mínima de tiempo, conocimientos o de dinero. Es posible que estés a punto de liberar tu siguiente proyecto web y esta lista puede serte útil como guía por si no has considerado estas tres opciones en tu proyecto. Recuerda que sin importar si el proyecto es un desarrollo propio, una aplicación web basada en gestores de contenido o cualquier otro tipo de servicio en línea que utilice Internet, puedes aplicar alguna de estas recomendaciones con relativa facilidad.

1. Caché

La utilización de sistemas de caché en un proyecto debe estar acompañada de un entendimiento, al menos en términos generales, de las implicaciones de seguridad que debe tener disponible una sección del contenido de esta manera.[1] Sin embargo, a veces es inevitable el uso de estos sistemas porque el rendimiento del servidor es insuficiente, la carga de peticiones es mayor a la esperada o el presupuesto de ancho de banda es limitado. Esta recomendación asume que existe alguna justificación para utilizar servicios de caché en un proyecto web, por ejemplo, que la tecnología en la que se desarrolla un proyecto web incluye estas funciones y desactivarlas afectaría el rendimiento del sistema.

Las funciones de caché para aplicaciones web muchas veces están ya incluidas en la configuración de tu servidor web o son una función automática del lenguaje que utilizas para servir contenido dinámico. Otra manera de utilizar caché en una página web es aprovechando las funciones de los navegadores, que pueden guardar datos en la computadora de tus usuarios para evitar la consulta remota lo más posible. En “Caching Tutorial for Web Authors and Webmasters” [4], puedes encontrar una reseña sobre lo que puede hacer el caché para tu página.

Sobre las opciones de caché en el servidor, básicamente se trata de configurarlo para que guarde una copia estática de los archivos de tu página. Este tipo de caché almacena las secciones de tu sitio en un formato que no puede ser procesado por el lenguaje para servir contenido dinámico (pensemos que las páginas PHP o Java se guardan como HTML), lo que libera la carga de procesamiento de tu servidor y responde más rápido.

Activar configuraciones de caché puede ser cuestión de instalar un complemento para tu gestor de contenidos. Algunas opciones para Wordpress son W3 Total Cache, WP Super Cache, WP Rocket, de los que puedes consultar esta lista comparativa [5];  para Drupal puedes consultar [6]. Sin embargo, esta opción no siempre está disponible, porque supone al menos acceso al directorio de la aplicación (FTP, SFTP, SSH, entre otros), o incluso privilegios para instalar módulos para el servidor (como Apache y Nginx) o para el lenguaje (como PHP y Java).

2. CDN (Redes de Distribución de contenido)

Otra opción para mejorar el rendimiento son las redes de distribución de contenido (CDN) que se encargan, en términos generales, de servir como intermediarios para una parte del contenido (o todo) que se distribuye en tu sitio. La idea es que estos servicios respondan a los usuarios desde una ubicación optimizada, de forma que el tiempo de espera para una solicitud sea menor.

Una manera común de integrar esta tecnología es accediendo a bibliotecas comunes como jQuery, Bootstrap, Google, Font Awesome, entre muchas otras. Puedes consultar cómo incluir en tu proyecto las versiones CDN de las bibliotecas de funciones que utilices para evitar la descarga desde tu servidor. Por ejemplo, para incluir jQuery desde su versión CDN alojada por Google, debes agregar esto a la cabecera de tu página:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>​

Lo anterior descargará la versión 3.1.1 de jQuery desde un servidor de Google, evitando la consulta a tu servidor para jQuery. Revisa la documentación de las bibliotecas que utilizas, es muy probable que puedas ahorrar tiempo de procesamiento y de respuesta con esta estrategia.

Por otro lado, las redes CDN pueden servir también para distribuir el contenido completo de tu proyecto web. Puedes consultar [7] y [8] donde se explica el funcionamiento general y se enlistan las más populares. Cabe destacar que el funcionamiento de este tipo de servicios puede estar integrado incluso al registro DNS del dominio de tu proyecto, sin afectar tu servicio de hosting. Lo que ocurre es que esta red se encarga de distribuir tu contenido y evitar que la petición llegue a tu servidor. La ubicación de los nodos de estas redes globales garantiza que tu contenido se servirá desde el sitio geográfico que más le convenga a tus usuarios.

Figura 3. A la izquierda, un servidor web normal, a la derecha una red de distribución de contenido [https://en.wikipedia.org/wiki/File:NCDN_-_CDN.png]

Las empresas que ofrecen los servicios de distribución de contenido también ofrecen opciones de seguridad para sus usuarios. Debido a que estas redes están en una capa anterior a la infraestructura del servidor web principal, se pueden colocar servicios de firewall de aplicaciones, protecciones de DDoS, cifrado SSL, entre otros.

Por ejemplo, para protección de DDoS, un servicio CDN puede soportar una carga significativamente mayor a un servidor alojado en hospedajes de capacidad estándar. Cuando un ataque de este tipo se detecta por la CDN, el usuario puede recibir alertas y, literalmente, presionar un botón de pánico para informar a sus usuarios que el sitio está bajo un ataque. La función de la CDN es responder a las peticiones masivas con la posibilidad de distinguir entre las peticiones de ataque y las legítimas, como se muestra en la figura 4.

Figura 4. A la izquierda, el esquema de ataque DDoS; a la derecha, la protección de CDN ante DDoS [9]

Para mayor información, puedes consultar otros riesgos que puedes evitar con esta tecnología en [10], [11] o [12].

Al utilizar una CDN es de suponer que confías en el distribuidor de contenidos; esto es importante porque este tipo de servicios puede incluir condiciones por parte de estas empresas, lo que implica la recopilación de información de tu página  (por ejemplo, para estadísticas de uso). Estar en un punto intermedio entre el usuario y el servidor principal también otorga a este tipo de servicios privilegios muy interesantes: pueden permitir a la CDN mostrar publicidad a los usuarios (ads) o modificar el código que se envía desde tu página sin que tengas ningún control sobre el proceso. Si decides utilizar este tipo de servicio, asegúrate de comprender sus implicaciones e investiga las opciones disponibles con base en tus necesidades específicas, así como consultar con cuidado los términos y condiciones de uso.

3. Herramientas anti spam

La manera de proteger una página web contra el spam es relevante cuando el proyecto considera datos de entrada de parte de los usuarios, ya sea en forma de formularios de contacto, foros de discusión, listas de correo, entre otros.  Al permitir que una página reciba datos de entrada, es necesario añadir algún mecanismo para evitar mensajes de spam, o ataques que vulneren el sistema que soporte la página web.

No siempre es posible integrar al desarrollo un sistema de monitoreo o moderación de comentarios a una página web, porque esta función muchas veces es secundaria para el objetivo principal del proyecto. Sin embargo, considerar un mecanismo de moderación o protección contra el spam, hará que esté mejor protegido y evitará problemas futuros, mantenimientos inesperados o corrección de fallas no programadas.

En este caso, tu mejor opción es transferir la operación de los comentarios a una plataforma de terceros, como Facebook [13], Disqus [14] o Wordpress [15] con Akismet [16], o lo que dependerá de cada proyecto, además de que se debe considerar la privacidad de los usuarios al elegir alguno de estos servicios.

Conclusión

Claramente, esta no es una lista exhaustiva de características de seguridad o de las herramientas para atender estas cuestiones. Reconocer posibles amenazas que puedan afectar a tu aplicación es un primer paso muy importante para evitar estos problemas. Los cuidados y medidas que puedas adoptar dependerán de tu proyecto y de los usuarios a los que esté orientada tu página web. Recuerda que la seguridad y privacidad de la información de los usuarios de tu página estará bajo tu cuidado, al consultar tu sitio y posiblemente después, si almacenas información.

Referencias

[1]       Díaz, S. S. (Enero-febrero 2013). Firewall de Aplicación Web - Parte I. .Seguridad Cultura de prevención para TI. Recuperado de: http://revista.seguridad.unam.mx/node/2167

[2]       Díaz, S. S.; Ramírez, D. O. (Marzo-abril 2013). Firewall de Aplicación Web - Parte II. .Seguridad Cultura de prevención para TI. Recuperado de: http://revista.seguridad.unam.mx/node/2175

[3]       OWASP. (30 de junio de 2016). OWASP Application Security FAQ - OWASP. OWASP. Recuperado de: https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Browser_Cache

[4]       Nottingham, M. (6 de mayo de 2013). Caching Tutorial for Web Authors and Webmasters. mnot. Recuperado de: https://www.mnot.net/cache_docs/

[5]       Ewer, T. (28 de febrero de 2017). The Top 3 WordPress Caching Plugins Compared and Choosing the Best One for Your Site.  WPMU DEV- The WordPress Experts. Recuperado de : https://premium.wpmudev.org/blog/top-wordpress-caching-plugins/

[6]       Drupal. (s.f.). Caching to improve performance. Drupal. Recuperado de: https://www.drupal.org/docs/7/managing-site-performance-and-scalability/caching-to-improve-performance [Consultado: 06-mar-2017].

[7]       Wikipedia. (1 de enero de 2017). Red de entrega de contenidos. Wikipedia, La enciclopedia libre. Recuperado de: https://es.wikipedia.org/wiki/Red_de_entrega_de_contenidos

[8]       Wikipedia. (22 de marzo de 2017). Content delivery network. Wikipedia, The Free Encyclopedia. Recuperado de: https://en.wikipedia.org/wiki/Content_delivery_network

[9]       Sullivan, N. (30 de julio de 2013. DDoS Prevention: Protecting The Origin. Cloudflare Blog. Recuperado de: http://blog.cloudflare.com/ddos-prevention-protecting-the-origin/

[10] Cloudfare. (s.f.). Security. Cloudflare. Recuperado de: https://www.cloudflare.com/security/

[11] KeyCDN. (2017). CDN Features | API, Raw Logs, HTTP/2, Free Custom SSL, Real-time Analytics and many more. KeyCDN. Recuperado de: https://www.keycdn.com/features

[12] Imperva. (2017). Website Security | Bot Filtering | Anti-DDoS | PCI Compliance. Imperva Incapsula. Recuperado de: https://www.incapsula.com/website-security/

[13] Facebook for Developers. (s.f.). Plugin de comentarios. Facebook for Developers. Recuperado de: https://developers.facebook.com/docs/plugins/comments/

[14] Disqus. (2017). Disqus – The #1 way to build your audience. Disqus. Recueprado de: https://disqus.com/

[15] WordPress. (s.f.). Comments in WordPress. WordPress.ORG. Recuperado de: https://codex.wordpress.org/Comments_in_WordPress

[16] Akismet. (s.f.). Akismet: Spam Protection for WordPress. Akismet. Recuperado de: https://akismet.com/

 

Si quieres saber más consulta:



[1] Los riesgos de utilizar caché se pueden consultar en [3], en la sección “Browser Cache”.

 

UNAM

[ CONTACTO ]

Se prohíbe la reproducción total o parcial
de los artículos sin la autorización por escrito de los autores

 

Hecho en México, Universidad Nacional Autónoma de México (UNAM) © Todos los derechos reservados 2017.