Guía de Pruebas OWASP V2

GUA DE PRUEBAS OWASP2007 V2.0

2002-2007 OWASP Foundation

This document is licensed under the Creative Commons Attribution-ShareAlike 2.5 license. You must attribute your version to the OWASP Testing or the OWASP Foundation.

http://creativecommons.org/licenses/by-sa/2.5/

Tabla de contenidos

Prlogo .............................................................................................................................................. 6

Porqu OWASP? ............................................................................................................................. 6

Escogiendo la estrategia y prioridades ........................................................................................... 7

El papel de las herramientas automatizadas .................................................................................. 7

Convocatoria ................................................................................................................................... 8

Notas de traduccin ............................................................................................................................ 9

Notas .............................................................................................................................................. 9

Glosario de trminos y desambiguacin ......................................................................................... 9

Agradecimientos ........................................................................................................................... 10

1. Portada ......................................................................................................................................... 11

Bienvenidos a la gua de pruebas OWASP 2.0 ............................................................................... 11

Acerca del proyecto abierto de Seguridad de Aplicaciones Web ................................................... 13

2. Introduccin .................................................................................................................................. 16

Principios de la comprobacin ....................................................................................................... 19

Tcnicas de comprobacin explicadas ........................................................................................... 23

3. El entorno de pruebas OWASP ...................................................................................................... 31

Presentacin ................................................................................................................................. 31

Fase 1: Antes de empezar el desarrollo ......................................................................................... 32

Fase 2 - Durante el diseo y definicin ......................................................................................... 32

fase 3: Durante el desarrollo ......................................................................................................... 34

Fase 4: Durante la implementacin ............................................................................................... 35

Fase 5: Mantenimiento y operaciones ........................................................................................... 36

Un flujo de comprobacin tpico en un SDLC ................................................................................. 37

4 Pruebas de intrusin de aplicaciones Web ..................................................................................... 38

4.1 Introduccin y objetivos .......................................................................................................... 38

4.2 Recopilacin de informacin ................................................................................................... 42

2 de 309

OWASP Testing Guide v2.0

4.2.1 Pruebas de firma digital de aplicaciones web ...................................................................... 45

4.2.2 Descubrimiento de aplicaciones .......................................................................................... 51

4.2.3 Tcnicas de Spidering y googling ......................................................................................... 59

4.2.4 Anlisis de cdigos de error ................................................................................................. 64

4.2.5 Pruebas de gestin de configuracin de la infraestructura .................................................. 67

4.2.5.1 Pruebas de SSL/TLS .......................................................................................................... 73

4.2.5.2 Pruebas del receptor de escucha de la BBDD ................................................................... 82

4.2.6 Pruebas de gestin de configuracin de la aplicacin .......................................................... 87

4.2.6.1 Gestin de extensiones de archivo ................................................................................... 93

4.2.6.2 Archivos antiguos, copias de seguridad y sin referencias ................................................. 95

4.3 Comprobacin de la lgica de negocio .................................................................................. 102

4.4 Comprobacin del sistema de autenticacin ......................................................................... 107

4.4.1 Cuentas de usuario por defecto o adivinables (diccionario) ............................................... 108

4.4.2 Fuerza bruta ....................................................................................................................... 111

4.4.3 Saltarse el sistema de autenticacin ................................................................................. 117

4.4.4 Atravesar directorios/acceder a archivos adjuntos externos .............................................. 122

4.4.5 Recordatorio de contraseas y pwd reset .......................................................................... 126

4.4.6 Pruebas de gestin del cach de navegacin y de salida de sesin ................................... 130

4.5 Pruebas de gestin de sesiones ............................................................................................ 135

4.5.1 Anlisis del esquema de gestin de sesiones ..................................................................... 136

4.5.2 Manipulacin de cookies y testigos de sesin .................................................................... 142

4.5.3 Variables de sesin expuestas ........................................................................................... 151

4.5.4 Pruebas de CSRF ................................................................................................................ 155

4.5.5 HTTP Exploit ....................................................................................................................... 161

4.6 Pruebas de validacin de datos ............................................................................................ 165

4.6.1 Cross Site Scripting ............................................................................................................ 168

4.6.1.1 Mtodos HTTP y XST ....................................................................................................... 173

4.6.2 Inyeccin SQL .................................................................................................................... 176

3 de 309

4.6.2.1 Pruebas de Oracle ........................................................................................................... 185

4.6.2.2 Pruebas de MySQL .......................................................................................................... 193

4.6.2.3 Pruebas de SQL Server .................................................................................................... 199

4.6.3 Inyeccin LDAP .................................................................................................................. 208

4.6.4 Inyeccin ORM ................................................................................................................... 211

4.6.5 Inyeccin XML .................................................................................................................... 212

4.6.6 InyecciN SSI ..................................................................................................................... 219

4.6.7 Inyeccin XPATH ................................................................................................................. 222

4.6.8 Inyeccin IMAP/SMTP ......................................................................................................... 224

4.6.9 Inyeccin de codigo ........................................................................................................... 230

4.6.10 Pruebas de inyeccin de comandos de sistema ............................................................... 231

4.6.11 Pruebas de desbordamiento de bfer .............................................................................. 234

4.6.11.1 Desbordamientos de memoria Heap ............................................................................. 234

4.6.11.2 Desbordamiento de pila ................................................................................................ 238

4.6.11.3 Cadenas de formato ...................................................................................................... 243

4.6.12 Pruebas de vulnerabilidad Incubada ................................................................................ 247

4.7 Pruebas de denegacin de servicio ....................................................................................... 250

4.7.1 Bloqueando cuentas de usuario ......................................................................................... 251

4.7.2 Desbordamientos de bfer ................................................................................................. 253

4.7.3 Reserva de objetos especificada por usuario ..................................................................... 254

4.7.4 Entradas de usuario como bucle ........................................................................................ 255

4.7.5 Escritura a disco de datos suministrados por usuario ........................................................ 257

4.7.6 Fallos en la liberacin de recursos ..................................................................................... 258

4.7.7 Almacenamiento excesivo en la sesin .............................................................................. 259

4.8 Comprobacin de servicios web ............................................................................................ 261

4.8.1 Pruebas estructurales de XML ............................................................................................ 261

4.8.2 Comprobacin de XML a nivel de contenido ..................................................................... 264

4.8.3 Comprobacin de parmetros HTTP GET/REST .................................................................. 266

4 de 309


4.8.4 Adjuntos SOAP maliciosos .................................................................................................. 267

4.8.5 Pruebas de repeticin ........................................................................................................ 270

4.9 Pruebas de AJAX .................................................................................................................... 272

4.9.1 Vulnerabilidades de AJAX ................................................................................................... 273

4.9.2 Como probar AJAX .............................................................................................................. 278

5. Redaccin de informes: Valorar el riesgo real ......................................................................... 284

5.1 Como valorar el riesgo real ................................................................................................... 284

5.2 Cmo escribir el informe de pruebas ................................................................................... 292

Apndice A: Herramientas de comprobacin ............................................................................. 299

Apndice B: Lectura recomendada ............................................................................................. 301

Apndice c: Vectores de fuzzing ................................................................................................. 303

5 de 309

PRLOGO

El problema del software inseguro es quizs el reto tcnico ms importante de nuestros tiempos. La seguridad es ahora el factor clave limitante sobre que podemos crear con la tecnologa de la informacin. En el OWASP, estamos intentando hacer del mundo un lugar en el que el software inseguro es la anomala, no la norma, y la Gua de Pruebas es una pieza importante del rompecabezas.

No puede dejar de remarcarse que no puedes construir una aplicacin segura sin realizar pruebas de seguridad en ella. Y aun as, muchas empresas de desarrollo de software no incluyen la comprobacin de seguridad como parte de su proceso estndar de desarrollo.

La comprobacin de seguridad, por si misma, no es una medida particularmente buena de cun segura es una aplicacin, porque existe un nmero infinito de modos en que un atacante podra ser capaz de colgar una aplicacin, y es simplemente imposible comprobarlas todos. Sin embargo, la comprobacin de seguridad tiene la cualidad nica de convencer a aquellos que continuamente niegan los hechos de que existe un problema. La comprobacin de seguridad ha demostrado ser un elemento clave para cualquier organizacin que necesita confiar en el software que produce o usa.

PORQU OWASP?

Crear una gua como representa un esfuerzo enorme, representando dcadas de trabajo realizado por cientos de personas por todo el mundo. Hay muchas formas diferentes de probar fallos de seguridad, y esta gua ana el consenso de los principales expertos sobre como realizar esta comprobacin rpida, exacta y eficientemente.

Es imposible subestimar la importancia de tener esta gua disponible de modo totalmente abierto y gratuito. La seguridad no debera ser magia negra que solo unos pocos pueden realizar. Gran parte de las guas de orientacin existentes son solo suficientemente detalladas para conseguir que la gente se preocupe por un problema, sin dar suficiente informacin para encontrar, diagnosticar y resolver problemas de seguridad. El proyecto de crear esta gua mantiene esta experiencia en manos de las personas que la necesitan.

Esta gua debe hacerse camino hasta manos de desarrolladores y revisores de software. No hay ni de lejos suficientes expertos en seguridad de aplicaciones en el mundo como para hacer un cambio significativo en el problema global. La responsabilidad inicial de la seguridad en las aplicaciones debe recaer sobre los hombros de los desarrolladores. No debera ser una sorpresa que los desarrolladores no produzcan cdigo seguro si no estn comprobndolo.

Mantener esta informacin actualizada es un aspecto crtico de este proyecto de gua. Adoptando el enfoque wiki, la comunidad OWASP puede evolucionar y expandir la informacin en esta gua para mantenerse al ritmo de los rpidos movimientos en amenazas de seguridad de las aplicaciones.

6 de 309


ESCOGIENDO LA ESTRATEGIA Y PRIORIDADES

Te recomendamos adoptar esta gua en tu organizacin. Puedes tener que adaptar la informacin contenida a las tecnologas, procesos y estructura organizacional de tu empresa. Si posees tecnologas estndar de seguridad, deberas adaptar tus comprobaciones para asegurarte de que estn siendo usadas apropiadamente. Existen diversos roles diferentes que pueden emplear esta gua.

Los desarrolladores deberan utilizar esta gua para asegurarse de que estn produciendo cdigo seguro. Estas pruebas deberan ser parte de los procedimientos normales de comprobacin de cdigo y mdulos.

Las personas que realizan pruebas de software deberan utilizar esta gua para expandir el conjunto de casos de comprobacin que aplican a los programas. Detectar estas vulnerabilidades en una fase temprana ahorra un tiempo y esfuerzo considerables a posteriori.

Los especialistas en seguridad deberan utilizar esta gua en combinacin con otras tcnicas, como un mtodo para verificar que no se ha dejado ningn agujero de seguridad en una aplicacin.

Cuando se realizan pruebas de seguridad, lo ms importante que debe recordarse es revisar continuamente las prioridades. Hay un nmero infinito de modos en que una aplicacin puede fallar, y t siempre cuentas con recursos y tiempo limitados, as que asegrate de que los gastas sabiamente. Trata de enfocarte en los agujeros de seguridad que son ms fciles de ser descubiertos y explotados por un atacante, y que conducen a los compromisos de seguridad ms serios.

Esta gua puede ser vista ms adecuadamente como un conjunto de tcnicas que puedes utilizar para encontrar diferentes tipos de agujeros de seguridad. Pero no todas las tcnicas son igual de importantes. Procura evitar utilizar esta gua como una lista de comprobacin.

EL PAPEL DE LAS HERRAMIENTAS AUTOMATIZADAS

Existen varias compaas que comercializan herramientas de anlisis y comprobacin de seguridad automatizadas. Recuerda las limitaciones de estas herramientas, de modo que puedas emplearlas para aquello en lo que son ms tiles. Como Michael Howard apunt en la Conferencia AppSec del Owasp de 2006 en Seattle, Las herramientas no hacen al software seguro! Ayudan a reducir el proceso y a imponer la poltica (de seguridad).

Lo ms importante a remarcar es que estas herramientas son genricas es decir, que no estn diseadas para tu cdigo especfico, sino para aplicaciones en general. Lo que significa que aunque pueden encontrar algunos problemas genricos, no tienen el conocimiento suficiente sobre tu aplicacin como para permitirles detectar la mayora de los fallos. Por mi experiencia, las incidencias de seguridad ms serias son aquellas que no son genricas, sino profundamente intrincadas en tu lgica de negocio y diseo a medida de la aplicacin.

7 de 309

Estas herramientas pueden tambin ser atractivas, ya que encuentran muchas incidencias potenciales. Aunque ejecutar estas herramientas no toma mucho tiempo, cada uno de los problemas potenciales toma su tiempo investigar y verificar. Si el objetivo es encontrar y eliminar los fallos ms serios tan rpidamente como sea posible, ten en consideracin si tu tiempo est mejor empleado usando herramientas automatizadas o con las tcnicas descritas en esta gua.

Con todo, estas herramientas son ciertamente parte de un programa de seguridad de aplicaciones bien equilibrado. Utilizadas sabiamente, pueden ofrecer soporte a tus procesos globales para producir cdigo ms seguro.

CONVOCATORIA

Si desarrollas software, te animo firmemente a familiarizarte con las orientaciones de comprobacin de seguridad de este documento. Si encuentras errores, por favor aade una nota a la pgina de discusin o realiza tu mismo el cambio. Estars ayudando a cientos de otras personas que usan esta gua. Por favor, considera unirte a nosotros como miembro individual o corporativo, de modo que podamos continuar produciendo materiales como esta gua y todos los otros grandes proyectos en OWASP. Gracias a todos los colaboradores, pasados y futuros, a esta gua, vuestro trabajo ayudar a hacer las aplicaciones de todo el mundo ms seguras.

-- Jeff Williams, OWASP Chair, 15 de Diciembre, 2006

8 de 309

http://www.owasp.org/index.php/User:Jeff_Williams


NOTAS DE TRADUCCIN

NOTAS

El proyecto de traduccin de la gua de pruebas OWASP v2 es una iniciativa del captulo espaol del proyecto OWASP. Puedes contactar con nosotros a travs de nuestra lista de correo.

A la hora de realizar la traduccin de esta gua, nos hemos enfrentado a una difcil eleccin: traducir o interpretar. La complejidad tcnica de algunas explicaciones hace muy difcil comprender un texto traducido literalmente, mientras que una interpretacin puede hacer perder detalles contenidos en el texto original. Nos hemos decidido por un enfoque mixto, intentando realizar una traduccin lo ms fiel posible a los objetivos de la gua, pero incluyendo notas con los trminos originales en ingls, para poder hacer ms sencillo buscar en otros documentos o por Internet los temas tratados en cada seccin. En los casos en que se sigue este esquema, se incluye, entre parntesis, una indicacin N. del T. (Nota del traductor).

GLOSARIO DE TRMINOS Y DESAMBIGUACIN

Los siguientes trminos en el documento original pueden tener varias acepciones, con diferentes matices segn el contexto. Se incluyen aqu las acepciones escogidas para la traduccin, con el resto de significados que puede tener:

Approach: trmino escogido para la traduccin: enfoque. Puede ser interpretado como aproximacin.

Tester: trmino escogido para la traduccin: persona que realiza las pruebas, o auditor. Puede ser interpretado como verificador, comprobador.

Token: trmino escogido para la traduccin: testigo. Puede ser interpretado como identificador, elemento.

Framework: trmino escogido para la traduccin: entorno de trabajo. En ocasiones se ha mantenido el trmino original, cuando forma parte del nombre de un producto (Ej: Java Framework). Puede ser interpretado como entorno de desarrollo, entorno de pruebas, marco de pruebas.

Overflow: trmino escogido para la traduccin: desbordamiento. Puede ser interpretado como sobrecarga.

Backend: se ha optado por no traducir el trmino. Puede ser interpretado como servicios internos, de infraestructura.

Middleware: se ha optado por no traducir el trmino. Puede ser definido como aquel software que funciona como intermediador entre diferentes tipos de software y hardware de modo que stos puedan trabajar en conjunto dentro de una red.

Site y Website: se ha optado por no traducir el trmino. Puede ser definido como el conjunto de servicios y archivos servidor por un servidor web dentro de una estructura jerrquica definida.

9 de 309

https://lists.owasp.org/mailman/listinfo/owasp-spain

AGRADECIMIENTOS

La traduccin de esta gua ha sido posible gracias al apoyo y contribucin de Pricewaterhouse Coopers Espaa, y al grupo de profesionales del proyecto hacktimes.com.

TRADUCTORES

Daniel Cabezas Molina

Alberto Corsn Lafuente

Juan de la Fuente Costa

Daniel P.F.

10 de 309


1. PORTADA

BIENVENIDOS A LA GUA DE PRUEBAS OWASP 2.0

Conocimiento colaborativo y abierto: ese es el estilo OWASP

Matteo Meucci

OWASP agradece a los muchos autores, revisores y editores involucrados por su duro trabajo en llevar a trmino esta gua hasta donde est hoy por hoy. Si tienes cualquier comentario o sugerencia sobre la Gua de Pruebas, por favor, enva un e-mail a la lista de correo de la Gua de Pruebas (en ingls):

http://lists.owasp.org/mailman/listinfo/owasp-testing

COPYRIGHT Y LICENCIA

Copyright (c) 2006 The OWASP Foundation.

Este documento ha sido publicado bajo la licencia Creative Commons 2.5 License. Por favor, consulta la licencia y condiciones de copyright.

REVISIN HISTRICA

La Gua de pruebas se origina en el 2003, con Dan Cuthbert como uno de los editores iniciales. En el 2005, Eoin Keary tom el relevo y la convirti en un wiki. Matteo Meucci ha decidido continuar la Gua de Pruebas y actualmente dirige el proyecto Gua de Pruebas OWASP "Otoo de Cdigo"(en ingls, AoC, Autumn of Code).

""Gua de pruebas OWASP"", Versin 2.0 25 de Diciembre, 2006

" Checklist de penetracin de aplicaciones OWASP ", Versin 1.1 14 de Julio, 2004

" Gua de pruebas OWASP ", Versin 1.0 - Diciembre 2004

EDITORES

Matteo Meucci: Responsable de la Gua de pruebas OWASP "Otoo de Cdigo" 2006.

Eoin Keary: Responsable de la Gua de pruebas OWASP 2005-2007.

11 de 309

http://creativecommons.org/licenses/by-sa/2.5/http://lists.owasp.org/mailman/listinfo/owasp-testinghttp://www.owasp.org/index.php/User:Mmeucci

AUTORES

Vicente Aguilera

Mauro Bregolin

Tom Brennan

Gary Burns

Luca Carettoni

Dan Cornell

Mark Curphey

Daniel Cuthbert

Sebastien Deleersnyder

Stephen DeVries

Stefano Di Paola

David Endler

Giorgio Fedon

Javier Fernndez-Sanguino

Glyn Geoghegan

Stan Guzik

Madhura Halasgikar

Eoin Keary

David Litchfield

Andrea Lombardini

Ralph M. Los

Claudio Merloni

Matteo Meucci

Marco Morana

Laura Nunez

Gunter Ollmann

Antonio Parata

Yiannis Pavlosoglou

Carlo Pelliccioni

Harinath Pudipeddi

Alberto Revelli

Mark Roxberry

Tom Ryan

Anush Shetty

Larry Shields

Dafydd Studdard

Andrew van der Stock

Ariel Waissbein

Jeff Williams

REVISORES

Vicente Aguilera

Marco Belotti

Mauro Bregolin

Marco Cova

Daniel Cuthbert

Paul Davies

Stefano Di Paola

Matteo G.P. Flora

Simona Forti

Darrell Groundy

Eoin Keary

James Kist

Katie McDowell

Marco Mella

Matteo Meucci

Syed Mohamed A

Antonio Parata

Alberto Revelli

Mark Roxberry

Dave Wichers

12 de 309


MARCAS

Java, Java Web Server y JSP son marcas registradas de Sun Microsystems, Inc.

Merriam-Webster es una marca registrada de Merriam-Webster, Inc.

Microsoft es una marca registrada de Microsoft Corporation.

Octave es una marca de servicios de la Carnegie Mellon University.

VeriSign y Thawte son marcas registradas de VeriSign, Inc.

Visa es una marca registrada de VISA USA.

OWASP es una marca registrada de la Fundacin OWASP.

PricewaterhouseCoopers es una marga registrada de PricewaterhouseCoopers International Limited.

Todos los otros nombres de producto y compaas pueden ser marcas registradas por sus respectivos propietarios. El uso de un trmino en este documento no debe ser tomado como implicacin que afecte a la validez de ninguna marca o marca de servicio.

ACERCA DEL PROYECTO ABIERTO DE SEGURIDAD DE APLICACIONES WEB

PRESENTACIN GENERAL

El Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP), es una comunidad abierta dedicada a permitir a las organizaciones realizar el desarrollo, adquisicin y mantenimiento de aplicaciones fiables. Todas las herramientas, documentos, foros y delegaciones del OWASP son libres y abiertas a cualquiera interesado en mejorar la seguridad de las aplicaciones. Abogamos por un enfoque de la seguridad en las aplicaciones como un problema tecnolgico, un proceso y que involucra a la gente, porque los enfoques ms efectivos a la seguridad de aplicaciones incluyen mejoras en todas estas reas. Nos puedes encontrar en http://www.owasp.org (en ingls).

El proyecto OWASP es un nuevo tipo de organizacin. Nuestra libertad frente a presiones comerciales nos permite proveer de informacin imparcial, prctica y ajustada en costes sobre la seguridad en aplicaciones. El OWASP no est afiliado a ninguna compaa tecnolgica, aunque damos soporte a la informacin de uso de tecnologa de seguridad comercial. De modo similar a muchos proyectos de cdigo abierto, el OWASP produce muchos tipos de material con un desarrollo colaborativo y abierto. La fundacin OWASP es una entidad sin nimo de lucro que asegura el mantenimiento del proyecto a largo plazo. Para ms informacin, por favor consulta en las pginas listadas a continuacin:

Contacto para informacin sobre como comunicar con OWASP

Contribuciones para detalles acerca de como realizar contribuciones

Advertising si ests interesado en anunciarte en el site del OWASP

Como funciona el OWASP para ms informacin sobre la estructura y proyectos

13 de 309

http://www.owasp.org/index.php/How_OWASP_Workshttp://www.owasp.org/index.php/Advertisinghttp://www.owasp.org/index.php/Contributionshttp://www.owasp.org/index.php/Contacthttp://www.owasp.org/

Reglas de uso de la marca OWASP para informacin sobre uso de la marca OWASP

ESTRUCTURA

La Fundacin OWASP es una entidad sin nimo de lucro (501c3) que provee la infraestructura para la comunidad OWASP. La Fundacin provee nuestros servidores y ancho de banda, facilita los proyectos y delegaciones, y gestiona las Conferencias de Seguridad en Aplicaciones en todo el mundo.

LICENCIAS

Todos los materiales de OWASP estn disponibles bajo una licencia de cdigo abierto aprobada. En caso de que pases a ser un miembro de la organizacin OWASP, tambin puedes hacer uso de la licencia comercial que te permite el uso, modificacin y distribucin de todos los materiales de OWASP en tu organizacin bajo una licencia de uso nica.

Para ms informacin, consulta la pgina Licencias OWASP.

PARTICIPACIN E INGRESO COMO MIEMBRO

Todo el mundo es bienvenido a participar en nuestros foros, proyectos, delegaciones y conferencias. OWASP es un lugar fantstico para aprender sobre seguridad en aplicaciones, para relacionarse, e incluso labrarse una reputacin como experto.

Si consideras los materiales del OWASP valiosos, por favor plantate ayudar al mantenimiento de nuestros fines convirtindote en un miembro de OWASP. Todo el dinero recibido por la Fundacin OWASP va directamente al sustento de los proyectos de OWASP.

Para ms informacin, consulta la pgina Comunidad.

PROYECTOS

Los proyectos del OWASP cubren muchos aspectos de la seguridad en aplicaciones. Desarrollamos documentos, herramientas, entornos de formacin, guas prcticas, listados de comprobacin, y otros materiales para ayudar a las organizaciones a mejorar su capacidad de producir cdigo seguro.

Para ms detalles sobre todo acerca de los proyectos del OWASP, consulta la pgina Proyectos OWASP Project.

14 de 309

http://www.owasp.org/index.php/Category:OWASP_Projecthttp://www.owasp.org/index.php/Category:OWASP_Projecthttp://www.owasp.org/index.php/Membershiphttp://www.owasp.org/index.php/OWASP_Licenseshttp://www.owasp.org/index.php/OWASP_brand_usage_rules


POLTICA DE PRIVACIDAD OWASP

Dada la misin del OWASP de ayudar a las organizaciones con la seguridad de las aplicaciones, tienes todo el derecho a esperar proteccin de cualquier informacin personal que podamos recopilar sobre nuestros miembros.

En general, no requerimos autentificacin o pedimos a los visitantes revelar informacin personal cuando visitan nuestro website. Recabamos las direcciones IP, no los e-mails, de los visitantes, con el propsito exclusivo de calcular varias estadsticas de web.

Podemos preguntar por alguna informacin personal, incluidos nombre y direccin de e-mail, de las personas que descargan productos del OWASP. Esta informacin no es revelada a ninguna tercera parte, y tan solo es empleada para los propsitos de:

Comunicar correcciones urgentes en Materiales del OWASP

Para pedir consejos y comentarios de mejora sobre Materiales del OWASP

Invitar a la participacin en procesos de consenso del OWASP y conferencias de Seguridad

El OWASP publica una lista de organizaciones miembro y miembros individuales. El listado es completamente voluntario y con la opcin de participar. Los miembros listados pueden pedir no aparecer en cualquier momento.

Toda la informacin sobre ti o tu organizacin que nos enves por fax o email es protegida fsicamente. Si tienes cualquier duda o pregunta acerca de nuestra poltica de seguridad, por favor contctanos a [email protected]

15 de 309

mailto:[email protected]

2. INTRODUCCIN

El Proyecto de Pruebas OWASP ha estado en desarrollo durante muchos aos. Queramos ayudar a la gente a entender el que, porque, cuando como probar sus aplicaciones web, y no tan solo proveer con un simple listado de comprobacin o una prescripcin de acciones especficas que deben ser atendidas. Queramos realizar un marco de desarrollo de pruebas a partir del cual otros pudiesen crear sus propios programas de test, o evaluar los procesos de otros. Escribir el Proyecto de Pruebas ha demostrado ser una tarea difcil. Ha sido todo un reto conseguir un cierto consenso y desarrollar el contenido apropiado, que permitiese a la gente aplicar el contenido y marco de trabajo global aqu descrito y a la vez tambin les permitiese trabajar dentro de su propio entorno y cultura. Tambin ha sido un reto el cambiar el enfoque de la realizacin de pruebas sobre aplicaciones web de tests de penetracin a las pruebas integradas en el ciclo de desarrollo del software. Muchos expertos en la industria y responsables de la seguridad del software en algunas de las mayores empresas del mundo dan validez al Marco de Pruebas, presentado como Partes 1 y 2 del Marco de Pruebas OWASP. Este marco de trabajo tiene por objetivo, ms que simplemente resaltar reas con carencias, ayudar a las organizaciones a comprobar sus aplicaciones web con el propsito de construir software fiable y seguro, aunque ciertamente lo primero se obtiene gracias a muchas de las guas y listados de comprobacin del OWASP. Debido a ello, hemos hecho algunas decisiones difciles sobre la conveniencia de algunas tecnologas y tcnicas de pruebas, que entendemos por completo que no seran aceptadas por todo el mundo. Sin embargo, el proyecto OWASP es capaz de colocarse en un plano superior de autoridad y cambiar la cultura de conocimiento existente, mediante la educacin y la concienciacin basadas en el consenso y la experiencia, preferentemente a tomar la va del mnimo comn denominador.

Datos econmicos del software inseguro El coste del software inseguro en la economa mundial es aparentemente inconmensurable. En Junio del 2002, el instituto de estndares Nacional Estadounidense (NIST) public un estudio sobre los costes del software inseguro para la economa estadounidense debidos a un testing inadecuado del software (The economic impacts of inadequate infrastructure for software testing. (2002, June 28). Retrieved May 4, 2004, from http://www.nist.gov/public_affairs/releases/n02-10.htm)

La mayora de la gente entiende al menos las implicaciones bsicas, o tiene un conocimiento tcnico ms profundo de las vulnerabilidades. Por desgracia, muy pocos son capaces de realizar una conversin de dicho conocimiento en un valor monetario, y de ese cuantificar los costes que acarrea a su negocio. Creemos que hasta que eso ocurra, los responsables informticos no podrn desarrollar un clculo preciso del retorno sobre una inversin en seguridad, y por tanto asignar los presupuestos adecuados para la seguridad del software. Consulta la pgina de Ross Anderson en http://www.cl.cam.ac.uk/users/rja14/econsec.html ara ms informacin acerca de las implicaciones econmicas de la seguridad.

16 de 309

http://www.cl.cam.ac.uk/users/rja14/econsec.htmlhttp://www.nist.gov/public_affairs/releases/n02-10.htm


El marco de trabajo descrito en este documento pretende alentar a las personas a evaluar y tomar una medida de la seguridad a travs de todo el proceso de desarrollo. As, pueden relacionar los costes de un software inseguro al impacto que tiene en su negocio, y de este modo gestionar decisiones de negocio apropiadas (recursos) para la gestin del riesgo. El software inseguro tiene de por si sus consecuencias, pero las aplicaciones web inseguras, expuestas a millones de usuarios a travs de Internet, representan una inquietud creciente. Incluso a da de hoy, la confianza de los clientes que usan la Web para realizar sus compras o cubrir sus necesidades de informacin est decreciendo, a medida que ms y ms aplicaciones web se ven expuestas a ataques.

Esta introduccin contempla los procesos involucrados en el testing de aplicaciones web:

El alcance de qu se debe probar

Principios del testing

Explicacin de las tcnicas de pruebas

Explicacin del marco de pruebas del OWASP

En la segunda parte de esta gua se cubre como comprobar cada fase del ciclo de vida del desarrollo del software, utilizando las tcnicas descritas en este documento. Por ejemplo, la segunda parte cubre como realizar pruebas de vulnerabilidades especficas, como inyeccin SQL mediante inspeccin de cdigo fuente y pruebas de intrusin.

Alcance de este documentoEste documento ha sido diseado para ayudar a las organizaciones a entender qu comprende la realizacin de un programa de pruebas, y ayudarlas a identificar los pasos necesarios a realizar para construir y operar dicho programa de pruebas sobre sus aplicaciones web. Se pretende suministrar una vista lo ms amplia posible de los elementos necesarios requeridos para realizar un programa de seguridad de aplicacin web exhaustivo. Esta gua puede ser usada como una referencia y como una metodologa para ayudar a determinar las brechas existentes entre tus prcticas existentes y las mejores prcticas de la industria. Esta gua permite a las organizaciones compararse con industrias a su mismo nivel, entender la magnitud de los recursos requeridos para comprobar y mejor su software, o prepararse ante una auditoria. Este documento no entra en detalles tcnicos de como probar una aplicacin, ya que su intencin es proveer de un marco de trabajo organizativo de seguridad tpico. Los detalles tcnicos de como probar una aplicacin, como parte de una prueba de intrusin o de revisin de cdigo, sern cubiertos en la segunda parte del documento mencionado ms arriba. A que nos referimos por comprobacin? Durante el ciclo de vida del desarrollo de una aplicacin web, muchas cosas han de ser probadas. El diccionario Merriam-Webster describe la accin de comprobar (en ingls, testing) como:

Poner a prueba o probar

Pasar una prueba

Ser asignado un estado o evaluacin basado en pruebas.

17 de 309

A efectos de este documento, la comprobacin o testing es un proceso de comparacin del estado de algo ante un conjunto de criterios. En la industria de la seguridad, a menudo se realizan pruebas contra un conjunto de criterios mentales que no estn ni bien definidos ni completos. Por esa y otras razones, muchas personas ajenas a esta industria consideran el testing de seguridad como un arte secreto y arcano. El objetivo de este documento es modificar esa percepcin, y hacer ms fcil a las personas sin un conocimiento en profundidad de seguridad cambiar las cosas.

El Ciclo de Vida del Proceso de Desarrollo del SoftwareUno de los mejores mtodos para prevenir la aparicin de bugs de seguridad en aplicaciones en produccin es mejorar el Ciclo de Vida de Desarrollo del Software (en ingls Software Development Life Cycle, o SDLC), incluyendo la seguridad. Si no hay un SDLC en uso en tu entorno actualmente, es el momento de escoger uno! La figura siguiente muestra un modelo SDLC genrico, as como los costes en incremento progresivo (estimados) de corregir bugs de seguridad en un modelo de este tipo.

Figura 1: Modelo SDLC genrico

Las compaas deberan inspeccionar su SDLC global para asegurarse que la seguridad es una parte integral del proceso de desarrollo. Los SDLC deberan incluir tests de seguridad para asegurar que la seguridad est adecuadamente cubierta, y los controles son efectivos a travs del proceso de desarrollo.

18 de 309


El Alcance: Qu debe ser probadoPuede ser de gran ayuda pensar en el desarrollo de software como en una combinacin de personas, procesos y tecnologa. Si esos son los factores que ``crean`` el software, es lgico que esos sean los factores que deben ser probados. Hoy en da la mayora de personas realizan pruebas a la tecnologa o el propio software. De hecho, la mayora no realiza pruebas al software hasta que ya ha sido creado y est en la fase de desarrollo de su ciclo de vida (es decir, que el cdigo ha sido creado e instanciado en una aplicacin web en uso). Generalmente, esta es una prctica muy ineficaz y prohibitiva en coste. Un programa de pruebas efectivo debera tener componentes que comprueban; Las Personas - para asegurarse de que hay la educacin y concienciacin adecuadas; Los Procesos - para asegurarse que hay las polticas y estndares adecuados, y que las personas saben como seguir dichas polticas; La Tecnologa - para asegurarse de que el proceso ha sido efectivo en su implementacin. A menos se adopte un aproximacin integral, probar tan solo la implementacin tcnica de una aplicacin no descubrir vulnerabilidades operacionales o de gestin que pudiesen estar presentes. Mediante la realizacin de pruebas sobre las personas, polticas y procesos, puedes llegar a prever incidencias o problemas que mas tarde se manifestasen en forma de defectos en la tecnologa, y as erradicar bugs de forma temprana e identificar las causas de los defectos. Del mismo modo que probar solamente algunas de las incidencias tcnicas que pueden estar presentes en un sistema resultar en un punto de vista incompleto e incorrecto de como realizar una evaluacin de seguridad. Denis Verdon, Responsable de Seguridad de la Informacin en Fidelity National Financial (http://www.fnf.com) present una excelente analoga para esta concepcin errnea en la Conferencia del OWASP AppSec 2004 en Nueva York. Si los coches fuesen construidos como aplicaciones...las pruebas de seguridad asumiran tan solo impactos frontales. A los coches no se les haran pruebas de rodaje, o seran probados en estabilidad en maniobras de emergencias, eficacia de los frenos, impactos laterales y resistencia a robos.

Informacin y ComentariosComo con todos los proyectos OWASP, damos la bienvenida a comentarios e informacin. Nos gusta especialmente tener constancia de que nuestro trabajo est siendo usado y si es preciso y efectivo.

PRINCIPIOS DE LA COMPROBACIN

Existen algunas concepciones equivocadas a la hora de desarrollar una metodologa de pruebas para corregir bugs de seguridad en el software. Este captulo cubre algunos de los principios bsicos que deberan ser tenidos en cuenta por los profesionales a la hora de realizar pruebas en busca de bugs de seguridad en software.

No existe la bala de plataAunque es tentador pensar que un scanner de seguridad o un cortafuegos de aplicacin nos proporcionar o una multitud de defensas o identificar una multitud de problemas, en realidad no existen balas de plata para el problema del software inseguro. El software de evaluacin de seguridad de aplicaciones, aunque til como un primer paso para encontrar la fruta al alcance de la mano, generalmente es inefectivo e inmaduro en evaluaciones en profundidad y a la hora de proporcionar una cobertura de pruebas adecuada. Recuerda que la seguridad es un proceso, no un producto.

19 de 309

http://www.fnf.com/

Piensa estratgicamente, no tcticamenteEn los ltimos aos, los profesionales de la seguridad han llegado a darse cuenta de la falacia que representa el modelo de parchear y penetrar, generalizado en seguridad de la informacin durante los 90. El modelo de parchear y penetrar comprende corregir un bug reportado, pero sin la investigacin adecuada de la causa origen. El modelo de parchear y penetrar se asocia a menudo con la ventana de vulnerabilidad (1) mostrada en la siguiente figura. La evolucin de vulnerabilidades en el software comn usado por todo el mundo ha demostrado la ineficacia de este modelo. Estudios de las vulnerabilidades (2) han mostrado que con el tiempo de reaccin de los atacantes por todo el mundo, la ventana de vulnerabilidad tpica no provee del tiempo suficiente para la instalacin de parches, ya que el tiempo entre que la vulnerabilidad es descubierta y un ataque automatizado es desarrollado y divulgado decrece cada ao. Existen tambin varias asunciones errneas en este modelo de parchear y penetrar: los parches interfieren con la operativa normal y pueden quebrantar aplicaciones existentes, y no todos los usuarios podran ser conscientes de la disponibilidad de un parche. Por lo tanto no todos los usuarios del producto aplicarn los parches, debido a la incidencia o por falta de conocimiento de la existencia del parche.

Figura 2: Ventana de exposicin

Nota: (1) Para ms informacin acerca de la ventana de vulnerabilidad, remitirse a la Entrega 9 del boletn Cryptogram de Bruce Schneier, disponible en http://www.schneier.com/crypto-gram-0009.html (2) Como pueden serlo los Informes de Amenazas de Symantec

Para prevenir problemas de seguridad recurrentes en una aplicacin, es esencial el construir la seguridad dentro del Ciclo de Vida de Desarrollo del Software (SDLC), desarrollando estndares, polticas y guas de uso que encajen y funcionen dentro de la metodologa de desarrollo. El modelado de amenazas y otras tcnicas deberan ser empleados para ayudar a asignar los recursos apropiados en aquellas partes de un sistema ms expuestas al riesgo.

SDLC es el reyEl SDLC es un proceso bien conocido por los desarrolladores. Mediante la integracin de la

20 de 309

http://www.schneier.com/crypto-gram-0009.html


seguridad en cada fase del SDLC, permite una aproximacin integral a la seguridad de aplicaciones que se apoya en los procedimientos ya existentes en la organizacin. Ten en cuenta que mientras los nombres de las varias fases pueden cambiar dependiendo del modelo SDLC usado por una organizacin, cada fase conceptual del arquetipo SDLC ser usada para desarrollar la aplicacin (es decir, definir, disear, desarrollar, implementar, mantener). Cada fase tiene implicaciones de seguridad que debern formar parte del proceso existente, para asegurar un programa de seguridad rentable y exhaustivo.

Prueba pronto y prueba a menudoEl detectar un bug en una etapa temprana dentro del SDLC permite que pueda ser abordado con mayor rapidez y a un coste menor. Un bug de seguridad no es diferente de uno funcional o de un bug en el rendimiento, en este contexto. Un factor clave en hacer esto posible es educar a las organizaciones de desarrollo y Calidad sobre problemas de seguridad comunes y los mtodos para detectar y prevenirlos. A pesar de que las nuevas bibliotecas, herramientas o lenguajes pueden ayudar a disear mejores programas (con menos bugs de seguridad), nuevas amenazas estn apareciendo constantemente y los desarrolladores deben ser conscientes de aquellas que afectan al software que estn desarrollando. La educacin en testing de seguridad ayuda tambin a los desarrolladores a adquirir el enfoque apropiado para probar una aplicacin desde la perspectiva de un atacante. Esto permite a cada organizacin considerar los problemas de seguridad como una parte de de sus responsabilidades.

Comprende el alcance de la seguridadEs importante saber cuanta seguridad requerir un proyecto determinado. A la informacin y activos que van a ser protegidos les debera ser asignada una clasificacin que indique como van a ser manejados (por ejemplo confidencial, secreto, alto secreto). Debera discutirse con un consejo legal para asegurarse de que se cumplir cualquier necesidad de seguridad especfica. En los EEUU dichas necesidades pueden provenir de regulaciones federales como el acta Gramm-Leach-Bliley (http://www.ftc.gov/privacy/glbact/), o de leyes estatales como la SB-1386 de California (http://www.leginfo.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html). Para organizaciones radicadas en pases de la UE, tanto la regulacin especfica del pas como las directivas europeas pueden aplicar, por ejemplo la Directiva 96/46/EC4 hace obligatorio el tratamiento de datos personales en aplicaciones con la debida atencin, sea cual sea la aplicacin.

EnfoqueProbar con xito una aplicacin en busca de vulnerabilidades de seguridad requiere pensar fuera de lo convencional . Los casos de uso habituales realizarn una comprobacin del comportamiento normal de la aplicacin cuando un usuario est emplendola del modo que esperas. Una buena comprobacin de seguridad requiere ir ms all de lo que se espera y pensar como un atacante que est intentando quebrantar la aplicacin. Pensar creativamente puede ayudar a determinar que datos no esperados pueden causar que una aplicacin falle de modo inseguro. Tambin puede ayudar encontrar que supuestos realizados por los desarrolladores web no son siempre ciertos y como pueden ser explotados. Esta es una de las razones por las que las herramientas automatizadas son realmente malas en la prueba automtica de vulnerabilidades, esta mentalidad creativa debe ser usada caso por caso, y la mayora de las aplicaciones web son desarrolladas de forma nica y singular (incluso aunque usen marcos de desarrollo comunes).

Comprende el objeto de estudioUna de las primeras iniciativas principales en cualquier buen programa de seguridad debera ser

21 de 309

http://www.leginfo.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.htmlhttp://www.leginfo.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.htmlhttp://www.ftc.gov/privacy/glbact/

pedir documentacin precisa de la aplicacin. La arquitectura, diagramas de flujo de datos, casos de uso, y dems deberan ser escritos en documentos formales y puestos a disposicin para revisin. La documentos de aplicacin y especificacin tcnica deberan incluir informacin que liste no solo los casos de uso deseados, sino tambin cualquier caso de uso especficamente no admitido. Finalmente, es bueno tener como mnimo una infraestructura de seguridad bsica que permita la monitorizacin y el anlisis de la evolucin de los ataques contra tus aplicaciones y red (por ejemplo, sistemas IDS).

Utiliza las herramientas adecuadasAunque ya hemos enunciado que no existe una herramienta bala de plata, las herramientas juegan un papel crtico en el programa de seguridad global. Hay toda una gama de herramientas de cdigo abierto y comerciales que pueden ayudar en la automatizacin de muchas tareas de seguridad rutinarias. Estas herramientas pueden simplificar y acelerar el proceso de seguridad ayudando al personal de seguridad en sus tareas. Sin embargo, es importante comprender exactamente lo que estas herramientas pueden hacer y lo que no, de forma que no se exagere su uso o sean usadas incorrectamente.

Lo importante est en los detallesEs un factor crtico no realizar una revisin de seguridad superficial de una aplicacin y considerarla completa. Esto infundir una falsa sensacin de confianza que puede ser tan peligrosa como no haber hecho una revisin de seguridad. Es vital revisar cuidadosamente los resultados encontrados y cribar cualquier falso positivo que pueda quedar en el informe. Informar de un resultado de seguridad hallado que sea incorrecto puede desacreditar el resto de mensajes vlidos de un informe de seguridad. Debe tomarse cuidado en verificar que casa posible seccin de la lgica de aplicacin ha sido probada, y que cada escenario de caso de uso ha sido explorado en busca de posibles vulnerabilidades.

Usa el cdigo fuente cuando est disponibleA pesar de los resultados de los tests de penetracin de caja negra pueden ser impresionantes y tiles para demostrar como son expuestas las vulnerabilidades en produccin, no son el mtodo ms efectivo para securizar una aplicacin. Si el cdigo fuente de la aplicacin est disponible, debera ser entregado al personal de seguridad para ayudarles durante la realizacin de la revisin. Es posible descubrir vulnerabilidades dentro del cdigo fuente de la aplicacin que se perderan durante el trabajo de caja negra.

22 de 309


Desarrolla mtricasUna parte importante de un buen programa de seguridad es la habilidad para determinar si las cosas estn mejorando. Es importante seguir la pista de los resultados de los trabajos de prueba, y desarrollar mtricas que podrn revelar la evolucin de la seguridad de la aplicacin en la organizacin. Estas mtricas pueden mostrar si son necesarias ms educacin y formacin, si hay algn mecanismo de seguridad en particular que no es comprendido con claridad por desarrollo, y si el nmero total de problemas relacionados con seguridad que se han encontrado cada mes se est reduciendo. Unas mtricas consistentes que puedan ser generadas automticamente a partir de cdigo fuente disponible ayudarn tambin a la organizacin en la evaluacin de la eficacia de los mecanismos introducidos para reducir el nmero de bugs de seguridad en el desarrollo de software. Las mtricas no son fciles de desarrollar, por lo que usar mtricas estndar, como las provistas por el proyecto OWASP Metrics y otras organizaciones podra ser una buena base de la que partir para empezar.

TCNICAS DE COMPROBACIN EXPLICADAS

Esta seccin presenta una visin genrica de alto nivel de las diversas tcnicas de testing que pueden ser empleadas en la construccin de un programa de pruebas. No se presentan metodologas especficas para estas tcnicas, aunque la Parte 2 del proyecto de Pruebas OWASP si abordar esa informacin. Incluimos esta seccin para situar en contexto el marco de pruebas presentado en el siguiente Captulo, y para remarcar las ventajas y desventajas de algunas de las tcnicas que pueden ser consideradas.

Inspecciones y Revisiones Manuales

Modelado de Amenazas

Revisin de Cdigo

Pruebas de Penetracin

INSPECCIONES Y REVISIONES MANUALES

Las inspecciones manuales son revisiones realizadas por personas, que por lo general comprueban las implicaciones de seguridad de personas, polticas y procesos, aunque pueden incluir la inspeccin de decisiones tecnolgicas, como puede ser los diseos de la arquitectura escogidos. Generalmente se llevan a cabo analizando documentacin o mediante entrevistas con los diseadores o propietarios de los sistemas. Aunque el concepto de inspeccin manual y revisin personal es simple, pueden considerarse entre las tcnicas ms efectivas y eficaces. Preguntar a alguien como funciona algo y porque est implementado de un modo especfico permite al revisor determinar rpidamente si una consideracin de seguridad puede resaltar de forma evidente. Las inspecciones y revisiones manuales son una de las pocos mtodos para probar el ciclo de vida de desarrollo de software y asegurar que en el mismo existe la poltica de seguridad o competencia adecuada. Como con muchas otras cosas en la vida, a la hora de realizar inspecciones y revisiones manuales, te sugerimos que adoptes un modelo de confa, pero verifica.

23 de 309

No todo lo que todo el mundo te dice o te muestre ser preciso o correcto. Las revisiones manuales son particularmente buenas para comprobar si las personas comprenden el proceso de seguridad, si han sido concienciadas de la existencia de una poltica, y si tienen los conocimientos apropiados para disear y/o implementar una aplicacin segura. Otras actividades, incluyendo la revisin manual de documentacin, polticas de programacin segura, requerimientos de seguridad y diseos estructurales, deberan ser efectuadas usando revisiones manuales.

Ventajas:

No requiere tecnologa de apoyo

Puede ser aplicada a una variedad de situaciones

Flexible

Fomenta el trabajo en grupo

Se aplica en una fase temprana del SDLC

Desventajas:

Puede consumir mucho tiempo

Material de apoyo no siempre disponible

Precisa de bastantes conocimientos, reflexin y competencia humana para ser efectiva

MODELADO DE AMENAZAS

Informacin General

En el contexto del mbito tcnico, el modelado de amenazas se ha convertido en una tcnica popular para ayudar a los diseadores de sistemas acerca de las amenazas de seguridad a las que se enfrentan sus sistemas. Les permite desarrollar estrategias de mitigacin para vulnerabilidades potenciales. El modelado de amenazas ayuda a las personas a concentrar sus, inevitablemente, limitados recursos y atencin en aquellas partes del sistema que ms lo necesitan. Los modelos de amenaza deberan ser creados tan pronto como sea posible en el ciclo de vida de desarrollo del software, y deberan ser revisados a medida que la aplicacin evoluciona y el desarrollo va progresando. El modelado de amenazas es esencialmente la evaluacin del riesgo en aplicaciones. Se recomienda que todas las aplicaciones tengan un modelo de amenaza desarrollado y documentado. Para desarrollar un modelo de amenaza, recomendamos tomar una aproximacin simple que siga el estndar NIST 800-30 para evaluacin del riesgo. Esta aproximacin incluye:

Descomponer la aplicacin - a travs de un proceso de inspeccin manual, comprendiendo como funciona la aplicacin, sus activos, funcionalidad y conectividad.

Definir y clasificar los activos - clasificar los activos en activos tangibles e intangibles, y ponderarlos de acuerdo a su criticidad para el negocio.

Explorar vulnerabilidades potenciales (tcnicas, operacionales y de gestin)

24 de 309


Explorar amenazas potenciales - a travs de un proceso de desarrollo de escenarios de amenaza o rboles de ataque que desarrollan una visin realista de potenciales vectores de ataque desde la perspectiva del atacante.

Crear estrategias de mitigacin desarrollar controles de mitigacin para cada una de las amenazas que se consideran realistas. El resultado de un modelo de amenaza puede variar, pero generalmente es un coleccin de listas y diagramas. La Parte 2 de la Gua de Pruebas OWASP (el texto detallado de Como) apuntar una metodologa especfica de Modelado de Amenazas. No hay un modo correcto o incorrecto de desarrollar modelos de amenaza, y han ido surgiendo diversas tcnicas. Vale la pena echar un vistazo al modelo OCTAVE de la universidad Carnegie Mellon (http://www.cert.org/octave/).

Ventajas

Visin prctica del sistema desde el punto de vista de un atacante

Flexible

Se aplica en una fase temprana del SDLC

Desventajas

Nueva tcnica, relativamente

Unos buenos modelos de amenaza no significan un buen software

Nota: (3) Stoneburner, G., Goguen, A., & Feringa, A. (2001, October). Risk management guide for information technology systems. Obtenido el 7 de Mayo de 2004 de http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

REVISIN DE CDIGO FUENTE

Presentacin generalLa revisin de cdigo fuente es el proceso de comprobar manualmente el cdigo fuente de una aplicacin web en busca de incidencias de seguridad. Muchas vulnerabilidades de seguridad serias no pueden ser detectadas con ninguna otra forma de anlisis o prueba. Como dice la conocida frase ``si quieres saber que es lo que est pasando realmente, vete directo a la fuente. Casi todos los expertos en seguridad estn de acuerdo en que no hay nada mejor que ver realmente el cdigo. Toda la informacin necesaria para identificar problemas de seguridad est en el cdigo en algn lugar. De modo diferente a comprobar software cerrado de terceras partes, como sistemas operativos, cuando se realizan tests de aplicaciones web (especialmente cuando han sido desarrolladas internamente), el cdigo fuente debera ser puesto a disposicin para comprobarlo. Muchos problemas de seguridad no intencionados pero significativos son tambin extremadamente difciles de descubrir con otras formas de testing o anlisis, como el testing de penetracin, haciendo del anlisis de cdigo la tcnica preferida para las comprobaciones tcnicas. Con el cdigo fuente, la persona comprobndolo puede determinar con exactitud que est pasando (o qu se supone que est pasando), y eliminar el trabajo de adivinar del testing de caja negra.

Ejemplos de incidencias particularmente propicias a ser encontradas a travs de las revisiones de cdigo fuente incluyen problemas de concurrencia, lgica de negocio errnea, problemas de control de acceso y debilidades criptogrficas, as como puertas traseras, Troyanos, Huevos de Pascua,

25 de 309

http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdfhttp://www.cert.org/octave/

bombas de tiempo, bombas lgicas y otras formas de cdigo malicioso. Estas incidencias a menudo se manifiestan como las vulnerabilidades ms dainas en websites. El anlisis de cdigo fuente puede ser tambin extremadamente eficiente a la hora de encontrar incidencias de implementacin, como localizaciones en las que la validacin de entradas no es realizada o cuando pueda haber presentes procedimientos errneos de control de fallos. Pero ten en cuenta que los procedimientos operativos deben ser revisados tambin, ya que el cdigo fuente usado puede no ser el mismo que el analizado.(4).

Ventajas

Eficacia e integridad

Precisin

Rapidez (Para revisores competentes)

Desventajas

Requiere desarrolladores de seguridad altamente competentes

No puede detectar errores en tiempo de ejecucin con facilidad

El cdigo fuente realmente en uso puede ser diferente del que est siendo analizado

Para ms informacin acerca de la revisin de cdigo, OWASP gestiona un proyecto de revisin de cdigo: http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

Nota: (4) Ver "Reflections on Trusting Trust" por Ken Thompson (http://cm.bell-labs.com/who/ken/trust.html)

26 de 309

http://cm.bell-labs.com/who/ken/trust.htmlhttp://cm.bell-labs.com/who/ken/trust.htmlhttp://www.owasp.org/index.php/Category:OWASP_Code_Review_Project


PRUEBAS DE INTRUSIN

Informacin GeneralLos tests de intrusin se han convertido desde hace muchos aos en una tcnica comn empleada para comprobar la seguridad de una red. Tambin son conocidos comnmente como tests de caja negra o hacking tico. Las pruebas de intrusin son esencialmente el ``arte de comprobar una aplicacin en ejecucin remota, sin saber el funcionamiento interno de la aplicacin, para encontrar vulnerabilidades de seguridad. Generalmente, el equipo de prueba de intrusin tendra acceso a una aplicacin como si fuesen usuarios. Los probadores actan como un atacante, e intentan encontrar y explotar vulnerabilidades. En muchos casos al encargado de las pruebas se le da una cuenta vlida en el sistema. Mientras que los tests de penetracin han demostrado ser efectivos en seguridad de redes, la tcnica no se traslada de forma natural al caso de aplicaciones. Cuando se realizan tests de penetracin en redes y sistemas operativos, la mayora del trabajo se centra en encontrar y explotar vulnerabilidades conocidas en tecnologas especficas. Dado que las aplicaciones web son casi todas hechas a medida exclusivamente, el testing de penetracin en el campo de aplicaciones web es ms similar a investigacin pura. Se han desarrollado herramientas de testing de penetracin para automatizar el proceso pero, de nuevo, por la naturaleza de las aplicaciones web, su eficacia es a menudo escasa. Actualmente muchas personas emplean tests de penetracin sobre aplicaciones web como su tcnica de comprobacin de seguridad principal. Aunque ciertamente tiene su lugar en un programa de pruebas, no creemos que deba ser considerado como la principal o nica tcnica. Gary McGraw resumi bien el testing de penetracin cuando dijo ``Si suspendes una prueba de intrusin sabes que, de hecho, tienes un problema muy grave. Si pasas una prueba de intrusin no sabes si no tienes un problema muy grave. Sin embargo una prueba de intrusin enfocado (esto es, un test que intenta explotar vulnerabilidades conocidas detectadas en revisiones anteriores) puede ser de utilidad para detectar si alguna vulnerabilidad especfica est realmente corregida en el cdigo fuente desplegado en la web..

Ventajas

Puede ser rpido (y por tanto, barato)

Requiere un conocimiento relativamente menor que una revisin de cdigo fuente

Comprueba el cdigo que est siendo expuesto realmente

Desventajas

Demasiado tardo en el SDLC

Testing solo de impactos frontales

27 de 309

LA NECESIDAD DE UNA APROXIMACIN EQUILIBRADA

Con tantas tcnicas y aproximaciones para comprobar la seguridad de tus aplicaciones web, puede resultar difcil comprender que tcnicas usar y cuando usarlas. La experiencia muestra que no hay una respuesta correcta o incorrecta a cuales seran exactamente las tcnicas que deberan usarse para construir un marco de pruebas. El hecho es que probablemente todas las tcnicas deberan ser empleadas para asegurar que todas las reas que necesitan ser probadas son cubiertas. Sin embargo, lo que est claro, es que no hay una sola tcnica que cubra eficazmente toda la comprobacin de seguridad que debe ser realizada para asegurar que todas las incidencias son abordadas. Muchas compaas adoptan una aproximacin, que histricamente ha sido el testing de penetracin. El testing de penetracin, a pesar de su utilidad, no puede abordar efectivamente muchas de las incidencias que requieren ser comprobadas, y simplemente es insuficiente y demasiado tarde dentro del ciclo de desarrollo del software (SDLC). La aproximacin correcta es una aproximacin equilibrada que incluya varias tcnicas, desde las revisiones manuales hasta el testing tcnico. Una aproximacin equilibrada asegura la cobertura de pruebas en todas las fases del SDLC. Esta aproximacin explota el potencial las tcnicas ms apropiadas disponibles dependiendo de la fase actual del SDLC. Por supuesto hay momentos en que solo una tcnica es aplicable; por ejemplo, un test en una aplicacin web que ya ha sido creada y en el que el probador no tiene acceso al cdigo fuente. En este caso, un test de penetracin es claramente mejor que no probar nada. Sin embargo, nosotros recomendamos a los responsables de realizar las pruebas poner a prueba cualquier asuncin, como el no tener acceso al cdigo fuente, y explorar la posibilidad de un testing completo. Una aproximacin equilibrada vara dependiendo de muchos factores, como la madurez del proceso de pruebas y la cultura corporativa. Sin embargo, se recomienda que un marco de pruebas equilibrado sea semejante a las representaciones mostradas en las Figuras 3 y 4. La siguiente figura muestra una representacin tpica proporcional superpuesta sobre el ciclo de vida de desarrollo del software. Es esencial para las compaas poner un mayor nfasis en las etapas iniciales de desarrollo.

Figure 3: Proporcin del esfuerzo de pruebas en el SDLC

La siguiente figura muestra una representacin proporcional tpica superpuesta sobre las tcnicas de comprobacin

28 de 309


Figura 4: Proporcin del esfuerzo de la prueba segn la tcnica empleada

Nota sobre los scanners de aplicaciones web

Muchas organizaciones han empezado a utilizar scanners de aplicaciones web. Aunque sin duda tienen su lugar en un programa de pruebas, queremos remarcar algunas razones fundamentales por las que creemos que el testing automtico de caja negra no es (ni ser) efectivo. Por el hecho de resaltar estos puntos no estamos desaconsejando el uso de scanners de aplicacin. Lo que queremos decir es que sus limitaciones deberan ser comprendidas, y los marcos de prueba deberan ser planeados apropiadamente.

Ejemplo 1: Parmetros mgicosImagina una aplicacin web simple que acepta una combinacin nombre-valor, primero el parmetro ``mgico y luego el valor. Por simplicidad, la peticin GET podra ser: http://www.host/application?magic=valor Para simplificar ms el ejemplo, en este caso los valores solo pueden ser caracteres ASCII de la ``a a la ``z (maysculas o minsculas), y nmeros del 0 al 9. Los diseadores de esta aplicacin crearon una puerta trasera administrativa durante las pruebas, pero la ofuscaron para evitar que un observador casual la descubriese. Enviando el valor sf8g7sfjdsurtsdieerwqredsgnfg8d (30 caracteres), el usuario se loguear y se le presentar una pantalla administrativa con control total de la aplicacin. La peticin HTTP sera:http://www.host/application?magic= sf8g7sfjdsurtsdieerwqredsgnfg8d Dado que todos los otros parmetros eran campos simples de dos y tres caracteres, no es posible empezar a adivinar combinaciones a partir de 28 caracteres. Un scanner de aplicacin web necesitar realizar fuerza bruta (o adivinar) el espacio de claves completo de 30 caracteres. Esto suma 3028 permutaciones, o !trillones de peticiones HTTP! Es como buscar un electrn en un pajar digital! El cdigo podra ser como el siguiente:

29 de 309

publicvoiddoPost(HttpServletRequestrequest,HttpServletResponseresponse){Stringmagic=sf8g7sfjdsurtsdieerwqredsgnfg8d;booleanadmin=magic.equals(request.getParameter(magic));if(admin)doAdmin(request,response);else.//procesonormal}

Mediante un vistazo al cdigo fuente, la vulnerabilidad prcticamente salta a la vista como un problema potencial.

Ejemplo 2: Mala criptografaLa criptografa es usada ampliamente en aplicaciones web. Imagina que un desarrollador decide escribir un algoritmo de cifrado simple para permitir a un usuario registrarse automticamente del site A al site B. El desarrollador decide, desde su conocimiento, que si un usuario est logueado en el site A, puede generar una clave usando una funcin de hashing MD5 que comprenda Hash { usuario:fecha } Cuando un usuario pasa al site B, enviar la clave en la cadena de peticin al site B en un redirect HTTP. El site B calcula independientemente el hash, y lo compara al hash que se le ha pasado en la peticin. Si coinciden, el site B registra al usuario como el usuario que dice ser. Claramente, tal y como explicamos el sistema, se pueden vislumbrar las insuficiencias del mismo, y se puede ver como cualquiera que se lo figure (o que alguien le indique como funciona, o descargue la informacin de Bugtraq) puede loguearse como cualquier usuario. Una revisin manual, como una entrevista, habra descubierto la incidencia de seguridad rpidamente, como tambin lo hara una inspeccin del cdigo. Un scanner de caja negra de la aplicacin web habra visto un hash de 128 bits que cambia para cada usuario y, por la naturaleza de las funciones de hash, no cambia en ninguna forma predecible.

Nota sobre las herramientas de revisin de cdigo fuente estticoMuchas organizaciones han empezado a utilizar scanners de cdigo fuente esttico. Aunque sin duda tienen su lugar en un programa de pruebas exhaustivo, queremos remarcar algunas notas acerca de porque no creemos que esta aproximacin sea eficaz cuando es usada por si sola. El anlisis de cdigo fuente esttico aisladamente no puede comprender el contexto de construcciones semnticas en el cdigo, y por tanto es propenso a hallar un nmero significativo de falsos positivos. Particularmente esto es cierto con C y C++. La tecnologa es til en determinar partes interesantes en el cdigo, aunque es necesario un esfuerzo significativo para validar los hallazgos.

Por ejemplo:

char szTarget[12];char *s = "Hello, World"; size_t cSource = strlen_s(s,20); strncpy_s(temp,sizeof(szTarget),s,cSource); strncat_s(temp,sizeof(szTarget),s,cSource);

30 de 309


3. EL ENTORNO DE PRUEBAS OWASP

PRESENTACIN

Esta seccin describe un marco de pruebas tpico que puede ser desarrollado en una organizacin. Puedes verla como un marco de referencia que comprende tanto tcnicas como tareas que es apropiado realizar en varias fases del ciclo de vida de desarrollo del software (SDLC). Las compaas y los equipos de proyecto emplean este modelo para desarrollar su propio marco de trabajo y determinar el alcance de las pruebas que realizan los vendedores. Este marco de trabajo no debe ser tomado como preceptivo, sino como una aproximacin flexible que puede ser extendida y amoldada para encajar en el proceso de desarrollo y cultura de una empresa.

Esta seccin tiene por objetivo ayudar a las organizaciones a construir un proceso de pruebas estratgicas completo; no est dirigida a consultores o contratistas, que suelen estar ocupados en reas ms especficas y tcticas del testing.

Es crtico comprender porque construir un marco de trabajo de testing de principio a fin es crucial para evaluar y mejorar la seguridad del software. Howard y LeBlanc apuntan en Writing Secure Code que publicar un boletn de seguridad le cuesta a Microsoft como mnimo $100,000, y a sus clientes en conjunto mucho ms que eso el implementar los parches de seguridad. Tambin indican que el site web del gobierno de los EEUU para el Cibercrimen (http://www.cybercrime.gov/cccases.html) detalla casos criminales recientes y la prdida de las organizaciones. Las prdidas tpicas exceden ampliamente los $100,000.

Con datos as, es comprensible porque muchos vendedores de software pasan de realizar testing de seguridad de caja negra solamente, que solo se puede realizar en aplicaciones que ya han sido desarrolladas, a concentrarse en los primeros ciclos de desarrollo de la aplicacin, como la definicin, diseo y desarrollo.

Muchos profesionales de la seguridad ven todava la comprobacin de seguridad dentro del terreno de las pruebas de intrusin. Tal como se mostr en el Captulo 3: " ", y segn el marco de trabajo, aunque las pruebas de intrusin tienen un papel que jugar, generalmente es ineficaz en encontrar bugs, y depende excesivamente de la capacidad del probador. Debera ser considerado nicamente como una tcnica de implementacin, o suscitar una mayor atencin sobre incidencias de produccin. Para mejorar la seguridad de las aplicaciones, se debe antes mejorar la calidad de seguridad del software. Eso significa comprobar la seguridad en las fases de definicin, diseo, desarrollo, implementacin y mantenimiento, y no confiar en la costosa estrategia de esperar hasta que el cdigo est construido por completo.

Tal y como se expuso en la introduccin, hay muchas metodologas de desarrollo, como la de proceso racional unificado, desarrollo gil y extremo, y las metodologas tradicionales de cascada. La intencin de esta gua no es ni apuntar a una metodologa de desarrollo en particular ni proporcionar unas directrices especficas que se ajusten a una metodologa especfica. En vez de eso, presentamos un modelo de desarrollo genrico, y el lector debera seguirlo de acuerdo al proceso que emplee su compaa.

31 de 309

http://www.cybercrime.gov/cccases.html

Este marco de pruebas consta de las siguientes actividades que deberan tener lugar:

Antes de empezar el desarrollo

Durante el diseo y definicin

Durante el desarrollo

Durante la implementacin

Mantenimiento y operaciones

FASE 1: ANTES DE EMPEZAR EL DESARROLLO

Antes de que el desarrollo de la aplicacin haya empezado:

Comprobacin para asegurar que existe un SDLC adecuado, en el cual la seguridad sea inherente.

Comprobacin para asegurar que estn implementados la poltica y estndares de seguridad adecuados para el equipo de desarrollo.

Desarrollar las mtricas y criterios de medicin.

FASE 1A: REVISIN DE ESTNDARES Y POLTICAS

Asegurar que las polticas, documentacin y estndares adecuados estn implementados. La documentacin es extremadamente importante, ya que brinda al equipo de desarrollo polticas y directrices a seguir.

Las personas pueden hacer las cosas correctamente, solo si saben que es lo correcto.

Si la aplicacin va a ser desarrollada en JAVA, es esencial que haya un estndar de programacin segura en Java. Si la aplicacin va a usar criptografa, es esencial que haya un estndar de criptografa. Ninguna poltica o estndar puede cubrir todas las situaciones con las que se enfrentar un equipo de desarrollo. Documentando las incidencias comunes y predecibles, habr menos decisiones que afrontar durante el proceso de desarrollo.

FASE 1B - DESARROLLO DE MTRICAS Y CRITERIOS DE MEDICIN (ASEGURAR LA TRAZABILIDAD)

Antes de empezar el desarrollo, planifica el programa de medicin. Definir los criterios que deben ser medidos proporciona visibilidad de los defectos tanto en el proceso como en el producto. Es algo esencial definir las mtricas antes de empezar el desarrollo, ya que puede haber necesidad de modificar el proceso (de desarrollo) para poder capturar los datos necesarios.

FASE 2 - DURANTE EL DISEO Y DEFINICIN

32 de 309


FASE 2A: REVISIN DE LOS REQUISITOS DE SEGURIDAD

Los requisitos de seguridad definen como funciona una aplicacin desde una perspectiva de la seguridad. Es indispensable que los requisitos de seguridad sean probados. Probar, en este caso, significa comprobar los supuestos realizados en los requisitos, y comprobar si hay deficiencias en las definiciones de los requisitos.

Por ejemplo, si hay un requisito de seguridad que indica que los usuarios deben estar registrados antes de tener acceso a la seccin de whitepapers de un site, Significa que el usuario debe estar registrado con el sistema, o debe estar autenticado? Asegrate de que los requisitos sea lo menos ambiguo posible.

A la hora de buscar inconsistencias en los requisitos, ten en cuenta mecanismos de seguridad como:

Gestin de Usuarios (reinicio de contraseas, etc.)

Autenticacin

Autorizacin

Confidencialidad de los Datos

Integridad

Contabilidad

Gestin de Sesiones

Seguridad de Transporte

Segregacin de Sistemas en Niveles

Privacidad

FASE 2B: DISEO DE UNA ARQUITECTURA DE REVISIN

Las aplicaciones deberan tener una arquitectura y diseo documentados. Por documentados nos referimos a modelos, documentos de texto y semejantes. Es indispensable comprobar estos elementos para asegurar que el diseo y la arquitectura imponen un nivel de seguridad adecuado al definido en los requisitos.

Identificar fallos de seguridad en la fase de diseo no es solo una de las fases ms efectiva por costes a la hora de identificar errores, sino que tambin puede ser la fase ms efectiva para realizar cambios. Por ejemplo, ser capaz de identificar que el diseo precisa realizar decisiones de autorizacin en varias fases; p

Documents

Guía de Pruebas OWASP V2