Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Los mejores documentos en venta realizados por estudiantes que han terminado sus estudios
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Descubre las mejores universidades de tu país según los usuarios de Docsity
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Seguridad en el Desarrollo de Aplicaciones CICLO DE VIDA DE SEGURIDAD EN EL DESARROLLO DE SOFTWARE 1. Proceso de planeación de la aplicación segura 2. Identificación y corrección de vulnerabilidades 3. Paginas consultadas
Tipo: Guías, Proyectos, Investigaciones
1 / 31
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
S e g u r i d a d e n e l D e s a r r o l l o d e A p l i c a c i o n e s
Pag. 4 - Pag.
Tabla de contenido
Pag. 29 Pag. 13 - Pag.
Durante el proceso de estadías se desarrollo una aplicación web híbrida para una agencia aduanal la cual tuvo como principal objetivo notificar al cliente en tiempo real sobre la ubicación de su mercancía y de los posibles problemas o motivos del retraso de esta misma. Descripción breve del proyecto que se tomará de referencia para esta presentación
En un ciclo de desarrollo de software normal se deben de recolectar los requerimientos necesarios para el futuro software a desarrollar (ya sean funcionales o no funcionales) pero además se necesitarán identificar y definir todos los requerimientos relacionados con la seguridad del software para que este sea valido y completo ya que no solo basta con que este funcione correctamente o sea util para nuestro cliente. Por ejemplo: Se requiere que el sistema implemente la autenticación a través de una pantalla de inicio de sesión segura. Los DATOS PERSONALES se cifrarán. Fase #1: Recolección de requerimientos seguros
Se analiza la aplicación en busca de vulnerabilidades. En el SDLC común se elabora un prototipo (algo ligero de lo que tenemos que presentar), pero en el S - SDLC se debe de realizar un modelado de amenazas que permita percibirlas fácilmente. Nos ayuda a detectar defectos en fases tempranas y así evitamos afectar el código y perder tiempo. En esta etapa también se hacen diseños seguro de: Mensajes de error: que no se puedan interactuar con ellos evitando el acceso al sistema Autenticación: evitar que el atacante tenga acceso con 1=1 y descartar esos datos de entrada. Fase #2: Análisis y diseño Durante el desarrollo de este proyecto nunca se realizo un modelado de amenazas. Descripción relacionada con el proyecto
Esta etapa consiste en el propio desarrollo del software, se implementa el código siguiendo las buenas practicas de codificación y aplicando las directrices de programación segura. Durante esta etapa es recomendable que se utilicen herramientas o recursos aprobados y se desprecie cualquier tipo de función insegura (librerías, APIS, etc.) Posteriormente se deben de realizar un análisis de código estático, es decir, revisar el código sin que este se este ejecutando. Fase #3: Implementación y desarrollo En la fase de desarrollo no se realizó ningún tipo de análisis , debido a que no se tuvo conocimiento sobre este y durante el TSU la gran mayoría del tiempo se usó para verificar que el código implementado estuviese "colocado" en su lugar correspondiente, que estuviesen implementados los privilegios, los mensajes de error con lenguaje común, las validaciones, etc. Descripción relacionada con el proyecto
Una vez aplicadas las pruebas estáticas en la codificación, posteriormente se realizan las pruebas dinámicas, es decir, se verifica la funcionalidad del software mientras este mismo se esta ejecutando. Se provocan fallos en el software (introducir datos erróneos) con el único propósito de revelar posibles problemas de seguridad en una etapa donde no se requiere demasiados recursos económicos por así decirlo. Fase #4: Verificación En la fase de desarrollo no se realizó ningún tipo de análisis , debido a que no se tuvo conocimiento sobre este y durante el TSU la gran mayoría del tiempo se usó para verificar la funcionalidad del proyecto más no la seguridad. Solamente se revisó que el código y todo lo que se implementó fuese funcional y concordará con las peticiones realizadas por el cliente más no que fuese seguro. Descripción relacionada con el proyecto
Ya estamos a punto de terminar el S -SDLC. En esta fase se elabora un plan para poder enfrentar cualquier incidente o amenaza que aparezca en un futuro, normalmente estos planes incluyen contactos de emergencia en caso de alguna falla de seguridad. El plan debe de probarse aunque sea una vez antes de usarse. En esta penúltima etapa se certifica el software elaborado para garantizar su seguridad y que todos los requisitos de seguridad se cumplieron. Fase #5: Liberación El software que se realizó para la agencia aduanal no se certificó, pero la empresa tiene toda la información necesaria para poder contactarnos en caso de que surgiera cualquier problema ya sea de seguridad o de software (principalmente de software debido que nunca se tuvo contemplado que nos pudiesen hablar por algún tema relacionado con la seguridad del proyecto). Descripción relacionada con el proyecto
Se realizó la identificación de vulnerabilidades usando como herramienta el software Owasp ZAP
Identificación de vulnerabilidades Catalogo: Inicio de sesión El catalogo es vulnerable a inyección SQL. La única función del código que marca como vulnerable es comparar si lo que se introdujo en una caja de texto es igual a otra. El análisis dice que los resultados se consiguieron manipular aplicando condiciones lógicas AND 1= OR 1=
Identificación de vulnerabilidades Catalogo: Recuperar contraseña El catalogo es vulnerable a inyección SQL. En este caso el código vulnerable esta del lado del servidor. El análisis indica que el tiempo de consulta es controlable a través del valor del parámetro [' / sleep(15) / '], el cual causó que la solicitud tomara [180,000] milisegundos.
En algunas ocasiones la herramienta Owasp ZAP lanza un error llamado " Divulgación de errores de aplicación" especialmente en paginas que se supone son librerías o forman parte de la documentación, eso ocurre principalmente en la carpeta assets. En algunos casos indicaba que se mostraban mensajes de error con lenguaje técnico aunque esto realmente no fuese cierto, al parecer el "error" se encuentra en que cada una de esas librerías o archivos que sirven como documentación contienen las palabras "Parent Directory" Identificación de vulnerabilidades Carpeta assets SOLUCIÓN: Eliminar las palabras "Parent Directory" de todos los archivos
En este caso Owasp Zap marca que en ambos archivos hay credenciales, información relacionada con la configuración del sitio y la administración de este. La descripción del error que arroja Owas Zap indica que con estos archivos se pueden realizar ataques de ingeniería social aunque estos en realidad no contienen ningún tipo de credencial o información relacionada con el cliente. Identificación de vulnerabilidades Server- info & server-status de localhost SOLUCIÓN: Por el momento no se me ocurre que acción pueda implementar debido a que son archivos pertenecientes a localhost-apache. Owasp Zap nos indica que consideremos si algún componente es realmente necesario en producción; si no es así, desactívarlo. Si es así, asegurarnos de que el acceso requiera la autenticación y autorización adecuadas, o que limitemos la exposición solo a sistemas internos o IPs de origen definidas, etc.
