Registro de cambios: el proyecto OWASP Top 10

Las aplicaciones web se han disparado en complejidad durante la última década. Han evolucionado desde simples contenedores para formularios de contacto y encuestas hasta aplicaciones completas. Podemos compararlos con las aplicaciones de escritorio pesadas, tanto en tamaño como en rendimiento. Con un fuerte aumento de la complejidad y un número cada vez mayor de aplicaciones ricas en funciones, se ha convertido en una necesidad invertir mucho tiempo y cuidado para hacer que todos los componentes de la aplicación sean lo más seguros posible. El aumento masivo de usuarios de Internet ha hecho que sea aún más importante abordar el tema de la protección de los usuarios de datos y aplicaciones. Hay una gran cantidad de amenazas que intentan colarse y causar dolores de cabeza severos a todos los involucrados.

En 2001, una nueva organización entró en escena. Su objetivo era combatir los problemas de seguridad que afectaban a sitios web y aplicaciones. Se le denominó apropiadamente Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP). Actualmente, publica recursos, organiza conferencias y propone estándares sobre seguridad web y de aplicaciones. Un estándar de facto para la seguridad de aplicaciones web es el OWASP Top Ten Project. Enumera las diez amenazas de seguridad más frecuentes. Los factores influyentes a la hora de decidir qué se incluye fueron una gran cantidad de datos y comentarios de la comunidad. A fines de 2017, hubo una actualización del proyecto. Varios problemas nuevos críticos para muchas aplicaciones web modernas recibieron su lugar, mientras que algunos se escaparon de la lista.

Este artículo complementa la lista original e ilustra los últimos cambios en la lista. Describe las amenazas, trata de proporcionar ejemplos claros para facilitar la comprensión y propone formas de combatir las amenazas a la seguridad.

Problemas eliminados de la lista OWASP Top 10

Antes de la actualización de 2017, la lista de 2013 era la más reciente. Teniendo en cuenta los cambios en la forma en que ahora se construyen y consumen las aplicaciones web, solo tenía sentido hacer una revisión exhaustiva. Los microservicios se están llevando su parte del pastel, y nuevos marcos geniales y brillantes están reemplazando el equipo de batalla del código de vainilla. Estos hechos significan que algunas de las amenazas enumeradas anteriormente se eliminaron y algunas nuevas ocuparon su lugar.

Nos aseguraremos de refrescar nuestra memoria de los problemas olvidados en este artículo, así como de presentar los nuevos lobos malos. Aprender sobre la historia es la única manera segura de no repetir los mismos errores.

Falsificación de solicitud entre sitios

La falsificación de solicitudes entre sitios (CSRF) es uno de los "perdedores" en la iteración reciente del proyecto. Desapareció porque muchos marcos web modernos incluyen mecanismos de defensa CSRF. La probabilidad de exponer sus aplicaciones a la amenaza disminuye rápidamente.

Independientemente de que CSRF salga de la lista, sigue siendo bueno para refrescar nuestra memoria. Asegurémonos de que no vuelva más fuerte que nunca.

En esencia, CSRF es un exploit que parece una bomba de humo. Un atacante engaña a un usuario desprevenido para que ejecute una solicitud o acción no deseada dentro de una aplicación web. En pocas palabras, un atacante obliga a su víctima a enviar una solicitud a una aplicación de terceros, y la víctima no se da cuenta de que la solicitud se envió. La solicitud podría ser una solicitud HTTP GET para recuperar un recurso o, peor aún, una solicitud HTTP POST que cambia un recurso bajo el control de la víctima. Durante el ataque, la víctima piensa que todo está bien, la mayoría de las veces sin siquiera darse cuenta de que algo está sucediendo en el fondo. Después de que el aire se aclara, el daño ya está hecho o falta algo, y nadie sabe qué sucedió.

La autenticación previa exitosa del usuario dentro de la aplicación de destino es lo que permite que la trampa sea efectiva. En algún momento antes del ataque, el usuario había iniciado sesión en una aplicación. La aplicación envió a la víctima una cookie para recordarlos. Una vez que el navegador web envía la solicitud maliciosa, la cookie se envía automáticamente junto con cualquier carga útil potencial y la aplicación no se opone a enviar la solicitud a un usuario que ya conoce.

Uno de los ejemplos más famosos es engañar a un usuario para que transfiera dinero de su cuenta a la que controla un atacante. Un usuario inicia sesión en un sistema de banca electrónica para consultar el saldo de su cuenta. Después de eso, visitan un foro en línea para consultar las reseñas de un nuevo teléfono móvil. Un atacante, pescando con dinamita, publica una reseña que incluye una imagen con un hipervínculo de imagen aparentemente roto. En lugar de un hipervínculo real, el atacante utiliza un hipervínculo que el sistema de banca electrónica utiliza internamente para transferir dinero de la cuenta A a la cuenta B: https://payments.dummybank.com?receiver=attacker&amount=100 . El sistema bancario convierte al usuario autenticado en el remitente y el valor del parámetro "receptor" en el receptor de los fondos. Por supuesto, el atacante especifica su cuenta en el extranjero como receptor.

Dado que el navegador carga imágenes automáticamente al mostrar la página, la solicitud se realiza en segundo plano. Si el sistema de pago del banco implementa transferencias de dinero mediante una solicitud HTTP GET, nada impide que ocurra el desastre. Tenga en cuenta que el ejemplo es simple y lo más probable es que las transferencias no se manejen a través de HTTP GET. Sin embargo, el atacante puede, con un poco más de dificultad, lograr cambiar el atributo "acción" en el formulario de publicación de mensajes HTML del foro. Luego, el navegador envía la solicitud al sistema de pago del banco, en lugar del back-end del foro.

Robar dinero es solo uno de los muchos ejemplos que existen. Cambiar las direcciones de correo electrónico de los usuarios o realizar compras no deseadas también se incluyen en esta categoría. Como suele suceder, la ingeniería social y algunos conocimientos técnicos son una palanca efectiva contra un error de ingeniería de software.

Al diseñar sus sistemas, tenga en cuenta lo siguiente:

• No utilice solicitudes HTTP GET para encapsular acciones que modifican un recurso. Solo debe utilizar estas solicitudes para recuperar información. Recuerde, la regla general es hacer que las solicitudes GET sean idempotentes.
• Cuando transfiere datos internamente mediante solicitudes HTTP POST, tiende a enviar los datos en JSON, XML o algún otro formato que no sea codificar los parámetros como una cadena de consulta. El uso de un formato de datos no trivial reduce el peligro de que alguien cree un formulario HTML falso que enviará los datos a su servicio.
• Asegúrese de crear e incluir un token único e impredecible en sus formularios HTML. Estos tokens también deben ser únicos para cada solicitud. Verificar la presencia y corrección de dichos tokens reducirá los riesgos de que ocurran amenazas. Para descubrir el token y usarlo en sus solicitudes falsas, los atacantes tendrían que acceder a su sistema y tomar un token directamente desde allí. Dado que los tokens son de una sola vez, no pueden reutilizarlos en el código malicioso.

Esta vulnerabilidad tiene un efecto aún peor cuando se combina con secuencias de comandos entre sitios (XSS). Si un atacante puede inyectar código malicioso en un sitio web o aplicación favorita, el alcance del ataque se vuelve mucho más significativo y peligroso. Aún más crítico, los atacantes pueden eludir algunos de los mecanismos de protección contra CSRF si los ataques XSS son posibles.

Tenga en cuenta que CSRF no ha desaparecido, simplemente no es tan común como solía ser.

Redireccionamientos y reenvíos no validados

Muchas aplicaciones, después de finalizar una acción, redirigen o remiten a un usuario a otra parte de la misma, o incluso a otra aplicación. Por ejemplo, iniciar sesión con éxito en una aplicación activa una redirección a la página de inicio o la página que el usuario visitó inicialmente. Muy a menudo, el destino es parte de la acción del formulario o la dirección de los enlaces. Si el componente que maneja la redirección o el reenvío no se asegura de que la dirección de destino sea realmente la que generó la aplicación, surge una amenaza potencial. Esta es una vulnerabilidad de seguridad llamada "redireccionamientos y reenvíos no validados".

Las dos razones principales por las que los redireccionamientos y reenvíos no validados se considerarían peligrosos son el phishing y el secuestro de credenciales. Un atacante puede lograr alterar la ubicación de destino de redireccionamiento/reenvío y enviar a un usuario a una aplicación maliciosa casi indistinguible de la original. Un usuario desprevenido revela sus credenciales e información confidencial a un tercero malicioso. Antes de que se den cuenta de lo que había sucedido, ya es demasiado tarde.

Como ejemplo, las aplicaciones web muy a menudo implementan el inicio de sesión con soporte para redireccionamientos a la última página visitada. Para poder hacer esto fácilmente, el atributo de acción de un formulario HTML podría parecerse a http://myapp.example.com/signin?url=http://myapp.example.com/puppies . Eres un gran admirador de los cachorros, por lo que tiene sentido instalar una extensión de navegador que reemplace los favicons del sitio web con las miniaturas de tus cachorros favoritos. Desafortunadamente, es un mundo de perro-come-perro. El autor de la extensión del navegador decidió sacar provecho de su amor incondicional e introdujo una "característica" adicional. Cada vez que visita su sitio favorito de fans de cachorros, reemplaza el parámetro "url" en el atributo de acción del formulario con un enlace a su propio sitio. Dado que el sitio se ve exactamente igual, cuando proporciona los detalles de su tarjeta de crédito para comprar naipes de cachorros, de hecho está financiando a un atacante malicioso, no a su pasatiempo.

Resolver la vulnerabilidad implica verificar la ubicación de destino asegurándose de que sea la deseada. Si un marco o biblioteca realiza la redirección completa o la lógica de reenvío, es beneficioso verificar la implementación y actualizar el código si es necesario. De lo contrario, debe realizar comprobaciones manuales para protegerse contra el ataque.

Hay varios tipos de cheques que puede hacer. Para obtener la mejor protección, utilice una combinación de varios enfoques en lugar de quedarse con uno solo de ellos.

• Valide la URL saliente asegurándose de que apunte al dominio que controla.
• En lugar de usar direcciones explícitas, codifíquelas en el front-end y luego decodifique y valide en el back-end.
• Prepare una lista blanca de URL de confianza. Permite reenvíos y redireccionamientos solo a las ubicaciones incluidas en la lista blanca. Prefiera este enfoque a mantener una lista negra. Las listas negras generalmente se llenan con elementos nuevos solo cuando sucede algo malo. Las listas blancas son más restrictivas.
• Emplee un enfoque utilizado por LinkedIn y algunas otras aplicaciones: presente a sus usuarios una página pidiéndoles que confirmen una redirección/reenvío, dejando en claro que están abandonando su aplicación.

Problemas combinados

La mayoría de los problemas de la lista se pueden etiquetar como defectos en la implementación, ya sea por falta de conocimiento o por una investigación insuficientemente profunda de las amenazas potenciales. Ambas razones pueden atribuirse a la falta de experiencia y la solución para considerarlas en el futuro es fácil: solo asegúrese de aprender más y ser más minucioso. Uno especialmente complicado se basa en una combinación del rasgo peligroso (pero muy humano) de hacer demasiadas suposiciones junto con la dificultad de desarrollar y mantener sistemas informáticos complejos. Una vulnerabilidad que encaja en esta categoría es el "control de acceso roto".

Control de acceso roto

Una vulnerabilidad es causada por una autorización y un control de acceso inadecuados o por la ausencia total de ciertas partes de la aplicación. En las iteraciones anteriores del Proyecto OWASP Top Ten, hubo dos problemas: referencias directas a objetos inseguras y falta de control de acceso a nivel de función. Ahora se fusionan en uno debido a su similitud.

Referencias directas a objetos

Las referencias directas a objetos se utilizan a menudo en las direcciones URL para identificar los recursos en los que se está operando. Por ejemplo, cuando un usuario inicia sesión, puede visitar su perfil haciendo clic en un enlace que contiene su identificador de perfil. Si ese mismo identificador se almacena en la base de datos y se usa para recuperar la información del perfil, y la aplicación asume que las personas pueden acceder a la página del perfil solo a través de una página de inicio de sesión, cambiar el identificador del perfil en la URL expone la información del perfil de otro usuario.

Una aplicación que establece la URL del formulario de eliminación de perfil http://myapp.example.com/users/15/delete deja en claro que hay al menos otros 14 usuarios dentro de la aplicación. Descubrir cómo llegar al formulario de eliminación de otros usuarios no es ciencia espacial en este caso.

La solución a este problema es realizar verificaciones de autorización para cada recurso sin asumir que solo se pueden tomar ciertas rutas para llegar a algunas partes de la aplicación. Además, eliminar las referencias directas y usar las indirectas es otro paso adelante porque dificulta que los usuarios malintencionados descubran cómo se crea la referencia.

Durante el desarrollo, como medida de precaución, escriba un diagrama de máquina de estado simple. Deje que los estados representen diferentes páginas dentro de su aplicación y las transiciones de las acciones que los usuarios pueden realizar. Esto facilita la lista de todas las transiciones y páginas que necesitan atención especial.

Control de acceso a nivel de función faltante

La falta de control de acceso a nivel de función es muy similar a las referencias a objetos directos inseguros. En este caso, los usuarios modifican la URL o algún otro parámetro para intentar acceder a partes protegidas de la aplicación. Si no hay un control de acceso adecuado que examine los niveles de acceso, un usuario puede obtener acceso privilegiado a los recursos de la aplicación o al menos cierto conocimiento de su existencia.

Tomando prestado del ejemplo para referencias directas a objetos, si una aplicación asume que un usuario que visita el formulario de eliminación es un superusuario solo porque los superusuarios pueden ver el enlace al formulario de eliminación, sin realizar ninguna autorización adicional, se abre una gran falla de seguridad. Contar con la disponibilidad de algún elemento de la interfaz de usuario no es un control de acceso adecuado.

El problema se resuelve asegurándose siempre de realizar comprobaciones en todas las capas de su aplicación. Es posible que la interfaz de front-end no sea la única forma en que los usuarios malintencionados pueden acceder a su capa de dominio. Además, no confíe en la información transmitida por los usuarios sobre sus niveles de acceso. Realice un control de sesión adecuado y siempre verifique dos veces los datos recibidos. El hecho de que el cuerpo de la solicitud diga que el usuario es un administrador no significa que lo sea.

El control de acceso roto ahora combina todos los problemas relacionados con un control de acceso insuficiente, ya sea a nivel de la aplicación o del sistema, como una mala configuración del sistema de archivos.

Nuevos problemas en la lista OWASP Top 10

La llegada de nuevos marcos front-end y la adopción de nuevas prácticas de desarrollo de software cambiaron las preocupaciones de seguridad a temas completamente nuevos. Las nuevas tecnologías también lograron resolver algunos problemas comunes con los que antes lidiamos manualmente. Por lo tanto, resultó beneficioso revisar la lista y ajustarla de acuerdo con las tendencias modernas.

Entidades externas XML

El estándar XML ofrece una idea poco conocida llamada entidad externa, que forma parte de la definición de tipo de datos (DTD) del documento. Permite a los autores de documentos especificar enlaces a entidades externas a las que luego se puede hacer referencia e incluir en el documento principal. Un ejemplo muy sencillo sería:

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

Durante el análisis, una referencia &bar; se reemplaza con el contenido de la entidad definida, lo que genera <foo>baz</foo> .

Si la aplicación tomara una entrada externa y la incluyera, sin ninguna verificación, directamente en la definición del documento XML, sería posible una amplia gama de fugas de datos y ataques.

Lo mágico es que la entidad no tiene que ser una simple cadena, puede ser una referencia a un archivo en el sistema de archivos. El analizador XML estará encantado de tomar el contenido del archivo especificado e incluirlo en la respuesta generada, lo que podría revelar información confidencial del sistema. Como ilustra OWASP, sería muy fácil obtener información sobre los usuarios del sistema definiendo la entidad como

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Una "característica" especialmente problemática de esta vulnerabilidad es la posibilidad de ejecutar fácilmente un ataque de denegación de servicio. Una forma fácil de hacerlo sería enumerar el contenido de un archivo interminable como /dev/random . El otro es crear una secuencia de entidades, cada una haciendo referencia a la anterior muchas veces. Esto convierte la referencia final en una raíz de un árbol potencialmente muy ancho y profundo cuyo análisis podría agotar la memoria del sistema. Este ataque incluso se conoce como Billion Laughs. Como se muestra en Wikipedia, se definen una serie de entidades ficticias, lo que genera una oportunidad para que un atacante incluya mil millones de lols en el documento final.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

La prevención de explotaciones de entidades externas de XML podría realizarse mediante el uso de un formato de datos menos complejo. JSON es un buen reemplazo, siempre que se tomen algunas precauciones debido a posibles ataques en su contra. La actualización de las bibliotecas XML es imprescindible, junto con la desactivación del procesamiento de entidades externas y DTD. Como siempre, valide y desinfecte los datos provenientes de fuentes no confiables antes de usarlos o incluirlos en sus documentos.

Deserialización insegura

Al escribir código, los desarrolladores tienen el poder de controlar los sistemas que están desarrollando utilizando el código que escriben. ¿Qué tan maravilloso sería controlar el comportamiento de los sistemas de terceros que escriben solo un poco o incluso nada de código? Gracias al hecho de que las personas no son perfectas y que las bibliotecas tienen fallas, esto definitivamente es posible.

El estado y la configuración de la aplicación a menudo se serializan y almacenan. A veces, los navegadores sirven como motores de almacenamiento si los datos serializados están estrechamente relacionados con el usuario actual. Una aplicación que intente ser inteligente y ahorrar tiempo de procesamiento podría usar una cookie para marcar que un usuario ha iniciado sesión. Dado que la cookie solo se puede crear después de que el inicio de sesión haya sido exitoso, tiene sentido almacenar el nombre de usuario en la cookie. A continuación, se autentica y autoriza a un usuario en función de la existencia y el contenido de la cookie. Si la gente no tuviera malas intenciones, nada podría salir mal. Para ser honesto, tampoco deben ser curiosos.

Si un usuario curioso encuentra una cookie en su máquina, podría ver algo como esto:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

Un diccionario de Python perfectamente válido serializado en JSON, nada especial al respecto. El usuario siempre curioso puede cambiar la fecha de vencimiento para evitar que la aplicación fuerce el cierre de sesión. Un usuario aún más curioso podría intentar modificar el nombre de usuario a "jane.doe" . Si existiera este nombre de usuario, abriría un mundo completamente nuevo para el usuario desprevenido que ahora tiene acceso a datos privados.

Un ejemplo simple de serializar datos en JSON y mantener todo transparente está lejos de ser lo peor que le puede pasar. Si un atacante logra modificar algunos datos serializados, es posible que pueda modificarlos de una manera que obligue a su sistema a ejecutar código arbitrario.

Supongamos que está creando una API REST que permite a las personas escribir sus propios modelos de aprendizaje automático en Python y subirlos a su servicio. El servicio evaluará los modelos cargados y los entrenará usando sus conjuntos de datos. Esto permite que las personas utilicen sus recursos informáticos y una gran cantidad de conjuntos de datos disponibles para crear modelos de forma rápida y sencilla.

El servicio no almacena el código en formato de texto sin formato. Los usuarios seleccionan su código, lo cifran con su clave privada y lo envían a la API para su capacitación. Cuando el servicio necesita ejecutar un modelo, descifra el código, lo descifra y lo ejecuta. La parte complicada es que el protocolo pickle no es seguro. El código se puede construir de manera que permita la ejecución de código malicioso arbitrario durante la deserialización.

El protocolo pickle de Python permite que las clases definan un método __reduce__ , que devuelve información sobre cómo deserializar un objeto personalizado. Uno de los valores de retorno admitidos es una tupla de dos argumentos: un invocable y una tupla de argumentos para pasar al invocable. Teniendo en cuenta que su sistema de entrenamiento de modelos ML tiene como objetivo proporcionar la máxima flexibilidad de estructura de código, es posible escribir el siguiente código:

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

Una vez que el objeto debe deserializarse (desengancharse), se llama a una list de funciones con un solo argumento. La list de funciones es un constructor de listas en Python, y la función itertools.count produce un iterador infinito de valores, comenzando con el parámetro pasado. Convertir un iterador infinito en una lista finita puede tener consecuencias desastrosas para el rendimiento y la estabilidad de su sistema.

La única cura real para este tipo de vulnerabilidad es optar por no deserializar los datos provenientes de fuentes externas. En caso de que esto no sea posible, se sugiere utilizar una suma de verificación o una firma digital para evitar la deserialización de los datos que posiblemente hayan sido modificados por un usuario malintencionado. Además, intente configurar un entorno de espacio aislado desvinculado de su sistema principal para limitar los efectos de los problemas que puedan surgir.

Cuando utilice bibliotecas externas para deserializar datos, por ejemplo, de XML o JSON, intente elegir las que le permitan realizar comprobaciones de tipo de objeto antes de que se haya ejecutado un procedimiento de deserialización real. Esto podría detectar tipos de objetos inesperados cuyo único propósito es dañar su sistema.

Al igual que con todas las demás acciones que realiza su aplicación, aplique un registro y una supervisión exhaustivos. Las deserializaciones que ocurren con frecuencia o fallan más de lo normal son señales de que algo malo está sucediendo. Detecte los problemas temprano.

Registro y monitoreo insuficientes

¿Cuánto tiempo dedica a asegurarse de registrar todas las advertencias y errores que ocurren en su aplicación? ¿Solo almacena los errores que ocurren en el código o también registra los errores de validación? ¿Qué sucede cuando no se cumplen las reglas comerciales de su dominio? La falta de persistencia de todas las actividades erróneas y sospechosas en su aplicación presenta un compromiso de seguridad y datos.

Imagina el siguiente escenario. Su aplicación contiene una página de inicio de sesión, como la mayoría. El formulario tiene dos campos, uno para ingresar un correo electrónico y otro para una contraseña. Si un usuario intenta iniciar sesión y proporciona una contraseña incorrecta, puede volver a intentarlo. Desafortunadamente, la cantidad de intentos incorrectos no está limitada, por lo que la página de inicio de sesión no se bloqueará después de N intentos fallidos. Un atacante puede aprovechar esta oportunidad y, dado un correo electrónico correcto, seguir ingresando contraseñas de una tabla de arcoíris hasta que una combinación finalmente tenga éxito. Siempre que su aplicación sea lo suficientemente segura y usted haga hash de las contraseñas antes de ingresarlas en una base de datos, este ataque en particular no funcionará. Sin embargo, ¿tiene un mecanismo para identificar intrusiones?

El hecho de que este intento no haya podido abrir su página de inicio de sesión no significa que otro no lo hará. La página de inicio de sesión probablemente tampoco sea la única puerta trasera potencial que tiene. Si no fuera por otra cosa, alguien podría intentar usar el control de acceso roto en su contra. Incluso las aplicaciones perfectamente diseñadas deben saber que alguien está intentando atacarlas, aunque no sea posible. Aunque siempre lo es.

Para hacer todo lo posible para protegerse contra tales ataques, siga los siguientes pasos:

• Registre todas las fallas y advertencias que ocurren en la aplicación, ya sean excepciones lanzadas en el código o errores de control de acceso, validación y manipulación de datos. Toda la información almacenada debe replicarse y persistir durante el tiempo suficiente para que sea posible la inspección y el análisis retrospectivos.
• Es importante determinar el formato y la capa de persistencia. Tener un archivo enorme con formato de texto arbitrario es fácil de lograr; procesarlo más tarde no lo es. Elija una opción de almacenamiento que facilite el almacenamiento y la lectura de los datos y un formato que permita una (des)serialización fácil y rápida. Almacenar JSON en una base de datos que permite un acceso rápido facilita el uso. Mantenga la base de datos pequeña haciendo copias de seguridad con regularidad.
• Si está tratando con datos importantes y valiosos, mantenga un registro de las acciones que se pueden seguir para auditar el estado final. Implementar un mecanismo para prevenir la manipulación de datos.
• Haga que los sistemas en segundo plano analicen los registros y le avisen si surge algo. Las comprobaciones, que son tan simples como probar si un usuario intenta acceder repetidamente a una parte protegida de la aplicación, ayudan. Sin embargo, no sobrecargue el sistema con cheques ficticios. Los sistemas de monitoreo deben ejecutarse como servicios separados y no deben afectar el rendimiento del sistema principal.

Cuando resuelva el problema, tenga especial cuidado de no filtrar los registros de errores a usuarios externos. No hacerlo lo hace susceptible a la exposición de información confidencial. El registro y la supervisión deberían ayudarlo a resolver problemas, no a los atacantes a hacer su trabajo de manera más eficiente.

Próximos pasos

Es importante ser consciente de las posibles amenazas y vulnerabilidades en las aplicaciones web. Es aún más importante comenzar a identificarlos en sus aplicaciones y aplicar los parches para eliminarlos.

La atención a la seguridad de las aplicaciones es una parte importante de todos los pasos del proyecto de desarrollo de software. Los arquitectos, desarrolladores y evaluadores de software deben incorporar procedimientos de prueba de software en sus flujos de trabajo. Es beneficioso utilizar listas de verificación de seguridad y pruebas automatizadas en los pasos apropiados del proceso de desarrollo de software para reducir el riesgo de seguridad.

Ya sea que esté analizando una aplicación existente o desarrollando una nueva, debe consultar el Proyecto estándar de verificación de seguridad de aplicaciones (ASVS) de OWASP. El objetivo del proyecto es desarrollar un estándar para la verificación de la seguridad de las aplicaciones. El estándar enumera pruebas y requisitos para desarrollar aplicaciones web seguras. A las pruebas se les asignan niveles del uno al tres, donde uno significa la menor cantidad de peligro y tres significa la mayor amenaza potencial. La clasificación permite a los administradores de aplicaciones decidir cuáles de las amenazas son más probables e importantes. No es necesario incluir cada prueba dentro de cada aplicación.

Tanto los proyectos de aplicaciones web nuevos como los existentes, especialmente aquellos que siguen los principios ágiles, se benefician de la planificación estructurada de los esfuerzos para asegurar sus aplicaciones. La planificación de las pruebas OWASP ASVS es más fácil si decide utilizar OWASP Security Knowledge Framework. Es una aplicación para administrar sprints orientados a pruebas de seguridad, que viene con un conjunto de ejemplos sobre cómo resolver problemas de seguridad comunes y listas de verificación fáciles de seguir basadas en OWASP ASVS.

Si acaba de comenzar a explorar la seguridad de las aplicaciones web y necesita un entorno de pruebas seguro, use una implementación de aplicaciones web de OWASP: WebGoat. Es una implementación intencionalmente insegura de una aplicación web. La aplicación lo guía a través de las lecciones, y cada lección se concentra en una amenaza de seguridad.

Durante el desarrollo de la aplicación, asegúrese de:

• Identificar y priorizar las amenazas. Defina qué amenazas pueden ocurrir de manera realista y representar un riesgo para su aplicación. Priorice las amenazas y decida cuáles merecen el mayor esfuerzo de desarrollo y prueba. No tiene mucho sentido poner mucho esfuerzo en resolver el registro y la supervisión insuficientes si está sirviendo un blog estático.
• Evalúe la arquitectura y el diseño de su aplicación. Algunas vulnerabilidades son muy difíciles de resolver durante las últimas fases del desarrollo de la aplicación. Por ejemplo, si tiene la intención de ejecutar código de terceros y no tiene planes de usar un entorno de espacio aislado, será muy difícil defenderse contra ataques de deserialización e inyección inseguros.
• Actualizar el proceso de desarrollo de software. La prueba contra amenazas de aplicaciones web debe, en la medida de lo posible, ser un proceso automatizado. Es beneficioso aumentar sus flujos de trabajo de CI/CD con pruebas automatizadas que intentan encontrar brechas de seguridad. Incluso puede utilizar su sistema de pruebas unitarias existente para desarrollar pruebas de seguridad y ejecutarlas periódicamente.
• Aprende y mejora. La lista de problemas y vulnerabilidades no es estática y definitivamente no se limita a diez o quince amenazas. Nuevas funcionalidades e ideas abren las puertas a nuevos tipos de ataques. Es importante leer sobre las tendencias actuales en el mundo de la seguridad de aplicaciones web para mantenerse al día. Aplicar lo que aprende; de lo contrario, estás perdiendo el tiempo.

Conclusión

Aunque, como sugiere el nombre, el Proyecto OWASP Top Ten enumera solo diez vulnerabilidades de seguridad, existen miles de posibles trampas y puertas traseras que amenazan sus aplicaciones y, lo que es más importante, sus usuarios y sus datos. Asegúrese de estar atento y actualizar constantemente sus conocimientos porque los cambios y las mejoras tecnológicas tienen ventajas y desventajas.

Ah, y no lo olvides, el mundo no es blanco y negro. Las vulnerabilidades de seguridad no vienen solas; a menudo están entrelazados. Estar expuesto a uno a menudo significa que un montón de otros están a la vuelta de las esquinas, esperando asomar sus feas cabezas y, en algún momento, aunque no sea su culpa, como desarrollador de seguridad del sistema, aún debe reparar las lagunas para frenar. ciberdelincuencia Para ver un ejemplo, consulte Los números de tarjetas de crédito pirateados todavía son aptos para Google .