GUIA DE PRUEBAS OWASP 4.0 ESPAÑOL.pdf

Guia de pruebas 4.0 "Borrador"

FERNANDO VELA

ROBERTO ANDRADE QUITO- ECUADOR

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 1

The world’s largest digital library

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.














































































































































































































































































































































































































































































































































































































































































































































La importancia de tener esta guía en forma totalmente libre y abierta es importante para la misión de las fundaciones. Da a cualquiera la capacidad de entender las técnicas usadas para detectar problemas de seguridad comunes. La seguridad no debe ser un arte oscuro o un secreto cerrado que sólo unos pocos pueden practicar. D ebe estar abi erta a todos y no n o ser exclusiva para los profesionales en seguridad, sino también para desarrolladores de control de calidad y gerentes técnicos. El proyecto para la construcción de esta guía mantiene la experiencia en manos de la gente que lo necesita; usted, yo y cualquier persona que participa en la construcción de software.

Esta guía debe abrirse paso hasta las manos de los desarrolladores y evaluadores de software. No hay suficientes expertos de seguridad de aplicaciones en el mundo para hacer una abolladura significativa en el problema general.

La responsabilidad inicial de seguridad de las aplicaciones debe recaer en los hombros de los desarrolladores; ellos escriben el código. No debería ser una sorpresa que los desarrolladores no están produciendo codificación segura si no la están probando o consideran los tipos de errores que generan la vulnerabilidad.

• Los desarrolladores deben usar esta guía para asegurarse de que están produciendo códigos seguros. Estas pruebas deben ser parte de los procedimientos normale s de los códigos y de la unidad de pru ebas.

• Los evaluadores de software y control de calidad deben usar esta guía para ampliar el conjunto de casos de prueba que emplean en las aplicaciones. Atrapar estas vulnerabilidades tempranamente es un ahorro considerable de tiempo y esfuerzo más adelante.

• Los especialistas en seguridad deben usar esta guía en combinación con otras técnicas como una manera de verificar que no se haya escapado algún agujero de seguridad en la aplicación.

• Los gerentes de proyectos deben considerar la razón por la que esta guía existe y que las cuestiones de seguridad se manifiestan mediante errores de código y diseño.

Lo más importante cuando se realizan pruebas pruebas de seguridad es recordar que se deben priorizar continuamente. Hay un número infinito de posibilidades
















































































general. Eso significa que mientras pueden encontrar algunos problemas genéricos, no tienen suficiente conocimiento de la aplicación para que puedan detectar la mayoría de los errores. En mi experiencia, los más graves graves problemas de seguridad son los que no son genéricos, sino profundamente entrelazados en su lógica de negocio y diseño de la aplicación personalizada.

Estas herramientas también pueden ser seductoras, puesto que encuentran una gran cantidad de problemas potenciales. Mientras que ejecutar las herramientas no toma mucho tiempo, cada uno de los problemas potenciales toma tiempo en investigar y verificar. Si el objetivo es encontrar y eliminar los defectos más graves lo más rápidamente posible, considere si es mejor utilizar su tiempo con herramientas automatizadas o con las técnicas descritas en esta guía. Sin embargo, estas herramientas son, sin duda, parte de un programa de seguridad de aplicaciones bien equilibrado. Usadas sabiamente, pueden apoyar sus procesos globales para producir un código más seguro.

de las aplicaciones, pero no es exhaustiva. Si encuentra errores, por favor agregue una nota en la página de discusión o haga el cambio usted mismo. Estará ayudando a miles de personas que utilizan esta guía.

Por favor, considere unirse a nosotros como miembro individual o corporativo, para que podamos seguir produciendo materiales como esta guía de prueba y todos los otros grandes proyectos en OWASP.

Gracias a todos los participantes pasados y futuros de esta guía; su trabajo ayudará a hacer aplicaciones más seguras en todo el mundo.

Llamado a la acción Eoin Keary, Miembro de la Junta Directiva de OWASP, Abri 19, 2013 Si está construyendo, diseñando o probando software, le animo a familiarizarse con la guía de la prueba de seguridad en este documento. Es un
















































































Con V4 nos dimos cuenta de una nueva guía que será la guía estándar por def defec ecto to para real realiza izarr prue pruebas bas de Pe Penetra netració ciónn de Apl Aplica icacio ciones nes Web. -Matteo Meucci.

2

El Proyecto de Pruebas OWASP El proyecto de pruebas OWASP ha sido desarrollado durante muchos años. El objetivo del proyecto es ayudar a las personas a entender el qué, por qué, cuándo, dónde y cómo de la prueba de las aplicaciones web.

Redactar la Guía de Pruebas ha demostrado ser una tarea difícil. Fue un reto conseguir consenso y desarrollar contenidos que permitan aplicar los conceptos descritos en la guía, permitiendo a la vez que trabajen en su propio entorno y cultura. También fue un reto el cambiar el enfoque de las pruebas de pruebas de penetració penetraciónn a pruebas pruebas integradas integradas en el ciclo ciclo de vida de desarrollo desarrollo de las aplicaciones web.

Un principio básico de la ingeniería de software es que usted no puede controlar lo que no se puede medir [1]. Las pruebas de seguridad no son diferentes. Desafortunadamente, medir la seguridad es un proceso difícil. Este tema no se cubrirá en detalle aquí, ya que tendrá su guía propia (para una introducción, vea [2]).
















































































críticas que otros programas, ya que las aplicaciones web están expuestas a millones de usuarios a través de Internet.

¿Qué es probar? Durante el ciclo de vida de desarrollo de una aplicación web necesitan probarse muchas cosas, pero ¿qué significa realmente probar? El diccionario MerriamWebster describe como:

La mayoría de la gente, hoy en día, no prueba el software hasta que ya ha sido creado y está en la fase de despliegue de su ciclo de vida (es decir, el código ha sido creado y utilizado en una aplicación web activa). Esto suele ser una práctica muy ineficaz y con un costo prohibitivo. Uno de los mejores métodos para impedir que haya fallos de seguridad que aparecen en aplicaciones en producción es mejorar el Ciclo de Vida de Desarrollo de Software (SDLC), incluyendo seguridades en cada una de sus fases. Un SDLC es una estructura impuesta sobre el desarrollo de artefactos de software. Si un SDLC actualmente no está siendo utilizando en su entorno, ¡es hora de elegir uno! La siguiente figura muestra un modelo SDLC genérico, así como el costo creciente (estimado) de corrección de fallas de seguridad en este modelo.

• Poner a prueba o verificar. • Someterse a una prueba. • Asignar una posición o una evaluación basada en pruebas.

Para los efectos de este documento, probar es un proceso de comparar el estado de un sistema o una aplicación contra un conjunto de criterios. En la industria de seguridad, las personas, con frecuencia, prueban contra un conjunto de criterios mentales que no son bien definidos ni completos. Como resultado de esto, muchas personas personas ajenas consideran consideran las pruebas como un arte oscuro. El objetivo de este documento es cambiar esa percepción y hacerlo más fácil para que personas sin

Figura 1: Modelo SDLC genérico
















































































Un programa efectivo de pruebas debe tener componentes que prueban:

Principios de la prueba

Personas – para para asegurar que existe una educación adecuada y consciente;

para asegurar que hay criterios y políticas adecuadas y que las las Proceso – para

personas personas sepan cómo seguir seguir estas estas políticas; políticas; Tecnología – para garantizar que el proceso ha sido eficaz en su su implementación.

A menos que se adopte un enfoque integral, sólo probar la aplicación técnica de una aplicación no destapará la gestión o vulnerabilidades operacionales que podrían estar presentes. Probando a las personas, políticas y procesos, una organización puede encontrar encontrar temas temas que después después se se manifies manifiesten ten en defectos defectos en en la tecnologí tecnología, a, así como erradicar errores tempranamente e identificar la causa de los defectos. Además, sólo probando algunas de las cuestiones técnicas que pueden estar presentes presentes en un sistema sistema resultará resultará en una evaluación evaluación de seguridad seguridad incompleta incompleta e inexacta.

No hay una bala de plata Aunque es tentador pensar que un escáner de seguridad o cortafuegos para aplicaciones pueden proporcionar muchas defensas contra el ataque o identificar una serie de problemas, en realidad no hay ninguna bala de plata para el problema del software inseguro. El software de evaluación de seguridad, aunque es útil como un primer paso para encontrar el premio deseado, suele ser inmaduro e ineficaz en las evaluaciones a fondo o en brindar una prueba de cobertura adecuada. Recuerde que la seguridad es un proceso y no un producto.

Pensar estratégicamente, no tácticamente En los últimos años, los profesionales de la seguridad se han dado cuenta de la falacia del modelo de remendar y penetrar que fue dominante en la seguridad de la información durante la década de 1990. El modelo de remendar y penetrar implica corregir un error reportado, pero sin una investigación adecuada de la causa inicial. Este modelo se asocia generalmente a la ventana de vulnerabilidad que se muestra en la figura siguiente. La evolución de las vulnerabilidades en software común utilizado en todo el mundo ha demostrado la ineficacia de este modelo. Para obtener más información acerca de la ventana de la vulnerabilidad, consulte [6].



































































































































































Por ejemplo, si no sabe por dónde empezar, un marco prescriptivo puede proporcion proporcionar ar un menú de controles controles de seguridad seguridad potenciale potencialess que pueden pueden aplicarse aplicarse en el SDLC. El asesoramiento descriptivo puede entonces impulsar el proceso de decisión mediante la presentación de lo que ha funcionado bien para otras organizaciones. SDLC descriptivos seguros son BSIMM-V, y SDLC prescriptivos seguros incluyen el Software Abierto de Modelo de Garantía de Madurez de OWASP (OpenSAMM) y el ISO/IEC 27034, partes 1-8, segmentos del cual todavía están en desarrollo.

Prueba temprano y prueba continuamente Cuando un error se detecta tempranamente dentro del SDLC, puede abordarse más rápido y a menor costo. En este sentido, un fallo de seguridad no es diferente de un

herramientas automatizadas son realmente malas al realizar pruebas de vulnerabilidad automáticamente es que este pensamiento creativo debe hacerse caso por caso, ya que la mayoría de las aplicaciones web se desarrollan de una manera única (aun cuando usen marcos comunes).

Entender el tema Una de las primeras iniciativas importantes en cualquier buen programa de seguridad es solicitar documentación precisa sobre la aplicación. La arquitectura, diagramas de flujo de datos, casos de uso, etc., deberían ser escritos en do cumentos formales y disponibles para su revisión. Las especificaciones técnicas y documentos de la aplicación deben incluir información que muestre no sólo los casos deseados de uso, sino también cualquier caso de uso no permitido


















































































disponible, debería entregarse al personal de seguridad para ayudar a realizar su revisión. Es posible descubrir vulnerabilidades dentro de la fuente de la aplicación que pasaron desapercibidas con la prueba de la Caja Negra.

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

Utilizar una plantilla de informe de pruebas de seguridad puede ahorrar tiempo y asegurar que los resultados sean documentados con precisión y consistencia y estén en un formato adecuado para el grupo objetivo.

Explicación de las técnicas de prueba

Unas buenas métricas mostrarán: Esta sección presenta un resumen de alto nivel de diferentes técnicas de


















































































Como con muchas cosas en la vida, al realizar inspecciones manuales y revisiones, es recomendable adoptar un modelo de "confíe pero verifique". No todo lo que el evaluador muestre o diga será preciso.

Para desarrollar un modelo de amenazas, amenazas, se recomienda recomienda adoptar un enfoque simple que sigue el estándar NIST 800-30 [11] de evaluación del riesgo. Este enfoque implica:

Las revisiones manuales son particularmente buenas para probar si las personas e ntienden el pr oceso de seguri dad, han sido concientizadas conci entizadas sobre la política y tienen las habilidades apropiadas para diseñar o implementar una aplicación segura. Otras actividades, como revisar manualmente la documentación, políticas de codificación seguras, requisitos de seguridad y diseños arquitectónicos, deben ser cumplidas mediante una inspección manual.

• Descomposición de la aplicación - utilice un proceso de inspección manual para entender cómo funciona la aplicación, sus activos, funcionalidad y conectividad. • Definir y clasificar los activos – clasifique los activos en tangibles e intangibles y ordénelos según la importancia del negocio.


















































































Revisión de código fuente

• Requiere de desarrolladores expertos de seguridad.

Resumen

• Puede saltarse temas en bibliotecas compiladas.

La revisión del código fuente es el proceso de comprobar manualmente el código fuente de una aplicación web por cuestiones de seguridad. Muchas vulnerabilidades serias de seguridad no pueden ser detectadas mediante otra forma de análisis o pruebas. Como dice el dicho popular "Si usted quiere saber lo que realmente está pasando, vaya directamente a la fuente". Casi todos los expertos en seguridad están de acuerdo en

que no existe un sustituto para revisar el código. Toda la información para identificar problemas de seguridad existe en alguna parte del código. A

• No puede detectar fácilmente errores de tiempo de ejecución. • El código fuente desplegado puede diferir del que se analiza.

Para más información sobre revisión de código, investigue el proyecto de revisión de código OWASP.




















































































realmente se arreglan algunas vulnerabilidades específicas en el código desplegado en el sitio web.

desafíen todos los supuestos, tales como el no acceso a cceso al código fuente y el explorar la posibilidad de realizar pruebas pru ebas más completas.


















































































Muchas organizaciones han empezado a utilizar escáneres de aplicaciones web automatizados. Aunque sin duda tienen su lugar en un programa de pruebas, algunos temas fundamentales deben ser resaltados porque se cree que las pruebas

Mirando el código, la vulnerabilidad prácticamente salta de la página como un problema problema potenc potencial. ial.


















































































seguridad conducen efectivamente las pruebas de seguridad durante el SDLC y cómo se pueden utilizar los datos de pruebas de seguridad para gestionar eficazmente los riesgos de seguridad de software.

Otra sección de la lista de verificación debe cumplir con los requisitos generales para el cumplimie cumplimiento nto de las políticas políticas y normas normas de seguridad seguridad de información información de la organización. Desde la perspectiva de los requisitos r equisitos funcionales, los requisitos para


















































































posible derivar mejor los casos de pru eba de seguridad y aumentar el nivel de protección protección de los re quisitos de seguridad. Por ejemplo, ejemplo, distinguir las verdaderas vulnerabilidades de los no explotables es posible cuando se combinan los

una función hash para cifrar una contraseña, sin la aplicación de una semilla en el valor. Desde la perspectiva de codificación segura, se trata de una vulnerabilidad que afecta a la encriptación usada para la autenticación con una


















































































derivados de la explotación de las vulnerabilidades de autenticación, controles criptográficos, criptográficos, validación del ingreso y controles de validación.

• La plantilla de restablecimiento de contraseña contraseña debe validar el nombre de usuario y el email del del usuario registrado antes de enviar la contraseña temporal del usuario por correo electrónico. electrónico. La contraseñ contraseñaa temporal emitida debe ser
























































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































LOS ICONOS DE ABAJO REPRESENTAN QUE OTRAS VERSIONES ESTÁN DISPONIBLES EN IMPRESO PARA ESTE TÍTULO DE LIBRO. ALPHA: el contenido del libro "Calidad Alfa" es un borrador de trabajo. El contenido es muy áspero y en desarrollo hasta el nivel siguiente de la publicación. BETA: el contenido del libro "Calidad Beta" es el siguiente nivel más alto. El contenido está todavía en desarrollo hasta la próxima publicación. RELEASE: el contenido del libro "Calidad de Liberación" es el más alto nivel de calidad en un título del libro ciclo de vida, y es un producto final.

–





Indice 0 Página 6-8

Prologo por Eoin Keary

1 Página 9-12

Frontispicio Acerca de el proyecto de guia de pruebas OWASP Acerca de el Proyecto de Seguirdad de Aplicaciones WEB Abierta

2 Página 13-37

Introduction El proyecto de pruebas OWASP Principios de la prueba Explicación de las técnicas de prueba Derivar requerimientos de pruebas de seguirdad Las pruebas de seguridad integradas al desarrollo y flujos de trabajo de las pruebas de seguridad Análisis de datos de prueba de seguridad y reportes

3 Página 38-41

El marco referencial (framework) de pruebas de OWASP Resumen Fase1: Antes del inicio del desarrollo



Fase 2: Durante la definición y diseño Fase 3: Durante el desarrollo Fase 4: Durante la fase de implementación Fase 5: Mantenimiento y operaciones Flujo de trabajo del marco de pruebas de OWASP

4 Páginas 42-313

Pruebas de seguridad de aplicaciones WEB Introducción y objetivos Listado de validación de pruebas Recopilación de información Conducir motor de busqueda para el descubrimiento y reconocimiento de fugas de información (OTG-INFO-001) Huellas digitales servidor WEB (OTG-INFO-002) Revision de los meta archivos del servidor web en busca de fugas de información (OTG-INFO-003) Ennumere las aplicaciones en el servidor WEB (OTG-INFO-004) Revisión de los comentarios del sitio web y los metadatos en busca de fujas de información (OTG-INFO-005) Identificar puntos de entrada de la aplicación (OTG-INFO-006) Creación de mapas de rutas de ejecución a través de la aplicación (OTG-INFO-007) Marco referencial para el uso de huellas digitales en aplicaciones WEB (OTG-INFO-008) Huellas digitales aplicaciones WEB (OTG-INFO-009) Mapa de arquitectura de la aplicación (OTG-INFO-010)

Pruebas para gestionar la configuración y la implementación Prueba configuración Red/Infraestructura (OTG-CONFIG-001) Prueba de la configuración de la plataforma de aplicaciónes (OTG-CONFIG-002) Prueba manejo de archivos de extensiones en busca informaci ón sensible (OTG-CONFIG-003) Revisión archivos viejos, copias de seguridad y archivos no referenciados para Informaci ón sensible (OTG-CONFIG-004) Revisió Enumeracióón Infraestructura y de Interfaces de administració Enumeraci administraci ón de aplicaciones (OTG-CONFIG-005)



Prueba metodos HTTP (OTG-CONFIG-006) Prueba HTTP Strict Transport Security (OTG-CONFIG-007) Prueba polí política de dominio cruzado cruzado RIA (OTG-CONFIG-008)

Pruebas de Administración de Identidad Prueba de definició definici ón de roles (OTG-IDENT-001) Prueba proceso de registro de usuarios (OTG-IDENT-002) Prueba proceso de provisió provisi ón de cuentas (OTG-IDENT-003) Pruebas para ennumeraci ennumeracióón de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004) Pruebas politica de nombre de usuarios debiles o sin fuerza (OTG-IDENT-005)

Pruebas de autenticación Pruebas para credenciales transportadas sobre canales encriptados (OTG-AUTHN-001) Pruebas credenciales por defecto (OTG-AUTHN-002) Pruebas para mecanismos de seguridad dé d é biles (OTG-AUTH (OTG-AUTHN-003) N-003) Pruebas para eludir el esquema de autenticació autenticaci ón (OTG-AUTHN-004) Prueba funcionalidad recordatorio de clave (OTG-AUTHN-005) Prueba para debilidades en la memoria del navegador (OTG-AUTHN-006) Prueba para politica de clave dé d é bil (OTG-AUTHN-007 (OTG-AUTHN-007)) Prueba para seguirdad pregunta/respuest dé d é bil (OTG-AUTHN-008 (OTG-AUTHN-008)) Prueba para cambios de clave dé d é bil o funcionalidad funcionalidades es de reinio. reinio. (OTG-AUTHN-009 (OTG-AUTHN-009)) Prueba para autenticació autenticaci ón dé dé bil en canal canal alternativo alternativo (OTG-AUTHN-010) (OTG-AUTHN-010)

Pruebas de autorización Prueba de inclusió inclusi ón archivos de directorio de circulaci ón (OTG-AUTHZ-001) Prueba para evadir el esquema de autorizaci ón (OTG-AUTHZ-002) Prueba para escalació escalaci ón de privilegios (OTG-AUTHZ-003) Prueba de la referencia de objetos directos inseguros (OTG-AUTHZ-004)

Pruebas de administración e sesión Prueba para evadir el esquema de administraci ón de sesió sesión (OTG-SESS-001) Prueba para atributos de cookies (OTG-SESS-002)



Prueba de fijació fijaci ón de sesió sesión (OTG-SESS-003) Prueba de exposició exposici ón de variables de sesió sesi ón (OTG-SESS-004) Prueba para falsificació falsificaci ón de petició petici ón de sitio cruzado (CSRF) (OTG-SESS-005) Pruebas funcionalidad cierre de sesió sesi ón (OTG-SESS-006) Pruebas del tiempo cierre de sesió sesi ón (OTG-SESS-007) Prueba para sobrecarga de variables (Session puzzling) (OTG-SESS-008)

Pruebas de validación de entradas Pruebas para la reflexió reflexi ón de Cross Site scripting (OTG-INPVAL-001) Pruebas de Cross Site Scripting almacenados (OTG-INPVAL-002) Pruebas de manipulació manipulaci ón de verbos en HTTP (OTG-INPVAL-003) Pruebas de contaminació contaminaci ón de par ámetros HTTP (OTG-INPVAL-004) Pruebas de Inyecciones de SQL (OTG-INPVAL-005) Pruebas en Oracle Pruebas de MySQL Pruebas del servidor SQL (SQL Server) Probar la seguridad del proyecto proyecto de acceso restringido PostgresSQL de OWASP Pruebas para MS Access Pruebas de inyecció inyecci ón NoSQL Pruebas de inyecció inyecci ón LDAP (OTG-INPVAL-006) Pruebas de inyecció inyecci ón de ORM (OTG-INPVAL-007) Pruebas de inyecció inyecci ón de XML (OTG-INPVAL-008) Pruebas de inyecció inyecci ón SSI (OTG-INPVAL-009) Pruebas de inyecció inyecci ón XPath (OTG-INPVAL-010) Pruebas de inyecció inyecci ón de IMAP/SMTP (OTG-INPVAL-011) Pruebas de inyecció inyecci ón de có código (OTG-INPVAL-012) Pruebas para determinar la inclusió inclusi ón de documentos locales Pruebas para la inclusió inclusi ón remota de archivos Pruebas de inyecció inyecci ón de comandos (OTG-INPVAL-013)



Pruebe la saturació saturaci ón del Bú Búfer (OTG-INPVAL-014) Pruebas de saturació saturación de Heap Probar la saturació saturación de pila de datos Pruebas para la cadena de formato Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015) Pruebas para verificar la separació separaci ón/contrabando de HTTP (OTG-INPVAL-016)

Pruebas de manejo de errores Pruebas de errores de có código (OTG-ERR-001) Pruebas para determinar los rastors de pila de datos (OTG-ERR-002)

Pruebas para Critografía débil Pruebas de codificadores SSL/TLS dé d é biles, pritecci priteccióón de trasnporte de capas insuficiente (OTG-CRYPST-001) Prueba del Padding Oracle (REelleno de Oracle) (OTG-CRYPST-002) Pruebas para el enví envío de informació informaci ón sensible por canales sin encriptar (OTG-CRYPST-003)

Prueba de la lógica del negocio Pruebas de la validació validaci ón de datos de la ló l ógica del negocio (OTG-BUSLOGIC-001) Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC-002) Prueba de comprobació comprobaci ón de integridad (OTG-BUSLOGIC-003) Pruebas del tiempo de procesamiento (OTG-BUSLOGIC-004) Prueba del nú número de veces que limita el uso de una funci ón (OTG-BUSLOGIC-005) Pruebas para la evasió evasión de los flujos de trabajo (OTG-BUSLOGIC-006) Prueba de las defensas contra el mal uso de la aplicaci ón (OTG-BUSLOGIC-007) Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-BUSLOGIC-008) Prueba de la posibilidad de carga de archivos maliciosos (OTG-BUSLOGIC-009)

Pruebas en el lado del cliente Prueba del Cross Site Scripting basado en DOM (OTG-CLIENT-001) Prueba de la ejecució ejecuci ón de JavaScript (OTG-CLIENT-002) Prueba de inyecció inyecci ón de HTML (OTG-CLIENT-003) Pruebas de redireccionamiento de la URL del lado del cliente (OTG-CLIENT-004)



Pruebas de inyecció inyecci ón de CSS (OTG-CLIENT-005) Pruebas de la manipulació manipulaci ón de recursos del lado del cliente (OTG-CLIENT-006) Pruebas para el Intercambio de recursos de origen cruzado (OTG-CLIENT-007) Pruebas de Cross Site Flashing (OTG-CLIENT-008) Pruebas de Clickjacking (OTG-CLIENT-009) Pruebas de WebSockets (OTG-CLIENT-010) Prueba de mensajer ía web (Web Messaging) (OTG-CLIENT-011) Prueba de Almacenamiento Local (OTG-CLIENT-012)

5 Páginas 314-331

Apéndice Apéndice A: Herramientas de prueba Herramientas de Pruebas de Caja Negra de código abierto

Apéndice B: Lecturas sugeridas Libros Blancos Libros Páginas Web Útiles

Apéndice C: Vectores Fuzz Categorías Fuzz

Apéndice D: Inyección codificada Codificación de entrada Codificación de salida



Prólogo de la Guía de Pruebas

0

El problema del software no seguro es quizás el desafío técnico más importante de nuestro nuestro tiempo. El dramático dramático aumento de las aplicaciones web para negocios, redes sociales, etc. sólo ha



complicado los requerimientos para definir un enfoque robusto para esc escribi ribirr y aseg asegurar urar nue nuestra strass Aplic Aplicaci acion ones es Web Web e Inf Inform ormaci ación. ón.

Prólogo de Eoin Keary, Consejo Global OWASP El problema del software inseguro es quizás el desafío técnico más importante de nuestro tiempo. El aumento espectacular de las aplicaciones web que permiten generar ne gocios, redes sociales, etc. sólo ha agra vado los requisito s para establecer e stablecer u n enfoqu e robusto robu sto para escribir y asegurar nuestros I nternet, Aplicaciones Web y Datos.

En el Proyecto de Seguridad para Aplicaciones en Red Abierta (OWASP), estamos tratando de hacer del mundo un lugar donde el software inseguro sea la anomalía, no la norma. La Guía de Pruebas OWASP tiene un papel importante que desempeñar en la solución de este grave problema. Es de vital importancia que nuestro enfoque para pruebas de software por temas de seguridad se base en los principios de ingeniería y ciencia. Necesitamos un enfoque consistente, repetible y definido para las pruebas de aplicaciones web. Un mundo sin normas mínimas en materia de ingeniería y tecnología es un mundo caótico.

Es obvio que no se puede construir una aplicación segura sin realizar pruebas de seguridad en la misma. Las pruebas son parte de un enfoque más amplio en la construcción de un sistema seguro. Muchas organizaciones de desarrollo de software no incluyen pruebas como parte de su procedimiento estándar de desarrollo de software. Lo que es peor aún, muchos proveedores de seguridad entregan pruebas con diversos grados de calidad y rigor.

Las pruebas de seguridad, por sí mismas, no son una medida de seguridad particularmente confiable de lo segura que es una aplicación, a plicación, ya qu e hay un número infinito de formas en que un atacante podría ser capaz de romper la aplicación, y simplemente no es posible poner a prueba a todas ellas. No podemos nosotros mismos hackear seguridades y solo tenemos un tiempo limitado para probar y defender mientras que un atacante no tiene estas limitaciones.

En conjunto con otros proyectos de la OWASP como la Guía de Revisión de Códigos, la Guía de Desarrollo y Herramientas como OWASP ZAP, es un gran comienzo para la construcción y mantenimiento de aplicaciones seguras. La guía de desarrollo mostrará para su proyecto cómo diseñar y construir una aplicación segura, la Guía de Revisión de Códigos le dirá cómo verificar la seguridad del código de origen de su aplicación, y esta Guía de Pruebas le mostrará cómo verificar la seguridad de su aplicación en funcionamiento. Yo recomiendo utilizar estas guías como parte de sus iniciativas para la seguridad de su aplicación.

¿Por qué OWASP? Crear una guía como esta es una gran tarea que requiere de la experiencia de cientos de personas alrededor del mundo. Hay muchas maneras diferentes para detectar fallos de seguridad y esta guía captura el consenso de los principales exper tos sobre cómo r ealizar esta prueba con rapide z, exactitud y eficiencia.OWASP da a personas de seguridad con conocimientos afines la capacidad de trabajar conjuntamente y formar formar un enfoque de práctica práctica de liderazgo para un problema de seguridad.



La importancia de tener esta guía en forma totalmente libre y abierta es importante para la misión de las fundaciones. Da a cualquiera la capacidad de entender las técnicas usadas para detectar problemas de seguridad comunes. La seguridad no debe ser un arte oscuro o un secreto cerrado que sólo unos pocos pueden practicar. D ebe estar abi erta a todos y no n o ser exclusiva para los profesionales en seguridad, sino también para desarrolladores de control de calidad y gerentes técnicos. El proyecto para la construcción de esta guía mantiene la experiencia en manos de la gente que lo necesita; usted, yo y cualquier persona que participa en la construcción de software.

Esta guía debe abrirse paso hasta las manos de los desarrolladores y evaluadores de software. No hay suficientes expertos de seguridad de aplicaciones en el mundo para hacer una abolladura significativa en el problema general.

La responsabilidad inicial de seguridad de las aplicaciones debe recaer en los hombros de los desarrolladores; ellos escriben el código. No debería ser una sorpresa que los desarrolladores no están produciendo codificación segura si no la están probando o consideran los tipos de errores que generan la vulnerabilidad.

Mantener esta información actualizada es un aspecto crítico de este proyecto de guía. Adoptando el enfoque wiki, la comunidad OWASP puede evolucionar y ampliar la información en esta guía para mantener el ritmo con el panorama de la veloz amenaza de seguridad a las aplicaciones.

Esta guía es un gran testimonio de la pasión y energía que nuestros miembros y voluntarios del proyecto han dedicado a este tema. Sin duda ayudará a cambiar el mundo "una línea de código" a la vez.

Confeccionar y Priorizar Usted debería adoptar esta guía en su organización. Deberá adaptar la información para que coincida con la tecnología, procesos y estructura organizacional de su empresa.

• Los desarrolladores deben usar esta guía para asegurarse de que están produciendo códigos seguros. Estas pruebas deben ser parte de los procedimientos normale s de los códigos y de la unidad de pru ebas.

• Los evaluadores de software y control de calidad deben usar esta guía para ampliar el conjunto de casos de prueba que emplean en las aplicaciones. Atrapar estas vulnerabilidades tempranamente es un ahorro considerable de tiempo y esfuerzo más adelante.

• Los especialistas en seguridad deben usar esta guía en combinación con otras técnicas como una manera de verificar que no se haya escapado algún agujero de seguridad en la aplicación.

• Los gerentes de proyectos deben considerar la razón por la que esta guía existe y que las cuestiones de seguridad se manifiestan mediante errores de código y diseño.

Lo más importante cuando se realizan pruebas pruebas de seguridad es recordar que se deben priorizar continuamente. Hay un número infinito de posibilidades para que una aplicación apli cación pueda fallar, y las organizaciones orga nizaciones siempre han tenido tiempo y recursos limitados. Asegúrese de que el tiempo y los recursos se utilicen adecuadamente. Trate de concentrarse en los agujeros de seguridad que son un riesgo real para su negocio. Trate de contextualizar el riesgo en cuanto a la aplicación y sus usos. Esta guía se visualiza mejor como un conjunto de técnicas que puede utilizar para encontrar diferentes tipos de agujeros de seguridad. Pero no todas las técnicas son igual de importantes. Trate de evitar el uso de la guía como una lista de verificación. Nuevas vulnerabilidades siempre se manifestarán y ninguna guía puede ser una lista exhaustiva de "cosas por probar", sino más bien un gran lugar para c omenzar.

El papel de las herramientas automatizadas

Existe un número de empresas que venden análisis de seguridad automatizados y herramientas de prueba. Recuerde las limitaciones de estas herramientas para que pueda usarlas para lo que son buenas. Como Michael Howard dijo en la Conferencia del 2006 de OWASP AppSec en Seattle: "¡las herramientas no hacen al software seguro! Ayudan a elevar el proceso y a cumplir la política."

En general, hay varios roles diferentes que pueden usar esta guía dentro de las organizaciones: Lo más importante, estas herramientas son genéricas; lo que significa que no están diseñadas para un código personalizado, sino para aplicaciones en








































































GUIA DE PRUEBAS OWASP 4.0 ESPAÑOL.pdf

Recommend Documents