Este es el primer material de una serie de artículos sobre el Proyecto OWASP Top 10, un proyecto que comenzó como una idea para los entusiastas y se convirtió en la fuente más autorizada para clasificar vectores de ataque y vulnerabilidades en aplicaciones web.
En este artículo, analizaremos brevemente todas las vulnerabilidades principales de la lista de los 10 principales de OWASP, y también veremos por qué es tan importante conocer las vulnerabilidades típicas para desarrollar aplicaciones seguras.
Hace unos 10 años, una persona muy observadora formuló un nuevo mantra: HTTP es el nuevo TCP. Por supuesto, no en el sentido de que la persona decidió poner HTTP en el nivel de transporte. De ninguna manera! Es solo que para las comunicaciones modernas, el protocolo HTTP realiza la misma función que TCP en su nivel: la gran mayoría de las aplicaciones modernas, incluidas las móviles, utilizan HTTP como transporte. Y con el advenimiento de HTTP 2.0, esta situación se ha bronceado y en el futuro cercano, aparentemente no cambiará. El protocolo se ha convertido en el estándar de entrega de contenido de facto, y HTTP ya no puede verse como un protocolo web.
Puede parecer que HTTP siempre ha existido, y esto es casi cierto cuando considera que la primera especificación oficial en RFC apareció en 1997, aunque el protocolo en sí comenzó a usarse mucho antes.
Tomó bastante tiempo comprender que tan pronto como el protocolo se vuelva popular, todos comenzarán a usarlo para entregar contenido, a menudo sin las calificaciones adecuadas. Y el resultado será cientos de miles de sistemas vulnerables en todo el mundo y perspectivas vagas para remediar la situación.
En el caso de decisiones de proveedores específicos, siempre puede recurrir a sus materiales o preguntar directamente: "¿cuál es la mejor manera de actuar?" - y obtenga una respuesta calificada, porque al final solo el vendedor es responsable de su producto. Cuando se trata de utilizar herramientas y estándares abiertos para crear aplicaciones, se necesita una fuente imparcial de información sobre las mejores prácticas. Tal fuente puede ser entusiastas, o tal vez toda una comunidad de profesionales en este campo.
Avispa volando
En el campo de la seguridad de las aplicaciones web, el OWASP (Open Web Application Security Project) se ha convertido en una comunidad. Por supuesto, OWASP es una organización sin fines de lucro no afiliada a ninguna compañía de tecnología. Esta situación le permite brindar información práctica imparcial sobre tecnologías de protección de aplicaciones web para organizaciones, instituciones educativas, servicios gubernamentales e incluso personas interesadas en el tema.
Entonces, ¿qué está haciendo exactamente OWASP? Dentro de su competencia, OWASP tiene dos tareas principales: producir documentación y proporcionar herramientas, y de forma totalmente gratuita.
En esta serie de artículos, analizaremos, quizás, el material más popular del Proyecto OWASP TOP 10. Este es un documento que enumera los riesgos más significativos y críticos de las aplicaciones web. La decisión de incluir vulnerabilidades en esta lista se basa en la opinión experta de expertos en seguridad de la información de todo el mundo (sin ella) y, en general, comprender estas vulnerabilidades es el primer paso para cambiar la cultura del desarrollo de software.
Debe comprender claramente que, por regla general, todas estas vulnerabilidades no se basan en los errores de programadores específicos o las vulnerabilidades de los protocolos en sí, sino en los problemas arquitectónicos del diseño de software. Y para los principiantes, esta lista es estrictamente necesaria para estudiar.
Diez hechizos mortales
La lista de vulnerabilidades se actualiza constantemente y para 2017 es la siguiente:
• A1: 2017 - Inyecciones, también conocido como "Inyección de código"
Estamos hablando de todo tipo de inyecciones: SQL, NoSQL, LDAP, cualquier cosa. La inyección de código se hace posible cuando se envían datos no verificados al intérprete como parte de un comando o solicitud. Tal solicitud "maliciosa" se ejecuta de forma segura y hace su propio daño. En el 90% de los casos, cuando escucha que se accedió a una base de datos privada a través de la web, esta es solo nuestra A1.
• A2: 2017: autenticación incorrecta
Las funciones de la aplicación que son responsables de la autenticación y la administración de la sesión a menudo se usan incorrectamente, lo que implica el compromiso de contraseñas, claves, tokens de sesión e incluso la capacidad de interceptar completamente una sesión de usuario. Cuando se sienta en wifi público y de repente descubre que se están realizando algunas acciones en su nombre en recursos web públicos, esto es A2.
• A3: 2017: divulgación de información confidencial
Muchas aplicaciones web y API pueden almacenar y procesar incorrectamente información confidencial, como datos personales. Los atacantes pueden robar o alterar dicha información, lo que puede convertirse en la base de graves pérdidas financieras o de reputación. La información confidencial debe almacenarse adecuadamente y también protegerse durante la transmisión a través de canales de comunicación.
• A4: 2017 - Implementación de entidades XML externas (XXE)
Muchos procesadores XML antiguos o configurados de forma torcida pueden usar datos externos de enlaces en archivos XML. Dichos datos externos pueden contener código malicioso que le permitirá ejecutar casi cualquier código extraño en la máquina de destino.
• A5: 2017 - Control de acceso violado
La matriz de acceso, que era tan buena en el papel, puede probarse incorrectamente en un sistema específico, de modo que los usuarios ilegítimos obtengan fácilmente acceso a áreas cerradas de los sitios o tengan la oportunidad de cambiar los derechos de los recursos a su discreción.
• A6: 2017: Configuración incorrecta de seguridad: errores en la configuración
Aquí estamos hablando de algunas cosas más globales, como la falta de actualizaciones oportunas del servidor y el software de la aplicación, la presencia de información importante en los mensajes de error o incluso en los encabezados HTTP. La aplicación puede ser casi perfecta, pero si el servidor web en el que se ejecuta tiene problemas con la configuración básica, entonces todo es inútil.
• A7: 2017 - Crossite Scripting (XSS)
XSS ocurre cuando una aplicación incluye datos no confiables sin la verificación adecuada. Por ejemplo, el código del programa de un banner publicitario puede contener una secuencia de comandos para interceptar los datos del usuario, la cara del sitio o incluso redirigir de forma transparente a otros sitios.
• A8: 2017 - Deserialización insegura
La deserialización insegura generalmente conduce a la ejecución remota de código. La conclusión es que los datos no confiables pueden destruir la lógica de su aplicación tan pronto como se deserialice. Sin embargo, una vulnerabilidad bastante exótica a primera vista ocupa su lugar de honor en la lista.
• A9: 2017: uso de componentes con vulnerabilidades conocidas
Las bibliotecas, los marcos, los sistemas operativos y otros componentes de los sistemas de información deben actualizarse de manera oportuna. De lo contrario, una vulnerabilidad conocida en una biblioteca puede comprometer un servicio grande que utiliza incluso una función de una biblioteca vulnerable.
• A10: 2017 - Registro y monitoreo inadecuados
Aquí todo es simple: construyó un sistema maravilloso, pero olvidó ajustar las herramientas de monitoreo. Ni siquiera se trata de un sistema SIEM conectado, sino simplemente del registro banal de los eventos del servidor principal. Desafortunadamente, no es raro que los sistemas de pirateo se noten seis meses después del pirateo en sí, y aprenden sobre esto no de los registros, sino de observadores externos.
En los siguientes artículos, comenzaremos a analizar con más detalle cada una de estas vulnerabilidades. Nos armaremos con las herramientas necesarias y veremos cómo se implementan estas vulnerabilidades en la práctica.
Preparado por
Sergey Polunin .