Cómo los proxies inversos mejoran la seguridad de su aplicación web
No es ningún secreto que las empresas utilizan cada vez más las aplicaciones web. Las aplicaciones web permiten agilizar las operaciones corporativas, mejorar la eficiencia y ahorrar gastos en tareas que, de otro modo, se realizarían manualmente. A pesar de su creciente popularidad, las aplicaciones web están expuestas a riesgos y ciberataques. Este artículo ofrece una visión
No es ningún secreto que las empresas utilizan cada vez más las aplicaciones web en la actualidad. Las aplicaciones web permiten agilizar las operaciones corporativas, mejorar la eficiencia y ahorrar gastos en tareas que de otro modo se harían manualmente.
Las aplicaciones web son propensas a riesgos y ciberataques a pesar de su creciente popularidad. Este artículo le proporcionará información sobre los principales ataques a los que es vulnerable una aplicación web. A continuación, descubrirás cómo puedes incorporar un proxy inverso para minimizar las amenazas.
Pero antes de sumergirnos en los aspectos de seguridad, echemos un vistazo a la arquitectura de una aplicación web típica.
Visión general de la arquitectura de aplicaciones web
Aplicación web
En la mayoría de los casos, las aplicaciones web constan de servidores y páginas web. Los servidores web aceptan peticiones de los clientes (sus navegadores web), que un servidor web procesa y devuelve la respuesta al cliente.
Mientras que el lado del servidor se codifica con lenguajes de programación dinámicos como PHP, Python, ASP.NET, etc., el lado del cliente se codifica con HTML, CSS y JavaScript. La comunicación entre el cliente y el servidor tiene lugar a través del protocolo HTTP.
Puede consultar este artículo para obtener más información sobre la estructura de las aplicaciones web. La siguiente figura muestra una comunicación cliente-servidor típica.
En el diagrama anterior, toda la comunicación parece sencilla: las solicitudes van y vienen entre el cliente y el servidor. Sin embargo, no siempre es así.
Desafortunadamente, las aplicaciones web que utilizan el diseño anterior están sujetas a ciberataques por parte de extraños entre el cliente y el servidor.
Echemos un vistazo a algunas de las estadísticas de ciberataques más interesantes antes de sumergirnos en la naturaleza de estos ataques.
¿Cuáles son las principales amenazas para una aplicación web?
Emocionantes estadísticas sobre ciberataques
Según los datos de vulnerabilidades de aplicaciones web de Positive Technologies de 2018, las industrias de Finanzas y Banca representaron el 28 % de todas las aplicaciones web atacadas. También indica que el 14 % de los ciberataques se dirigen a aplicaciones en línea de los sectores de las telecomunicaciones y la fabricación, y el 11 % a aplicaciones de transporte.
Otras industrias que se enfrentan a riesgos son las instituciones gubernamentales (11%), las TI, el comercio electrónico y los medios de comunicación de masas.
En cuanto a los tipos de ataques, otro informe, el de F5, señala que aumentan los ataques de cross-site scripting (del 4% al 54%) y de SQL injection (SQLi) (del 15% al 76%).
A partir de estas estadísticas podemos llegar a la conclusión de que son necesarias algunas medidas estrictas para proteger las aplicaciones web de las vulnerabilidades. Algunos de los fallos de seguridad se deben a problemas de codificación, mientras que otros pueden deberse a una infraestructura inadecuada de la aplicación web. Aquí es donde entra en escena el cortafuegos de aplicaciones web (WAF), que puede minimizar las vulnerabilidades mediante el filtrado de paquetes, el bloqueo del tráfico HTTP y el registro no autorizado.
Lo analizaremos más adelante. Antes de eso, un breve repaso a las principales amenazas a la seguridad.
Inyección SQL (SQLi)
SQLi -La inyección SQL es una vulnerabilidad de seguridad web que permite al atacante manipular las consultas SQL que una aplicación realiza a la base de datos. Al hacerlo, obtienen acceso a información potencialmente valiosa a la que cualquiera no puede acceder fácilmente.
Un ejemplo sencillo y muy familiar sería aprovechar la entrada no desinfectada del usuario en beneficio del hacker. Supongamos que hay un cuadro de texto que solicita el ID de usuario. Entonces, basándose en el ID de usuario, la consulta recupera toda la información perteneciente a ese usuario.
Así que supongamos que en el cuadro de texto si el usuario había introducido el siguiente:
Id. de usuario 228 o 1=1
Entonces la consulta resultante sería la siguiente:
SELECT * FROM Usuarios WHERE UserId = 228 OR 1=1;A continuación, recuperaría todos los datos de la tabla del usuario, incluidas las contraseñas si la tabla contiene datos de contraseñas.
Para más información sobre SQLi, puede consultar aquí.
Secuencias de comandos en sitios cruzados (XSS)
XSS se produce cuando un usuario inyecta un script malicioso principalmente en javascript a través de campos de entrada no sanitizados. Normalmente, un atacante envía este script malicioso a un usuario que no será sospechoso. El navegador del usuario final no es consciente de que este script es dañino y lo ejecutará.
Como resultado, este script malicioso puede acceder a todos los datos asociados con cookies, tokens de sesión o cualquier otra información sensible. Además, estos scripts pueden reescribir el HTML de una página web.
Autenticación y gestión de sesiones defectuosas
Supongamos que un usuario tiene que iniciar sesión en una aplicación web utilizando las credenciales de inicio de sesión. En ese caso, el algoritmo propietario del sitio web genera un identificador de sesión único para toda la comunicación entre el usuario y el servidor web para esa sesión.
Si los desarrolladores web no han cifrado los datos seguros que viajan de un lado a otro entre el usuario y el servidor web, hay muchas posibilidades de que un intruso los robe y se haga pasar por el usuario. Esta situación se da sobre todo al conectarse a Internet a través de redes WiFi públicas en cafeterías.
Puede consultar este artículo para más información.
¿Cuáles son los métodos para prevenir los ataques web?
Cortafuegos de aplicaciones web
WAF es una defensa de capa 7 en el modelo OSI que se puede colocar en el punto de entrada al servidor de destino, como se muestra en el siguiente diagrama. Protege la red interna del servidor de ataques y oculta la topología de red del servidor.
Para que WAF funcione, debe realizar configuraciones adicionales en el servidor. Al igual que los cortafuegos, WAF filtra el tráfico HTTP entrante y saliente que parece peligroso para la red interna del servidor si no satisfacen las reglas que establezca en el WAF.
WAF es también un tipo de proxy inverso del que hablaremos en la siguiente sección.
Proxy inverso
La función de un servidor proxy es ocultar tu dirección IP y sustituirla por la del servidor proxy. Pues bien, un proxy inverso también hace lo mismo y mejora la seguridad del servidor web ocultándola, así como la topología de red interna del servidor.
El cliente sólo conoce la dirección del servidor proxy, por lo que el servidor real queda oculto para el cliente.
Idealmente, usted puede utilizar un proxy inverso como un Web Application Firewall (WAF) que hemos discutido anteriormente. Puede implementar WAF en aplicaciones web en dispositivos con proxy inverso configurado. Como resultado, el alcance de WAF en la mejora de la seguridad se hace más amplio. El atacante tampoco puede ver la ubicación real del servidor web.
Puede consultar este artículo para obtener más información fundamental sobre los proxies inversos. En la siguiente sección, veremos cómo utilizar un proxy inverso para mitigar los riesgos de la aplicación. Sin embargo, antes de eso, vamos a proporcionarle una visión general de lo que hace un proxy inverso.
¿Cómo funciona la delegación inversa?
Todos los proxies inversos realizan las siguientes operaciones fundamentales:
- El navegador del cliente envía una petición HTTP a una URL pública. Supongamos que la URL es www.host.com en el puerto 80.
- A continuación, como de costumbre, el nombre de host se resuelve en el servidor proxy inverso. Este servidor proxy inverso escucha esta dirección y recibe la solicitud.
- Después de eso, el proxy inverso investiga la URL para determinar dónde tiene que desviar la petición. Normalmente, un proxy inverso puede utilizar cualquier componente de la URL para decidir hacia dónde dirigir la petición. Por ejemplo, puede utilizar el host, el protocolo, la ruta, el puerto o la cadena de consulta. Normalmente, la ruta es el componente principal que decide el enrutamiento.
- Los ajustes de configuración del proxy inverso determinan la URL de salida a la que se enviará la solicitud. Esta URL de salida suele ser el servidor back-end responsable de proporcionar los contenidos. El servidor proxy inverso puede reescribir las partes de la solicitud. Puede, por ejemplo, alterar o añadir segmentos de ruta.
- El proxy inverso también debe actualizar parte de la información de la cabecera HTTP para indicar el servidor web interno, además de reasignar la URL. La cabecera "Host:", por ejemplo, contiene el nombre de host desde el que se solicita la URL.
- Así que para concluir el mapeo de URLs, http://www.host.com puede ser remapeado a http://realhost.com:8080.As, puedes ver que en este caso el hostname cambió a realhost. Entonces el número de puerto también cambió a 8080.
- Por último, el proxy inverso envía la solicitud al servidor real, que la procesa.
- Una vez que el servidor procesa la solicitud, envía la respuesta al proxy inverso.
- A continuación, el proxy inverso hace lo siguiente:
- Modifica la respuesta para que se envíe correctamente al cliente. Esto incluye el campo "Location:", que contiene la ubicación del archivo en el servidor.
- El proxy inverso reasigna las cabeceras y finalmente envía la respuesta al cliente.
Cómo proteger su aplicación web con un proxy inverso
Dado que nuestro objetivo es superar los ciberataques mencionados anteriormente, el proxy inverso necesita realizar funcionalidades adicionales además de los pasos mencionados anteriormente.
Validación del contenido de la solicitud
Cuando un cliente envía una petición al servidor, el proxy inverso depura la entrada comparándola con su base de datos de firmas. Los programadores desarrollan estas firmas con expresiones regulares muy avanzadas. La decisión del proxy inverso de permitir la solicitud con la entrada del usuario se basará únicamente en el enfoque del filtro de la lista de bloqueo y del filtro de la lista blanca.
Enfoque de filtro de lista negra
El filtro de la lista negra almacena las solicitudes dañinas conocidas. A continuación, compara cada solicitud con las entradas de la lista. Si descubre una coincidencia, rechaza la solicitud. Las distintas variaciones de una misma agresión deben registrarse por separado en la lista. Con las listas negras sólo podrá evitar las agresiones conocidas.La exhaustividad de la lista negra contribuye a su eficacia.
Filtro de listas blancas
Un filtro de lista blanca captura toda la colección de peticiones válidas para un sitio específico. Como resultado, la lista blanca previene los ataques permitiendo únicamente que las peticiones conocidas lleguen al servidor. Por otra parte, el proceso de elaboración de una lista blanca lleva mucho tiempo y requiere conocer toda la gama de peticiones legítimas que un usuario puede enviar potencialmente a un servidor.
Además, puede resultar abrumador crear todas las peticiones válidas a cientos de miles de proveedores de bases de datos existentes en caso de inyección SQL.
Cualquier modificación de una aplicación web segura requeriría una actualización de la lista blanca. En consecuencia, mantener una lista blanca aumenta la carga administrativa.
Validación del contenido de la respuesta
Antes de enviar la respuesta del servidor al cliente, el proxy inverso la valida. Para ello se suele utilizar una lista negra. El filtro de la lista negra puede ocultar respuestas conocidas a clientes que no necesitan verlas. Los mensajes de error son un ejemplo de este tipo de datos; el proxy inverso puede sustituir el error por un mensaje de error genérico que no contenga datos sensibles.
Registro de solicitudes y respuestas
El proxy inverso también puede registrar la solicitud para su posterior examen. Lo mejor es configurar el registro sólo para las peticiones que el proxy inverso bloqueó inicialmente. Debe examinar cuidadosamente los registros durante las primeras etapas de la instalación. Esto es esencial para verificar que el proxy inverso no bloquea ninguna petición genuina.
Conclusión
En este artículo, esperamos que comprenda las vulnerabilidades de una aplicación web y cómo puede utilizar un proxy inverso para resolver estas amenazas. De hecho, el proxy inverso no desalojará todas las posibles vulnerabilidades asociadas a las aplicaciones web.
Sin embargo, sería una gran estrategia para mitigar la mayoría de las amenazas que se encuentran en una aplicación web. Así que, finalmente, esperamos que apliques los conceptos aprendidos en este artículo en caso de que experimentes problemas de seguridad en tu aplicación web.