Las aplicaciones web se vuelven cada vez más complejas, pero es normal. Siempre es un desafío mantenerse al día con este crecimiento y siempre saber qué aplicación hace, por qué y cuándo, y qué necesita medidas de seguridad adicionales de su parte.
Este tipo de análisis holístico de la seguridad se conoce como modelado de amenazas. Según los expertos en seguridad de la información, existen diferentes métodos o incluso herramientas para hacerlo. Pero en la raíz de todos ellos hay tres preguntas: ¿Quién puede atacarnos? ¿Qué recursos / componentes protegemos? ¿Cuál es la infraestructura de nuestro sistema?
¿QUIÉN PUEDE ATACARNOS?
La definición de perfiles de posibles agresores te ayudará a comprender cuáles podrían ser las formas más probables de ataque. Esos perfiles obviamente variarán según la industria, el tipo de aplicación y la empresa. Aquí hay unos ejemplos:
Competidores
Pueden estar interesados, entre otras cosas, en robar datos o desalentar a los usuarios al reducir el rendimiento de la aplicación.
Robots / hackers
Los bots semiautomáticos intentarán encontrar puntos débiles de su aplicación para instalar software malicioso para el spamming o la minería de criptomonedas.
Usuarios
Los usuarios de su aplicación pueden encontrar agujeros de seguridad y ver datos que no pueden ver cambiando las ID de usuario en la URL.
Empleados propios
Incluso si tiene plena confianza en sus empleados, pueden convertirse en una amenaza involuntariamente. Puede tratarse de una cookie de sesión robada, una contraseña robada o rota o simplemente un software malicioso instalado en la computadora del trabajador.
El último es especialmente complicado, y el argumento en el sentido de “utilizamos VPN, solo los usuarios de confianza están en él, estamos seguros” ya no es válido cuando uno de ellos tiene su propia computadora infectada. Es difícil predecir cómo se pueden introducir dichos virus; en un nuevo dispositivo USB que se entregó en una caja abierta o correo electrónico falso.
¿QUÉ PROTEGEMOS?
De acuerdo con los profesionales de la seguridad de la información, debe analizar qué tipo de recursos / valores se deben defender.
Componentes
Para comprender todas las formas posibles de ataque, crea un mapa de todos los componentes de tu aplicación. La página principal de la aplicación y su API backend estarían en el centro de ese mapa y eso no es revelador.
Interfaz
La página web suele ser una forma principal para que los usuarios ingresen a la aplicación web. Puede ser vulnerable a muchos tipos de ataques relacionados con el front-end, siendo XSS el más obvio. Inspeccione cada entrada, ya sea un formulario de contacto, una barra de búsqueda o la URL de la página
Back-end
La página web necesita comunicarse de alguna manera con el servidor. Un atacante también puede hacer eso usando la API directamente. No desea que nadie obtenga los valores de las variables de entorno a través del extremo / env del actuador de Spring Boot.
Base de datos
¿Estás seguro de que tu puerto de base de datos no está abierto? ¿Que no hay un administrador de GUI DB instalado bajo una URL secreta que solo el administrador conoce?
Móvil
Este es el canal favorito de los hackers para ingresar al sistema.
La base de código de las aplicaciones móviles se puede desarrollar independientemente de la aplicación principal, lo que puede llevar a olvidar los parches críticos relacionados con la seguridad.
Hoja informativa
¿Es ese contenido parte de la página principal, o es un lugar dedicado solo al boletín informativo? Si está en un espacio separado, entonces otro componente está bajo amenaza.
Componentes de infraestructura / nube
Su aplicación usará muchos componentes adicionales, especialmente en entornos de nube. Cosas como descubrimiento de servicios (por ejemplo, Eureka), herramientas de administración (Spring Boot Admin), registro y métricas (Kibana, Grafana) u otras herramientas de ayuda (Redis, RabbitMQ).
Software de terceros
¿Tal vez tienes un paquete especial de BPM que se encarga de algunos procesos comerciales bajo el capó? ¿O el sistema de gestión de reglas comerciales? ¿O tal vez se integra con las partes contratantes?
Puede haber muchas cosas diminutas que puede olvidar que incluso tiene, como fuentes RSS, servidores de caché o complementos de lujo para la página web.
INFRAESTRUCTURA
Al mapear todos los componentes de software, es hora de obtener una visión similar de la infraestructura.
Protege tu desarrollador y entornos de prueba. Desde el punto de vista del atacante, lo más interesante son los entornos de desarrollo y prueba. Debido a que, por lo general, su configuración de seguridad es más liberal que la de producción, ya que la conveniencia del programador a menudo tiene mayor prioridad que la seguridad del sistema, dijo el analista de seguridad de la información.
Al tener acceso al entorno de desarrollo, un atacante puede hacer muchas cosas desagradables:
- Comprender cómo preparar ataques exitosos en servidores de producción
- Robar datos / contraseñas
- Instalar software malicioso en servidores de desarrollo
- Analiza los registros de depuración detallados
Los repositorios de código fuente también deben estar restringidos del mundo exterior. Con un acceso a él, el atacante podría obtener las contraseñas de tus archivos de configuración.
¿Cómo un intruso podría encontrar sus entornos de desarrollo?
Transferencia de DNS
Una de las primeras cosas que debe intentar es inspeccionar su dominio e intentar transferir la información DNS. Una herramienta que permite esto es el programa host. Definir el tipo de consulta como NS mostrará el registro de servidores de nombres para un dominio dado:
$ host -t NS example.com
servidor de nombres example.com b.iana-servers.net.
servidor de nombres example.com a.iana-servers.net.
Luego, en el modo de lista (habilitado por la opción -l), el host intentará realizar la transferencia de zona.
$ host -l ejemplo.com b.iana-servers.net
Si la transferencia tiene éxito, un atacante verá todos los subdominios registrados, como dev.example.com, test.example.com, qa.example.com, etc., junto con sus direcciones IP. Para evitar esto, verifique su configuración de DNS y asegúrese de que las transferencias de zona estén restringidas.
DNS bruteforcing
Si la transferencia DNS simple falla, un intruso puede tratar de adivinar los subdominios en un proceso llamado forzamiento bruto de DNS. Uno de los programas que puede hacer eso se llama dnsenum. De acuerdo con los expertos en seguridad de la información, cuando se proporciona un archivo de diccionario con una lista de prefijos de dominio, el dominio de destino y el servidor DNS informará todos los subdominios existentes con los candidatos dados. Hay diccionarios públicos para dnsenum, que consisten en muchas suposiciones probables.
Después de obtener las IP de sus servidores, el atacante normalmente escaneará sus puertos, buscará los que estén abiertos y planificará los próximos pasos, dijeron profesionales de la seguridad de la información. Una buena práctica es ocultar todos los entornos de prueba del mundo público en redes privadas, permitiendo el acceso remoto para los trabajadores solo a través de redes VPN.
El último punto que podría tomarse en consideración es el uso de conexiones HTTPS no solo en producción sino también en entornos de prueba. Los certificados pueden estar autofirmados, no importa. Lo importante es que ni sus empleados ni los virus instalados en sus computadoras podrán detectar el tráfico HTTP dentro de la VPN.
0 comments:
Post a Comment