ACTUALIDAD

Los desarrolladores de software son la base sobre la que se apoya cualquier aplicación y/o organización. Para lograr un software seguro, los desarrolladores deben tener el respaldo y la ayuda de la organización para la que escriben el código. Según los desarrolladores de software crean el código que compone una aplicación web, se necesitan adoptar y practicar una amplia variedad de técnicas de codificación segura. Todos los niveles de una aplicación web, la interfaz de usuario, la lógica de negocios, el controlador, el código de la base de datos y más, todos deben desarrollarse teniendo la seguridad en mente. Obviamente, esta puede ser una tarea muy difícil y demasiado a menudo, no se desarrolla correctamente. La mayoría de los desarrolladores no han aprendido sobre la codificación segura o la criptografía en su etapa de formación.

Los lenguajes y marcos que los desarrolladores usan para construir aplicaciones, a menudo carecen de controles centrales críticos o son inseguros por defecto de alguna manera. También, en honor a la verdad, es muy raro que las organizaciones brinden a los desarrolladores requisitos prescriptivos que los guíen por el camino del software seguro, e incluso cuando lo hacen, puede haber errores de seguridad inherentes a los requisitos y diseños. Es por ello que es necesario ser proactivo desde los inicios del diseño del proyecto a realizar, teniendo en cuenta desde el principio la seguridad, como algo más que un mero concepto.

Los 10 principales controles proactivos de OWASP 2016 son una lista de técnicas de seguridad que deberían incluirse en cada proyecto de desarrollo de software. Se ordenan por orden de importancia, siendo el control número 1 el más importante. Este documento está pensado para ayudar a los desarrolladores en el desarrollo seguro. Se ha publicado anteriormente un documento que se planteó en su diseño como una introducción, el presente documento debe ser considerado una ampliación de ese primer pdf de desarrollo seguro.

La lista de los controles a realizar es:

• Verificar la seguridad desde el inicio y a menudo
• Parametrizar consultas
• Codificar datos
• Validar todas las entradas
• Implementar controles de identidad y autenticación
• Implementar controles de acceso apropiados
• Proteger datos
• Implementar el registro y la detección de intrusos
• Aprovechar los marcos de seguridad y las bibliotecas
• Manejo de errores y excepciones

¿Cómo podemos realizarlos?

Comencemos por el inicio:

Verificar la seguridad desde el inicio y a menudo

En muchas organizaciones (en casi todas a decir verdad), las pruebas de seguridad se realizan fuera de los bucles de prueba de desarrollo, siguiendo un enfoque de «escanear y luego arreglar». El equipo de desarrollo ejecuta una herramienta de escaneo o lleva a cabo una prueba de lápiz y papel, sin validez real a efectos prácticos, clasifica los resultados y luego presenta una lista de vulnerabilidades para ser reparadas y así se suele quedar. Obviamente, no hay que ser un genio para percatarse que hay mejores maneras. Esto sulele conocerse como » the hamster wheel of pain» (algo así como “la rueda de dolor del hámster”).

Las pruebas de seguridad deben ser parte integral de la práctica de ingeniería de software de un desarrollador. Del mismo modo que no puede «probar la calidad», no puede «probar la seguridad» realizando pruebas de seguridad al final de un proyecto. Se debe verificar la seguridad de manera temprana y lo más frecuentemente posible, ya sea mediante pruebas manuales o pruebas y escaneos automatizados. Obviamente esto retrasa los plazos y lógicamente debe ser tenido en cuenta desde el inicio del diseño de la aplicación por tema de plazos y demás.

Se debe incluir seguridad al escribir tareas de prueba. Se deben incluir los controles proactivos en los resguardos y controladores. Puede considerarse OWASP ASVS como una guía para definir los requisitos de seguridad y las pruebas. Debes considerar las protecciones de datos desde el inicio del desarrollo. La seguridad debe ser incluida por adelantado cuando se defina la estructura, no hacerlo implica si o si, problemas seguros a posteriori.

El estiramiento de correcciones en varios sprints se puede evitar si el equipo que revisa la seguridad en el planteamiento y desarrollo, se esfuerza por convertir la salida de escaneo en controles proactivos reutilizables para evitar problemas. De lo contrario, se debe enfocar la salida de escaneos de seguridad como una etapa, abordando los resultados en más de un sprint.

Como parte del desarrollo debe plantearse la necesidad de implementar medidas de testing durante la fase de desarrollo. Para ello OWASP tiene un proyecto de testing del código.

Orientado a ayudarnos en este proceso debemos usar también el proyecto ASVS o Application Security Verification Standard Project.

En cuanto a testing, debemos tener en cuenta como punto de partida:

Proyecto de pruebas OWASP (testing)

El Proyecto de Pruebas OWASP ha estado en desarrollo durante muchos años. El objetivo del proyecto es intentar ayudar a las personas a comprender qué, por qué, cuándo, dónde y cómo probar aplicaciones web. El proyecto entrega un marco de prueba completo, no es simplemente una simple lista de verificación o prescripción de problemas que deberían abordarse. Los desarrolladores pueden usar este marco como plantilla para construir sus propios programas de prueba o para calificar los procesos de otras personas. La Guía de prueba intenta describe en detalle tanto el marco de prueba general como las técnicas requeridas para implementar el marco en la práctica.

Diseñar la Guía de prueba es una tarea difícil. Fue un todo desafío obtener consenso y desarrollar contenido que permitiera a las personas aplicar los conceptos descritos en la guía, al tiempo que les permitía trabajar en su propio entorno y cultura. Asimismo también fue un desafío cambiar el enfoque de las pruebas de aplicaciones web de las pruebas de penetración a las pruebas integradas en el ciclo de vida del desarrollo de software.

Muchos expertos de la industria y profesionales de la seguridad, algunos de los cuales son responsables de la seguridad del software en algunas de las empresas más grandes del mundo, están validando este marco de prueba. Este marco ayuda a las organizaciones a probar sus aplicaciones web para crear software confiable y seguro. El marco no solo destaca áreas de debilidad, aunque este último es sin duda un subproducto de muchas de las guías y listas de verificación de OWASP. Como tal, hubo que tomar decisiones difíciles sobre la idoneidad de ciertas técnicas y tecnologías de prueba. Se comprende que no todos estarán de acuerdo con todas estas decisiones. Sin embargo, OWASP puede tomar el control y cambiar la cultura a través del tiempo a través de la conciencia y la educación basada en el consenso y la experiencia, ninguna de sus normas está cerrada a modificaciones si procediera.

¿Cuándo probar realizar el testing?

Actualmente, en la mayoría de los desarrollos no se prueba el software hasta que ya se haya creado y esté en la fase de implementación de su ciclo de vida (es decir, el código se haya creado e instanciado en una aplicación web en funcionamiento). En general, ésta es una práctica ineficaz y totalmente prohibitiva en cuanto a costos.

Uno de los mejores métodos para evitar que aparezcan errores de seguridad en las aplicaciones de producción es mejorar el Ciclo de vida de desarrollo de software (SDLC) al incluir seguridad en cada una de sus fases. Un SDLC es una estructura impuesta en el desarrollo de artefactos de software. Si un SDLC no se usa actualmente en su entorno, es hora de elegir uno. La siguiente figura muestra un modelo de SDLC genérico así como el costo creciente (estimado) de corregir errores de seguridad en dicho modelo.

¿Qué testear?

Es muy útil pensar en el desarrollo de software como una combinación de varios elementos: personas, procesos y tecnología. Si éstos son los factores que «crean» el software, entonces es lógico deducir que éstos sean los factores que deben probarse. Hoy en día, la mayoría de la gente generalmente prueba la tecnología o el software en sí, nunca estos elementos conjuntados.

Un programa de prueba efectivo debe tener componentes que prueben:

• Gente: para garantizar que haya una educación y conciencia de seguridad adecuadas;

• Proceso: para garantizar que existan políticas y estándares adecuados y que las personas sepan cómo seguir estas políticas;

• Tecnología: para garantizar que el proceso haya sido eficaz en su implementación.

A menos que se adopte un enfoque holístico, probar solo la implementación técnica de una aplicación no descubrirá las vulnerabilidades operacionales o de gestión que podrían estar presentes. Al evaluar a las personas, las políticas y los procesos, una organización puede detectar problemas que luego se manifestarían en defectos en la tecnología, lo que eliminará los errores de manera temprana e identificará las causas de las consecuencias. Del mismo modo, probar solo algunos de los problemas técnicos que pueden estar presentes en un sistema dará como resultado una evaluación de postura de seguridad incompleta e inexacta.

Denis Verdon, Jefe de Seguridad de la Información en Fidelity National Financial presentó una excelente analogía para este error en la Conferencia OWASP AppSec 2004 en Nueva York: «Si los coches se construyeran como aplicaciones, las pruebas de seguridad solo asumirían el impacto frontal. Los automóviles no se probarán ni se probarán en busca de estabilidad en maniobras de emergencia, efectividad del freno, impacto lateral y resistencia al robo».

Principios de prueba

Existen algunos conceptos erróneos comunes al desarrollar una metodología de prueba para encontrar errores de seguridad en el software. Vamos a intentar cubrir algunos de los principios básicos que los profesionales deben tener en cuenta al realizar pruebas de seguridad en el software.

Si bien es tentador y extremadamente cómodo pensar que un escáner de seguridad o firewall de aplicación proporciona muchas defensas contra ataques o identificará una multitud de problemas, en realidad no hay una solución mágica para el problema del software inseguro. El software de evaluación de seguridad de la aplicación, si bien es útil como primer paso para encontrar algunos vectores de entrada, generalmente es ineficaz en las evaluaciones en profundidad o en la cobertura de prueba adecuada. Debemos recordar siempre que la seguridad es un proceso y no un producto.

Debemos pensar estratégicamente, no tácticamente

En los últimos años, los profesionales de la seguridad se han dado cuenta del error del modelo de «parche y penetración» que fue omnipresente en la seguridad de la información durante los años noventa, a día de hoy se ha comprobado que simplemente, no funciona. El modelo de parche y penetración implica corregir un error informado, pero sin una investigación adecuada de la causa raíz, síntoma inequívoco de repetición. Este modelo generalmente se asocia con la ventana de vulnerabilidad que se muestra en la figura a continuación. La evolución de las vulnerabilidades en el software común utilizado en todo el mundo ha demostrado la ineficacia de este modelo.

Los estudios de vulnerabilidad han demostrado que con el tiempo de reacción de los atacantes en todo el mundo, la típica ventana de vulnerabilidad no proporciona suficiente tiempo para la instalación del parche, ya que el tiempo entre una vulnerabilidad que se descubre y un ataque automatizado contra el desarrollo y liberación disminuye todos los años vertiginisamente.

Hay varias suposiciones incorrectas en el modelo de parche y penetración. Muchos usuarios creen que los parches interfieren con las operaciones normales y pueden romper las aplicaciones existentes, lo cual es cierto en parte. Asimismo, también es incorrecto suponer que todos los usuarios conocen los parches recién lanzados. En consecuencia, no todos los usuarios de un producto aplicarán parches, ya sea porque creen que el parche puede interferir con el funcionamiento del software o porque no tienen conocimiento de la existencia del parche.

Es muy importante diseñar seguridad en el ciclo de vida de desarrollo de software (SDLC) para evitar problemas de seguridad recurrentes dentro de una aplicación. Los desarrolladores pueden construir seguridad en el SDLC mediante el desarrollo de estándares, políticas y directrices que se ajusten y funcionen dentro de la metodología de desarrollo. El modelado de amenazas y otras técnicas deben usarse para ayudar a asignar recursos apropiados a aquellas partes de un sistema que están en mayor riesgo.

El SDLC es Rey

El SDLC es un proceso que es bien conocido por los desarrolladores. Al integrar la seguridad en cada fase del SDLC, permite un enfoque holístico de la seguridad de las aplicaciones que aprovecha los procedimientos que ya existen en la organización. Tenga en cuenta que si bien los nombres de las diversas fases pueden cambiar dependiendo del modelo SDLC utilizado por una organización, cada fase conceptual del arquetipo SDLC se usará para desarrollar la aplicación (es decir, definir, diseñar, desarrollar, implementar, mantener). Cada fase tiene consideraciones de seguridad que deberían formar parte del proceso existente, para garantizar un programa de seguridad integral y rentable.

Existen varios marcos de SDLC seguros que existen que proporcionan consejos descriptivos y prescriptivos. Si una persona recibe asesoramiento descriptivo o prescriptivo depende de la madurez del proceso SDLC. Básicamente, el asesoramiento prescriptivo muestra cómo debería funcionar el SDLC seguro, y el asesoramiento descriptivo muestra cómo se usa en el mundo real. Ambos tienen su lugar. Por ejemplo, si no sabemos por dónde empezar, un marco prescriptivo puede proporcionar un menú de posibles controles de seguridad que se pueden aplicar dentro del SDLC. El asesoramiento descriptivo puede ayudar a conducir el proceso de decisión presentando lo que ha funcionado bien para otras organizaciones. Los SDLC seguros descriptivos incluyen BSIMM-V; y los SDLC seguros preceptivos incluyen el modelo de madurez Open Software Assurance de OWASP (OpenSAMM)

Probar temprano y a menudo

Cuando se detecta un error temprano en el SDLC, puede abordarse más rápido y a un menor costo. Un error de seguridad no es diferente en absoluto de un error funcional o basado en el rendimiento en este sentido. Un paso esencial para hacer esto posible es educar al desarrollo y a los equipos de control de calidad acerca de los problemas de seguridad comunes y las formas de detectarlos y prevenirlos. Aunque las nuevas bibliotecas, herramientas o idiomas pueden ayudar a diseñar mejores programas (con menos errores de seguridad), surgen constantemente nuevas amenazas y los desarrolladores deben ser conscientes de las amenazas que afectan el software que están desarrollando. La educación en pruebas de seguridad también ayuda a los desarrolladores a adquirir la mentalidad adecuada para probar una aplicación desde la perspectiva de un atacante. Esto permite que cada organización considere los problemas de seguridad como parte de sus responsabilidades existentes.

Comprender el alcance de la seguridad

Es importante saber cuánta seguridad requerirá un proyecto determinado. La información y los activos que deben protegerse deben tener una clasificación que establezca cómo se deben manejar (por ejemplo, confidencial, secreto, alto secreto). Deben discutirse con el consejo legal para garantizar que se cumplan los requisitos de seguridad específicos. Para las organizaciones con sede en los países de la UE, se pueden aplicar tanto la regulación específica del país como las Directivas de la UE. Por ejemplo, la Directiva 96/46 / CE stablece que es obligatorio tratar los datos personales en las aplicaciones con la debida diligencia, cualquiera que sea la aplicación.

Desarrollo de la mentalidad correcta

Probar con éxito una aplicación de vulnerabilidades de seguridad requiere pensar «fuera de la caja» (“out of the box”). Los casos de uso normales comprobarán el comportamiento normal de la aplicación cuando un usuario la esté usando de la manera esperada. Las buenas pruebas de seguridad deben ir más allá de lo esperado e intentar pensar como un atacante que está tratando de romper la aplicación. El pensamiento creativo puede ayudar a determinar qué datos inesperados pueden hacer que una aplicación falle. También puede ayudar a encontrar qué suposiciones hechas por los desarrolladores web no siempre son ciertas y cómo pueden ser subvertidas. Una de las razones por las que las herramientas automáticas no son funcionales para probar automáticamente las vulnerabilidades, es que este pensamiento creativo debe hacerse caso por caso, ya que la mayoría de las aplicaciones web se desarrollan de forma única (incluso cuando se utilizan marcos comunes).

Comprender el tema

Una de las primeras iniciativas importantes en cualquier buen programa de seguridad debe ser exigir una documentación precisa de la aplicación. La arquitectura, los diagramas de flujo de datos, los casos de uso, etc. deben escribirse en documentos formales y estar disponibles siempre para su revisión. La especificación técnica y los documentos de la aplicación deben incluir información que enumere no solo los casos de uso deseados, sino también cualquier caso de uso específicamente no permitido. Finalmente, es bueno tener al menos una infraestructura de seguridad básica que permita el monitoreo y la tendencia de los ataques contra las aplicaciones y la red de una organización (por ejemplo, sistemas IDS o NIDS).

Usa las herramientas correctas

Si bien ya hemos declarado que no existe una herramienta mágica, las herramientas juegan un papel fundamental en el programa de seguridad general. Existe una gama de herramientas comerciales y de código abierto que pueden automatizar muchas tareas de seguridad de rutina. Estas herramientas pueden simplificar y acelerar el proceso de seguridad ayudando al personal de seguridad en sus tareas. Sin embargo, es importante comprender exactamente qué pueden y no pueden hacer estas herramientas para que no se las venda en exceso o se usen incorrectamente.

El diablo está en los detalles

Es fundamental no realizar una revisión de seguridad superficial de una aplicación y considerarla completa. Esto infundirá una falsa sensación de confianza que puede ser tan peligrosa como no haber realizado una revisión de seguridad en primer lugar. Es vital revisar cuidadosamente los hallazgos y descartar cualquier falso positivo que pueda permanecer en el informe. Informar un hallazgo de seguridad incorrecto mina el mensaje válido del resto de un informe de seguridad. Se debe tener cuidado para verificar que se haya probado cada sección posible de la lógica de la aplicación, y que se exploró cada caso de uso para detectar posibles vulnerabilidades.

Utilice el código fuente cuando esté disponible

Si bien los resultados de las pruebas de penetración de la caja negra pueden ser impresionantes y útiles para demostrar cómo se exponen las vulnerabilidades en un entorno de producción, no son la forma más efectiva o eficiente de proteger una aplicación. Es difícil para las pruebas dinámicas probar toda la base de códigos, particularmente si existen muchas sentencias condicionales anidadas. Si el código fuente de la aplicación está disponible, se le debe dar al personal de seguridad para ayudarlos mientras realizan su revisión. Es posible descubrir vulnerabilidades dentro del origen de la aplicación que se perderían durante un compromiso de recuadro negro.

Desarrollar métricas

Una parte importante de un buen programa de seguridad es la capacidad de determinar si las cosas están mejorando. Es importante hacer un seguimiento de los resultados de los trabajos de prueba y desarrollar métricas que revelen las tendencias de seguridad de la aplicación dentro de la organización.

Las buenas métricas mostrarán:

• Si se requiere más educación y capacitación;

• Si hay un mecanismo de seguridad particular que no es claramente entendido por el equipo de desarrollo;

• Si la cantidad total de problemas relacionados con la seguridad que se encuentran cada mes está disminuyendo.

Las métricas consistentes que se pueden generar de forma automatizada a partir del código fuente disponible también ayudarán a la organización a evaluar la efectividad de los mecanismos introducidos para reducir errores de seguridad en el desarrollo de software. Las métricas no se desarrollan fácilmente, por lo que el uso de métricas estándar como las proporcionadas por el proyecto OWASP Metrics y otras organizaciones es un buen punto de partida.

Las inspecciones manuales

Las inspecciones manuales son revisiones humanas que típicamente prueban las implicaciones de seguridad de personas, políticas y procesos. Las inspecciones manuales también pueden incluir la inspección de decisiones tecnológicas tales como diseños arquitectónicos. Por lo general, se llevan a cabo analizando la documentación o realizando entrevistas con los diseñadores o propietarios de sistemas.

Si bien el concepto de inspecciones manuales y exámenes humanos es simple, pueden ser una de las técnicas más poderosas y eficaces disponibles. Al preguntarle a alguien cómo funciona algo y por qué se implementó de una manera específica, el probador puede determinar rápidamente si es probable que cualquier preocupación de seguridad sea evidente. Las inspecciones y revisiones manuales son una de las pocas maneras de probar el proceso del ciclo de vida del desarrollo de software y de asegurar que existe una política adecuada o un conjunto de habilidades en su lugar.

Al igual que con muchas cosas en la vida, cuando se llevan a cabo inspecciones y revisiones manuales se recomienda que se adopte un modelo de confianza, pero verificado. No todo lo que el probador muestre o diga será exacto. Las revisiones manuales son particularmente buenas para comprobar si las personas entienden el proceso de seguridad, han sido informadas de las políticas y tienen las habilidades apropiadas para diseñar o implementar una aplicación segura.

Otras actividades, incluida la revisión manual de la documentación, las políticas de codificación segura, los requisitos de seguridad y los diseños arquitectónicos, deben realizarse utilizando inspecciones manuales.

Ventajas:

• No requiere tecnología de apoyo
• Se puede aplicar a una variedad de situaciones
• Flexible
• Promueve el trabajo en equipo

Desventajas:

• Puede consumir mucho tiempo
• Material de apoyo no siempre disponible
• Requiere un pensamiento y una habilidad humana significativa para ser eficaz

Modelado de amenazas

El modelado de amenazas se ha convertido en una técnica bastante popular para ayudar a los diseñadores de sistemas a pensar en las amenazas de seguridad que podrían enfrentar sus sistemas y aplicaciones. Por lo tanto, el modelado de amenazas puede ser visto como una evaluación de riesgos para las aplicaciones. De hecho, permite al desarrollador plantear estrategias de mitigación para vulnerabilidades potenciales y les ayuda a concentrar sus recursos inevitablemente limitados y su atención en las partes del sistema que más lo requieren. Se recomienda que todas las aplicaciones tengan un modelo de amenaza desarrollado y documentado. Los modelos de amenazas deben crearse lo antes posible en el SDLC, y deben revisarse a medida que la aplicación evolucione y avance el desarrollo.

Para desarrollar un modelo de amenaza, recomendamos adoptar un enfoque simple que siga la norma NIST 800-30 para la evaluación de riesgos. Este enfoque implica:

• Descomposición de la aplicación – utilice un proceso de inspección manual para comprender cómo funciona la aplicación, sus activos, funcionalidad y conectividad.

• Definir y clasificar los activos – clasificar los activos en activos tangibles e intangibles y clasificarlos según su importancia comercial.

• Explorar vulnerabilidades potenciales – ya sean técnicas, operativas o de gestión.

• Explorar las amenazas potenciales: desarrolle una visión realista de los posibles vectores de ataque desde la perspectiva del atacante, utilizando escenarios de amenaza o árboles de ataque.

• Crear estrategias de mitigación – desarrollar controles de mitigación para cada una de las amenazas consideradas realistas.

El resultado de un modelo de amenaza en sí mismo puede variar, pero normalmente el resultado es una colección de listas y diagramas. La Guía de Revisión de Código OWASP describe una metodología de Modelado de Amenaza de Aplicación que puede ser usada como referencia para las aplicaciones de prueba para posibles fallas de seguridad en el diseño de la aplicación. No existe una forma correcta o incorrecta de desarrollar modelos de amenazas y realizar evaluaciones de riesgo de información en las aplicaciones.

Ventajas:

• Vista práctica del sistema desde el punto de vista del atacante
• Flexible
• Temprano en el SDLC

Desventajas:

• Técnica relativamente nueva
• Los buenos modelos de amenazas no significan automáticamente un buen software

Revisión del código fuente

La revisión del código fuente es el proceso de comprobación manual del código fuente de una aplicación web para problemas de seguridad. Muchas vulnerabilidades de seguridad graves no pueden ser detectadas con ninguna otra forma de análisis o prueba. Casi todos los expertos en seguridad están de acuerdo en que no hay sustituto válido para mirar el código. Toda la información para identificar problemas de seguridad se encuentra en algún lugar del código. A diferencia de probar software cerrado de terceros como sistemas operativos, cuando se prueban aplicaciones web (especialmente si han sido desarrolladas internamente) el código fuente debe estar disponible para propósitos de prueba.

Muchos problemas de seguridad no intencionales, pero significativos, son también extremadamente difíciles de descubrir con otras formas de análisis o pruebas, como las pruebas de penetración, haciendo que el análisis del código fuente sea la técnica de elección para las pruebas técnicas. Con el código fuente, un probador puede determinar con precisión lo que está sucediendo (o se supone que está sucediendo) y eliminar el trabajo de adivinanza de la prueba de caja negra.

Ejemplos de temas que son particularmente propicios para ser encontrados a través de revisiones de código fuente incluyen problemas de concurrencia, lógica de negocio defectuosa, problemas de control de acceso y debilidades criptográficas, así como puertas traseras, troyanos, huevos de Pascua, bombas de tiempo, bombas lógicas y otras formas de código malicioso. Estos problemas a menudo se manifiestan como las vulnerabilidades más dañinas en los sitios web. El análisis del código fuente también puede ser extremadamente eficiente para encontrar problemas de implementación, como lugares donde no se realizó la validación de entrada o donde pueden estar presentes procedimientos de control abierto de fallas. Pero debemos tener en cuenta que los procedimientos operativos también necesitan ser revisados, ya que el código fuente que se está implementando podría no ser el mismo que el que se está analizando aquí.

Ventajas:

• Integridad y eficacia
• Precisión
• Rápido (para revisores competentes)

Desventajas:

• Requiere desarrolladores de seguridad altamente cualificados
• Puede omitir problemas en las bibliotecas compiladas
• No detecta fácilmente errores en tiempo de ejecución
• El código fuente realmente desplegado podría diferir del que se está analizando.

Pruebas de penetración

Las pruebas de penetración han sido una técnica comúnmente utilizada para probar la seguridad de la red durante muchos años. También se conoce comúnmente como pruebas de caja negra o hacking ético. Las pruebas de penetración son esencialmente el «arte» de probar una aplicación en ejecución de forma remota para encontrar vulnerabilidades de seguridad, sin conocer el funcionamiento interno de la propia aplicación. Típicamente, el equipo de prueba de penetración tendría acceso a una aplicación como si fueran usuarios. El pentester actúa como un atacante e intenta encontrar y explotar vulnerabilidades. En muchos casos, el probador recibirá una cuenta válida en el sistema.

Aunque las pruebas de penetración han demostrado ser efectivas en seguridad de red, la técnica no se traduce naturalmente en aplicaciones. Cuando se realizan pruebas de penetración en redes y sistemas operativos, la mayoría del trabajo consiste en encontrar y explotar vulnerabilidades conocidas en tecnologías específicas. Como las aplicaciones web son casi exclusivamente a medida, las pruebas de penetración en el campo de las aplicaciones web son más parecidas a la investigación pura. Se han desarrollado herramientas de prueba de penetración que automatizan el proceso, pero con la naturaleza de las aplicaciones web su efectividad suele ser pobre.

Mucha gente hoy en día utiliza las pruebas de penetración de aplicaciones web como su principal técnica de pruebas de seguridad. Aunque ciertamente tiene su lugar en un programa de pruebas, no creemos que deba considerarse como la primera o única técnica de pruebas. Si pasas una prueba de penetración no sabes que no tienes un problema muy grave «. Sin embargo, las pruebas de penetración enfocadas (es decir, las pruebas que intentan explotar vulnerabilidades conocidas detectadas en revisiones anteriores) pueden ser útiles para detectar si algunas vulnerabilidades específicas están realmente corregidas en el código fuente desplegado en el sitio web.

Ventajas:

• Puede ser rápido (y por lo tanto barato)
• Requiere un conjunto de habilidades relativamente más bajo que la revisión del código fuente.
• Prueba el código que realmente está siendo expuesto

Desventajas:

• Demasiado tarde en el SDLC
• Sólo pruebas de impacto frontal.

Necesidad de un enfoque equilibrado del testing

Con tantas técnicas y enfoques para probar la seguridad de las aplicaciones web puede ser difícil entender qué técnicas utilizar y cuándo usarlas. La experiencia nos demuestra que no hay una respuesta correcta o incorrecta a la pregunta de qué técnicas se deben utilizar exactamente para construir un marco de pruebas viable. De hecho, todas las técnicas probablemente deberían utilizarse para probar todas las áreas que necesitan ser probadas.

Aunque es evidente que no existe una técnica única que pueda aplicarse para cubrir eficazmente todas las pruebas de seguridad y garantizar que se han resuelto todos los problemas, muchas empresas adoptan un único enfoque. El enfoque utilizado históricamente ha sido la prueba de penetración. Las pruebas de penetración, si bien son útiles, no pueden abordar eficazmente muchos de los problemas que necesitan ser probados

El enfoque correcto, es un enfoque equilibrado que incluye varias técnicas, desde revisiones manuales hasta pruebas técnicas. Un enfoque equilibrado debe cubrir las pruebas en todas las fases del SDLC. Este enfoque aprovecha las técnicas más apropiadas disponibles dependiendo de la fase actual del SDLC.

Lógicamente, hay momentos y circunstancias en los que solamente una técnica es posible. Por ejemplo, una prueba en una aplicación web que ya se ha creado, pero en la que la parte de prueba no tiene acceso al código fuente. En este caso, las pruebas de penetración son claramente mejores que ninguna prueba. Sin embargo, debe alentarse a las partes en el ensayo a que cuestionen los supuestos, como la falta de acceso al código fuente, y a que estudien la posibilidad de realizar ensayos más completos.

Un enfoque equilibrado varía dependiendo de muchos factores, como la madurez del proceso de pruebas y la cultura corporativa. Se recomienda que un marco de pruebas equilibrado se parezca a las representaciones mostradas en la Figura 3 y la Figura 4. La siguiente figura muestra una representación proporcional típica superpuesta al ciclo de vida del desarrollo de software. De acuerdo con la investigación y la experiencia, es esencial que las empresas pongan un mayor énfasis en las primeras etapas de desarrollo.

Manual Testing Owasp

¿Qué es ASVS?

El proyecto OWASP Application Security Verification Standard (ASVS) proporciona una base para probar los controles técnicos de seguridad de aplicaciones web y también proporciona a los desarrolladores una lista de requisitos para un desarrollo seguro.

El objetivo principal del proyecto OWASP Application Security Verification Standard (ASVS) es normalizar el rango en la cobertura y nivel de rigor disponible en el mercado cuando se trata de realizar la verificación de seguridad de aplicaciones Web utilizando un estándar abierto comercialmente utilizable. El estándar proporciona una base para probar los controles técnicos de seguridad de las aplicaciones, así como los controles técnicos de seguridad en el entorno, que se utilizan para proteger contra vulnerabilidades como Cross-Site Scripting (XSS) e inyección SQL. Este estándar se puede utilizar para establecer un nivel de confianza en la seguridad de las aplicaciones Web. Los requisitos se desarrollaron teniendo en cuenta los siguientes objetivos:

• Usar como una métrica – Proporcione a los desarrolladores y propietarios de aplicaciones una vara de medida con la que evaluar el grado de confianza que se puede depositar en sus aplicaciones Web.

• Utilizar como guía – Proporcionar orientación a los desarrolladores de control de seguridad sobre qué incorporar en los controles de seguridad para satisfacer los requisitos de seguridad de las aplicaciones.

• Uso durante la adquisición – Proporcionar una base para especificar los requisitos de verificación de seguridad de la aplicación en los contratos.

Cobertura de los puntos de este proyecto

Los puntos que cubre este proyecto son:

• Arquitectura

• Autenticación

• Gestión de sesiones

• Control de Acceso

• Validación de entrada y codificación de salida

• Criptografía

• Manejo de errores

• Protección de datos

• Comunicaciones

• Código malicioso

• Defectos de la lógica empresarial

• Archivos y recursos

• Móvil

• API

• Configuración

• Internet de las cosas

Puntos ampliados

Arquitectura

Además de los controles técnicos, el ASVS requiere que existan procesos que garanticen que la seguridad se ha abordado explícitamente al planificar la arquitectura de la aplicación o API, y que se conozcan las funciones funcionales y de seguridad de todos los componentes. Dado que las aplicaciones de una sola página actúan como clientes de API o servicios remotos, debe garantizarse que también se apliquen las normas de seguridad adecuadas a dichos servicios, ya que no basta con probar la aplicación de forma aislada.

La categoría «Arquitectura» enumera los requisitos de arquitectura y diseño de la aplicación. Como tal, esta es la única categoría que no asigna a casos de pruebas técnicas en la Guía de Pruebas OWASP. Para cubrir temas tales como el modelado de amenazas, SDLC seguro, gestión de claves, los usuarios del ASVS deben consultar los respectivos proyectos OWASP y/u otros estándares, como los que se indican a continuación.

1. Autenticación

La autenticación es el acto de establecer, o confirmar, algo (o alguien) como auténtico, es decir, que las afirmaciones hechas por o acerca de la cosa son verdaderas. Asegúrese de que una aplicación verificada satisface los siguientes requisitos de alto nivel:

• Verifica la identidad digital del remitente de una comunicación.
• Garantiza que sólo las personas autorizadas sean capaces de autenticarse y que las credenciales se transporten de forma segura.

Gestión de sesiones

Uno de los componentes centrales de cualquier aplicación basada en web es el sistema por el cual se controla y mantiene el estado de un usuario que interactúa con ella. Esto se denomina Gestión de sesiones y se define como el conjunto de todos los controles que gobiernan la interacción completa entre un usuario y la aplicación basada en web.

Asegúrese de que una aplicación verificada satisface los siguientes requisitos de gestión de sesiones de alto nivel:

• Las sesiones son únicas para cada individuo y no pueden ser adivinadas o compartidas.
• Las sesiones se invalidan cuando ya no son necesarias y se anulan durante los períodos de inactividad.

Control de Acceso

El control de accesos es el concepto de permitir el acceso a los recursos sólo a quienes tienen permiso para utilizarlos. Debemos asegurarnos de que una aplicación verificada cumple los siguientes requisitos de alto nivel:

• Los usuarios que acceden a los recursos tienen credenciales válidas para hacerlo.

• Los usuarios están asociados con un conjunto bien definido de roles y privilegios.

• Los metadatos de roles y permisos están protegidos contra la reproducción o manipulación.

Validación de entrada y codificación de salida

La debilidad más común en la seguridad de las aplicaciones web es la falta de validación adecuada de los datos que provienen del cliente o del entorno antes de utilizarlo. Esta debilidad conduce a casi todas las principales vulnerabilidades en las aplicaciones web, tales como scripting cross site, inyección SQL, inyección de intérprete, ataques locale/Unicode, ataques de sistemas de archivos y desbordamientos de búfer.

Asegúrese de que una aplicación verificada satisface los siguientes requisitos de alto nivel:

• Todas las entradas están validadas para ser correctas y utilizables para el propósito previsto.

• Los datos de una entidad externa o cliente nunca deben ser confiables y deben tratarse en consecuencia SIEMPRE.

Criptografía

Debemos asegurarnos de que una aplicación verificada satisface los siguientes requisitos de alto nivel:

• Que todos los módulos criptográficos fallan de forma segura y que los errores son manejados correctamente.
• Que se utilice un generador de números aleatorios adecuado cuando se requiera aleatoriedad.
• Que el acceso a las llaves se gestione de forma segura.

Manejo de errores

El objetivo principal del manejo y registro de errores es proporcionar una reacción útil por parte del usuario, administradores y equipos de respuesta a incidentes. El objetivo no es crear cantidades masivas de registros, sino registros de alta calidad.

Los registros de alta calidad a menudo contienen datos confidenciales y deben estar protegidos según las leyes o directivas locales de privacidad de datos. Esto debe incluir:

• No recopilar o registrar información confidencial si no se requiere específicamente.

• Asegurar que toda la información registrada sea manejada de forma segura y protegida según su clasificación de datos.

• Asegurar que los troncos no sean para siempre, sino que tengan una vida útil absoluta lo más corta posible.

• Si los registros contienen datos privados o confidenciales, cuya definición varía de un país a otro, los registros se convierten en la información más sensible que posee la aplicación y, por lo tanto, resultan muy atractivos para los atacantes por derecho propio

Protección de datos

Hay tres elementos que debemos clave para una sólida protección de datos: Confidencialidad, Integridad y Disponibilidad (CIA). Este estándar supone que la protección de datos se aplica en un sistema fiable, como un servidor, que ha sido reforzado y tiene suficientes protecciones.

Las aplicaciones tienen que asumir que todos los dispositivos del usuario están comprometidos de alguna u otra manera. Cuando una aplicación transmite o almacena información confidencial en dispositivos inseguros, como ordenadores, teléfonos y tabletas compartidos, la aplicación es responsable de garantizar que los datos almacenados en estos dispositivos estén cifrados y no puedan obtenerse, alterarse o divulgarse fácilmente de forma ilícita.

Asegúrese de que una aplicación verificada satisface los siguientes requisitos de protección de datos de alto nivel:

• Confidencialidad: Los datos deben protegerse de la observación o divulgación no autorizadas tanto en tránsito como almacenados.
• Integridad: Los datos deben estar protegidos al ser creados, alterados o borrados maliciosamente por atacantes no autorizados.
• Disponibilidad: Los datos deben estar disponibles para los usuarios autorizados según sea necesario.

Comunicaciones

Debemos aseegurarnos de que una aplicación verificada satisface los siguientes requisitos de alto nivel:

• Usa SSL/TLS se utiliza cuando se transmiten datos confidenciales.
• Que algoritmos y cifradores fuertes son usados en todo momento.

Código malicioso

Debemos estar seguros de que una aplicación verificada satisface los siguientes requisitos de alto nivel:

• La posible actividad maliciosa puede manejarse maneja de forma segura y correcta para no afectar al resto de la aplicación.

• No tienen bombas de tiempo u otros ataques basados en factores temporales incorporados en ellas.

• No realice llamadas a destinos maliciosos o no autorizados.

• Las aplicaciones no tienen puertas traseras (backdoors) o fallas lógicas que pueden ser controladas por un atacante.

El código malicioso es extremadamente raro y difícil de detectar. La revisión manual de código línea por línea puede ayudar a buscar bombas lógicas, pero incluso el revisor de código más experimentado luchará por encontrar código malicioso aunque sepa que existe. Esta sección no es posible completarla sin acceso al código fuente, incluyendo tantas bibliotecas de terceros como sea posible.

Defectos de la lógica empresarial

La aplicación verificada debe satisfacer los siguientes requisitos de alto nivel:

• El flujo lógico de negocio es secuencial y en orden
• La lógica de negocio incluye límites para detectar y prevenir ataques automatizados, tales como pequeñas transferencias de fondos continuas o la adición de un millón de amigos de uno en uno, etcétera.
• Los flujos de lógica de negocios de alto valor han considerado los casos de abuso y los actores maliciosos, y tienen protecciones contra el engaño, la manipulación, el repudio, la divulgación de información y la elevación de los ataques de privilegios.

Archivos y recursos

La aplicación verificada debe cumplir los siguientes requisitos de alto nivel:

• Los datos de archivos no fiables deben tratarse en consecuencia y de forma segura SIEMPRE.
• Obtenido de fuentes no confiables se almacenan fuera del webroot y los permisos limitados SIEMPRE.

Móvil

API

Debemos de que que una aplicación verificada que utilice servicios web basados en RESTful o SOAP tenga:

• Autenticación adecuada, gestión de sesión y autorización de todos los servicios web
• Validación de entrada de todos los parámetros que pasan de un nivel de confianza inferior a uno superior.
• Interoperabilidad básica de la capa de servicios web SOAP para promover el uso de la API

Configuración

Es nuestra obligación asegurarnos de que una aplicación verificada por nosotros tenga:

• Bibliotecas y plataformas actualizadas.
• Una configuración segura por defecto.
• Suficiente endurecimiento para que los cambios iniciados por el usuario a la configuración predeterminada no expongan innecesariamente o creen debilidades o fallas de seguridad a los sistemas subyacentes.

Internet de las cosas

Los dispositivos embebidos/IoT deberían:

• Tener el mismo nivel de controles de seguridad dentro del dispositivo que el encontrado en el servidor, mediante la aplicación de controles de seguridad en un entorno de confianza.
• Los datos delicados almacenados en el dispositivo deben guardarse de forma segura.
• Todos los datos confidenciales transmitidos desde el dispositivo deben utilizar la seguridad de la capa de transporte.

Manual Asvs Castellano

Para más información de todo lo expuesto anteriormente puede consultar las siguientes referencias:

Referencias

• OWASP Testing Guide

• OWASP ASVS

Herramientas

• OWASP ZAP

• OWASP Web Testing Environment Project