Las pruebas de penetración reportaron cero vulnerabilidades. ¿Esto significa que mi aplicación web es segura?

La respuesta es no . A pesar de que la seguridad es un concepto relativo, debe considerarlo como un ecosistema completo: su aplicación web no es solo su código, sino también los medios para hacer que este código funcione, los medios para respaldar y exponer este código y los medios para interactuar con el usuario:

  • Los navegadores web
  • La red
  • El código de la aplicación
  • La pila de software
  • El sistema operativo
  • Los procedimientos de operación

Un código limpio de vulnerabilidades es un buen comienzo, pero en mi opinión no es suficiente para considerar que su aplicación web es 99% segura.

Repasemos cada componente.

NAVEGADORES WEB

Si el navegador web no es seguro, un atacante puede robar credenciales o cookies de sesión para acceder a su aplicación.

Eche un vistazo a algunas vulnerabilidades conocidas de Firefox, incluidas las que se pueden usar para recopilar datos confidenciales de sitios en otras ventanas o inyectar datos o códigos en esos sitios, que no requieren más que acciones de navegación normales.

Avisos de seguridad de la Fundación Mozilla

Otro problema común es la instalación de extensiones maliciosas. Algunas extensiones del navegador pueden robar credenciales de los administradores de contraseñas:

Defectos de robo de contraseñas en las extensiones de LastPass Chrome y Firefox

Obligado a instalar una extensión de Chrome

RED

Quizás pueda proteger su infraestructura de red utilizando la última tecnología de CheckPoint, Palo-Alto, BlueCoat o cualquier otro fabricante, pero ¿qué pasa con los usuarios de su aplicación web? Un ataque no necesariamente puede ser contra su alojamiento, sino contra sus usuarios menos protegidos.

Si el atacante tiene acceso a la red WiFi de la víctima, puede lanzar un ataque de falsificación de ARP, el primer paso para los ataques de secuestro de sesión (robar ID de sesión y cookies, otorgar a los atacantes acceso a los datos privados de su aplicación web) o Man In The Middle ( MITM) para interceptar y modificar el tráfico entre su aplicación web y sus usuarios.

Spoofing ARP

CÓDIGO DE APLICACIÓN

Si de acuerdo con sus pruebas, el código puede considerarse SEGURO, me gustaría agregar la frase TAN LEJOS.

  • Sus escáneres de vulnerabilidad también son software, por lo que pueden tener errores y darle algunos resultados falsos positivos, sin importar que sean ampliamente conocidos o que cuesten $ 3500.00

Voy a dar algunos ejemplos de algunos escáneres populares:

OpenVAS Bug Tracker

Problemas de NMAP

Problemas de SQLMap

  • Tal vez su aplicación web sea más segura si escribió todo el código desde cero . Hoy en día es una práctica común usar marcos de software e incluso generadores de programas para crear aplicaciones web. No solo se trata de ahorrar costos y tiempo, sino también de hacer que el mantenimiento sea más barato adoptando estándares web y bibliotecas conocidas, reduciendo nuestras líneas de código y permitiéndonos centrarnos en los objetivos reales de la aplicación.

Pero también los marcos de software pueden tener errores y vulnerabilidades:

Vulnerabilidad de Apache Struts siendo explotada por atacantes

Vulnerabilidades de jQuery

Los 10 principales riesgos de seguridad para aplicaciones AngularJS – Kevin Hakanson

PILA DE SOFTWARE

Para que su código funcione, necesitará una pila completa de productos de software:

  • Servidores web: la función principal de un servidor web es almacenar, procesar y entregar páginas web a los clientes. La comunicación entre el cliente y el servidor se lleva a cabo utilizando el Protocolo de transferencia de hipertexto (HTTP). Las páginas entregadas son documentos HTML con mayor frecuencia, que pueden incluir imágenes, hojas de estilo y scripts además del contenido de texto.

Vulnerabilidades del servidor web Apache

Vulnerabilidades de seguridad de Nginx

  • Servidores de aplicaciones : un servidor de aplicaciones es un marco de software que proporciona instalaciones para crear aplicaciones web y un entorno de servidor para ejecutarlas. Son muy comunes para las aplicaciones empresariales de Java.

Vulnerabilidades de Apache Tomcat

Vulnerabilidades de JBOSS

  • Servidores de bases de datos: Un servidor de bases de datos es un programa informático que proporciona servicios de bases de datos a otros programas informáticos o computadoras.

Vulnerabilidades MySQL

Vulnerabilidades de Microsoft SQL Server

Vulnerabilidades de la base de datos Oracle

  • Certificados digitales : los certificados digitales son un componente vital de la infraestructura de clave pública de la Web. Se utilizan para autenticar sitios web y para cifrar las comunicaciones entre un sistema cliente y un servidor. Si un sitio web se ve comprometido o la clave de cifrado privada asociada con un certificado digital está expuesta, se supone que el certificado debe ser revocado para que otros no puedan usarlo para hacerse pasar por el sitio o para espiarlo.

Use un certificado válido de una Autoridad de certificación y asegúrese de que su infraestructura tenga las bibliotecas SSL / TLS correctas para evitar el error Heartbleed.

También puede revisar su certificado digital de acuerdo con esta guía:

Hoja de trucos de protección de la capa de transporte

Y verifique la solidez de sus certificados utilizando:

Prueba del servidor SSL (Desarrollado por Qualys SSL Labs)

SISTEMA OPERATIVO

Las fallas del sistema operativo pueden estar tanto en el lado del cliente como en el lado del servidor. Además, un mal uso del sistema operativo (principalmente en el lado del cliente) puede comprometer todas las aplicaciones.

Por ejemplo, en Android instalando aplicaciones desde repositorios no oficiales o operando en modo raíz (superusuario).

Los riesgos de rootear su teléfono Android – BullGuard

Aplicación falsa de Android Flash Player Malware dirigido a bancos, redes sociales

Si el sistema operativo de su servidor no tiene los últimos parches de seguridad, también puede tener una sorpresa muy desagradable:

Explotando Eternalblue para shell con Empire & Msfconsole – Tutoriales de piratería

Asegúrese de que los últimos parches de seguridad estén instalados de acuerdo con su sistema operativo:

Actualizaciones de seguridad de Microsoft

Aviso de seguridad de Ubuntu

Centro de seguridad de productos de Red Hat

PROCEDIMIENTOS DE OPERACIÓN

Los procedimientos operativos son muy importantes en seguridad. Le recomiendo que adopte una metodología de Riesgo de Seguridad y realice una Evaluación de Riesgo Empresarial:

Introducción al análisis de riesgos de seguridad y evaluación de riesgos de seguridad

“La evaluación de riesgos empresariales y los procesos de gestión de riesgos empresariales constituyen el corazón del marco de seguridad de la información. Estos son los procesos que establecen las reglas y pautas de la política de seguridad mientras transforman los objetivos de un marco de seguridad de la información en planes específicos para la implementación de controles y mecanismos clave que minimizan las amenazas y vulnerabilidades.

Realizar una evaluación de riesgos de seguridad

Debe considerar su respuesta a incidentes de seguridad, porque su aplicación web tal vez no sea segura para siempre de acuerdo con las tendencias de seguridad global.

Por ejemplo, si los piratas informáticos malintencionados inician un ataque de denegación de servicio contra su infraestructura, debe pensar:

  • ¿Cómo manejar los ataques de denegación de servicio?
  • ¿Cómo proteger los datos de sus clientes?
  • ¿Cómo comunicar el incidente a las autoridades, los medios o los clientes?
  • ¿Cómo su proveedor de servicios de Internet o su empresa de alojamiento pueden ayudarlo a manejar el ataque?

6 consejos para combatir los ataques DDoS

Solo eres parte del camino hecho. Mantener a la gente fuera es un buen primer paso, los siguientes son averiguar: cómo detectará cuándo entran, cuál es la cantidad máxima de daño que pueden hacer y cuál será su respuesta.

Muy pocas compañías hacen esos últimos pasos, se quedan como idiotas y dicen: “Ese sorprendente consultor de seguridad dijo que estamos a salvo, pero aún así fuimos pirateados … ¿y ahora qué?” Mantenga su base de datos y sistema de archivos seguros limitando el acceso a la cuenta del sistema solo a lo que se necesita. ¿Su sistema necesita permitir que su base de datos SQL ejecute sentencias de línea de comando usando EXEC? No, así que asegúrate, etc.

Cuando su base de datos es pirateada y copiada, ¿qué información está en texto plano y qué tan difícil será para ellos descifrar o invertir el hash de otros datos, como las contraseñas? Si enumera todos los correos electrónicos de los clientes en texto sin formato, acaba de perder la confianza de los clientes. Si simplemente usas un hash MD5 en tus contraseñas, acabas de perder un 75% + inmediatamente por un ataque de mesa arcoiris.

Cuando la prensa se acerque a ti y te pregunte qué pasó, ¿qué será lo primero que diga? Debería ser: “Detectamos el ataque, limitamos el acceso al sistema, rastreamos la fuente del ataque, parcheamos el sistema, y ​​estamos seguros de que los datos del usuario tomados no se utilizarán porque están muy encriptados”.

Desafortunadamente, las pruebas de seguridad son solo una instantánea y son tan buenas como las herramientas utilizadas y el conocimiento y la habilidad de la persona que realiza las pruebas.

Parece que has hecho mucho, y la falta de vulnerabilidades encontradas por múltiples herramientas respalda un mayor nivel de confianza. Pero debe planificar las pruebas periódicas en curso, por ejemplo, escaneos automáticos de Internet de un servicio de seguridad al menos una vez al mes, y más intensivo con herramientas absolutamente actuales cada 6 meses. También es esencial el uso de un firewall de aplicación web para filtrar solicitudes web maliciosas y sistemas para la detección en tiempo real de posibles actividades de intrusión. Usted menciona “99% seguro”, lo que implica que se da cuenta de que 100% no es posible en el mundo real. Pero hablando en sentido figurado, es ese 1% restante lo que representa la única grieta en tus defensas que puede ser realmente difícil de explotar y tomar un hacker de élite para hacerlo. Pero eventualmente sucederá, por lo que se necesita una vigilancia continua y una nueva prueba para cada sistema conectado a Internet.

Sé que esto es mucho, pero esa es la naturaleza de la amenaza en estos días.

EDITAR: Las vulnerabilidades Heartbleed (OpenSSL) y Shellshock (bash shell) más recientes subrayan la necesidad de estar al tanto de los componentes de software y bibliotecas que usa su sistema, y ​​corregirlos inmediatamente cuando sea necesario. Estas son vulnas que nunca habrían aparecido durante ningún tipo de prueba de seguridad.

“Las pruebas muestran la presencia, no la ausencia de errores”

– Edsger W. Dijkstra (1969)

No existe una aplicación perfectamente segura, solo una donde las vulnerabilidades aún no se hayan encontrado. Nunca asuma lo contrario, y nunca asuma que si usted mismo no ha encontrado ninguna vulnerabilidad, significa que nadie más (especialmente las personas que viven de ese tipo de cosas) no encontrará ninguna, o que ninguna aparecerá después de futuros cambios en el sistema .
.

Diría que agregar escaneo de seguridad automatizado al proceso de desarrollo es una de las formas más eficientes de proteger su aplicación. Las nuevas vulnerabilidades surgen todo el tiempo, por lo que es necesario realizar pruebas de seguridad continuas, y mediante el uso de escáneres de vulnerabilidades automatizados puede ejecutar pruebas de seguridad en una aplicación web de forma regular. De esta manera, el banco de pruebas se puede actualizar tan pronto como se descubran nuevas vulnerabilidades.

Chandan Kumar, que dirige el blog de tecnología Geekflare, ha enumerado algunos de los escáneres de seguridad más utilizados aquí; 12 herramientas gratuitas en línea para escanear vulnerabilidades de seguridad del sitio web y malware (divulgación completa: Detectify, la compañía para la que trabajo, se encuentra entre las compañías listadas).

No Ninguna cantidad de herramientas capturará cada vulnerabilidad, ya que todavía hay vulnerabilidades que no conocen, no pueden probar o aún no se han descubierto.

Además, las pruebas de penetración no deben ser realizadas por el desarrollador del software, sino por una parte externa. Nadie puede atrapar todos sus propios errores.