A6-Sensitive

Agentes de Los vectores de La debilidad de Impactos Impactos de

amenaza ataque seguridad tcnicos negocio
Prevalenci Detectabilid
Application /
Aplicacin Explotacin a ad Impactar
negocio
especfica DIFICIL UNCOMM PROMEDI GRAVES
especfico
ON O
Considere Los atacantes El defecto ms comn La falta con Considere el
que pueden normalmente no simplemente no est frecuencia valor
tener se rompen cripto encriptando los datos compromet comercial de
acceso a directamente. Ro sensibles. Cuando se e todos los los datos
sus datos mpen otra cosa, emplea crypto, dbil datos que perdidos y el
sensibles y como por ejemplo generacin de claves y deberan impacto de su
cualquier robar claves, la gestin, y el uso de haber sido reputacin.
copia de hacer ataques algoritmo dbil es protegidos. Cul es su
seguridad man-in-the- particularmente dbiles Por lo responsabilid
de los middle, o robar tcnicas comunes, general, ad legal si se
datos. Esto datos de texto contrasea de esta expone estos
incluye los claros fuera del hashing. debilidades informacin datos? Ten en
datos en servidor, mientras del navegador son muy incluye cuenta
reposo, en estn en trnsito, comunes y fciles de datos tambin el
trnsito, e o desde el detectar, pero es difcil sensibles, dao a su
incluso en navegador del de explotar a gran tales como reputacin.
los usuario. escala. Los atacantes los registros
navegadore externos tienen de salud,
s de sus dificultades para credenciale
clientes. Inc detectar defectos del s, datos
luir tanto lado del servidor personales,
las
debido al acceso tarjetas de
amenazas limitado y tambin son crdito, etc.
externas e generalmente difciles
internas. de explotar.

Lo primero que hay que determinar es qu datos es lo suficientemente sensible

como para requerir proteccin adicional. Por ejemplo, contraseas, nmeros de
tarjetas de crdito, registros de salud, e informacin personal deben ser
protegidos. Para todos estos datos:

1. Es cualquiera de estos datos almacenados en texto claro a largo plazo,

incluyendo las copias de seguridad de estos datos?
 2. Es cualquiera de estos datos transmitida en texto claro, interna o
externamente? El trfico de Internet es especialmente peligroso.

3. Se hacen viejos algoritmos de cifrado / dbiles usados?

4. Se generan claves criptogrficas dbiles, o es la gestin de clave adecuada

o rotacin falta?

5. Son las directivas de seguridad del navegador o cabeceras faltan cuando

los datos sensibles es proporcionada por / enviado al navegador?

Los peligros de pleno derecho de la criptografa insegura, el uso de SSL y

proteccin de datos estn ms all del alcance de los Top 10. Dicho esto, para
todos los datos sensibles, hacer todo de los siguientes, como mnimo:

1. Teniendo en cuenta las amenazas que planea proteger estos datos a partir
de (por ejemplo, ataque interno, el usuario externo), asegrese de cifrar
todos los datos sensibles en reposo y durante el transporte de una manera
que protege contra estas amenazas.

2. No almacene datos confidenciales de forma innecesaria. Desprenderse de

ella tan pronto como sea posible. Los datos que no tiene no puede ser
robado.

3. Garantizar fuertes algoritmos estndar y se utilizan claves de alta

seguridad, y gestin de claves adecuado est en su lugar. Considere el uso
de FIPS 140 mdulos criptogrficos validados .

4. Asegurar que las contraseas se almacenan con un algoritmo diseado

especficamente para la proteccin de contrasea, como bcrypt , PBKDF2 ,
o scrypt .

5. Desactivar autocompletar en formas de recoleccin de datos sensibles y

almacenamiento en cach desactivar para las pginas que contienen datos
sensibles.

Escenarios de Ejemplo Ataque

Escenario # 1:
Una aplicacin encripta los nmeros de tarjetas de crdito en una base de datos
mediante el cifrado de base de datos automtica. Sin embargo, esto significa que
tambin descifra estos datos automticamente cuando recuperada, lo que permite
un defecto de inyeccin SQL para recuperar los nmeros de tarjetas de crdito en
texto claro. El sistema debera haber encriptado los nmeros de tarjetas de crdito
a travs de una clave pblica, y slo se permite aplicaciones de back-end para
descifrar con la clave privada.

Escenario # 2:
Un sitio simplemente no utiliza SSL para todas las pginas autenticados. Atacante
simplemente supervisa el trfico de red (como una red inalmbrica abierta), y roba
cookie de sesin del usuario. El atacante entonces vuelve a reproducir esta cookie
y secuestra la sesin del usuario, acceder a los datos privados del usuario.

Escenario # 3:
La base de datos utiliza la contrasea hashes sin salt para almacenar las
contraseas de todos. Un defecto de carga de archivos permite a un atacante para
recuperar el archivo de contraseas. Todos los nmeros hash sin sal se puede
exponer con una tabla de arco iris de los hashes precalculados.

Herramientas de deteccin

Usando kali linux

w3af
Nikto