Trabajo: Auditoría de código de una aplicación con la

herramienta de HP Fortify

Materia: Seguridad en el software

Nombre Alumno: Victor Andres Frias Benitez

Nombre Maestra: Rosa Barba Varela

UNIR México

Fecha: 26 de agosto de
2019

Contenido
Vulnerabilidades......................................................................................................................3
1. Contraseña codificada...............................................................................................4
= Explicación del código =.........................................................................................4
= Grafica =..........................................................................................................................5
= Posible solución =......................................................................................................5
2. Configuración incorrecta de Spring Boot: Actuator Endpoint
Security Disabled................................................................................................................6
= Explicación del código =.........................................................................................6
= Grafica =..........................................................................................................................7
= Posible solución =......................................................................................................7
3. Manipulación de encabezado: SMTP................................................................7
= Explicación del código =.........................................................................................7
= Grafica =..........................................................................................................................8
= Posible solución =......................................................................................................9
4. Evaluación dinámica de código: deserialización insegura..................9
= Explicación del código =.........................................................................................9
= Grafica =........................................................................................................................10
= Posible solución =....................................................................................................10
5. Gestión de claves: clave de cifrado codificada..........................................11
= Explicación del código =.......................................................................................11
= Grafica =........................................................................................................................12
= Posible solución =....................................................................................................12
6. Gestión de contraseñas: contraseña vacía..................................................12
= Explicación del código =.......................................................................................12
= Grafica =........................................................................................................................13
= Posible solución =....................................................................................................14
7. Credenciales de una tienda Android WebView.........................................14
= Explicación del código =.......................................................................................14
= Grafica =........................................................................................................................15
= Posible solución =....................................................................................................15
8. Conectarse a una base de datos con una contraseña vacía..........15
= Explicación del código =.......................................................................................15
= Grafica =........................................................................................................................16
= Posible solución =....................................................................................................16
9. Usuario y contraseña codificados para configurar la autenticación
16
= Explicación del código =.......................................................................................17
= Grafica =........................................................................................................................17
= Posible solución =....................................................................................................17
 10. Almacenamiento de cache................................................................................18
= Explicación del código =.......................................................................................18
= Grafica =........................................................................................................................18
= Posible solución =....................................................................................................18

Vulnerabilidades

En esta sección se describirán las vulnerabilidades críticas que fueron

escaneadas con la herramienta HP Fortify SCA la cual es la encargada de
reducir los riesgos del software identificando las vulnerabilidades de
seguridad que representan las mayores amenazas para su organización.
Determina la causa raíz de la vulnerabilidad, correlaciona y prioriza los
resultados y proporciona prácticas recomendadas para que los
desarrolladores puedan crear el código de una forma más segura.

1. Contraseña codificada
Las contraseñas codificadas pueden comprometer la seguridad del
sistema de una manera que no se puede remediar fácilmente.

= Explicación del código =

Este código se ejecutará con éxito, pero cualquiera que tenga acceso a
él tendrá acceso a la contraseña. Después de que el programa se haya
enviado, es probable que no haya forma de cambiar el usuario de la
base de datos "scott" con una contraseña de "tigre" a menos que el
programa esté parcheado. Un empleado con acceso a esta información
puede usarla para ingresar al sistema. Peor aún, si los atacantes tienen
acceso al código de bytes de la aplicación, pueden usar el comando
javap -c para acceder al código desensamblado, que contendrá los
valores de las contraseñas utilizadas. El resultado de esta operación
podría ser similar al siguiente para el ejemplo anterior:

javap -c ConnMngr.class
22: ldc #36; //String jdbc:mysql://ixne.com/rxsql
24: ldc #38; //String scott
26: ldc #17; //String tiger

En el entorno móvil, la administración de contraseñas es especialmente

importante dado que existe un nivel tan alto posibilidad de pérdida de
dispositivo.

= Grafica =
 = Posible solución =

Las contraseñas nunca deben estar codificadas y generalmente deben

ofuscarse y administrarse en una fuente externa. El almacenamiento de
contraseñas en texto sin formato en cualquier parte del sistema permite
a cualquier persona con permisos suficientes leer y potencialmente usar
mal la contraseña. Como mínimo, las contraseñas se deben cifrar antes
de almacenarlas.

Algunos productos de terceros reclaman la capacidad de administrar

contraseñas de una manera más segura. Por ejemplo, WebSphere
Application Server 4.x utiliza un algoritmo de cifrado XOR simple para
ofuscar valores, pero sea escéptico acerca de tales facilidades.
WebSphere y otros servidores de aplicaciones ofrecen mecanismos de
cifrado obsoletos y relativamente débiles que son insuficientes para
entornos sensibles a la seguridad. Hoy, la mejor opción para una
solución genérica segura es crear un mecanismo propietario usted
mismo.

Para Android, así como cualquier otra plataforma que use la base de
datos SQLite, SQLCipher es una buena alternativa. SQLCipher es una
extensión de la base de datos SQLite que proporciona un cifrado AES
transparente de 256 bits de los archivos de la base de datos. Por lo
tanto, las credenciales se pueden almacenar en una base de datos
cifrada.

2. Configuración incorrecta de Spring Boot: Actuator

Endpoint Security Disabled
La aplicación Spring Boot utiliza puntos finales de Actuator que no
requieren autenticación.

= Explicación del código =

Las aplicaciones Spring Boot se pueden configurar para implementar Actuadores, que son
puntos finales REST que permiten a los usuarios monitorear diferentes aspectos de la
aplicación. Hay diferentes actuadores integrados que pueden exponer datos confidenciales
y están etiquetados como "confidenciales". De manera predeterminada, todos los puntos
finales HTTP confidenciales están protegidos de modo que solo los usuarios que tengan un
rol ACTUADOR puedan acceder a ellos.

Esta aplicación está desactivando el requisito de autenticación para puntos finales

sensibles:

endpoints.health.sensitive=false

O un Actuador personalizado se configura como no sensible:

@Component
public class CustomEndpoint implements Endpoint> {
public String getId() {
return "customEndpoint";
}
public boolean isEnabled() {
return true;
}
public boolean isSensitive() {
return false;
}
public List%lt;String> invoke() {
// Custom logic to build the output
...
}
}

= Grafica =
 = Posible solución =

Todos los puntos finales que exponen información u operaciones

confidenciales deben protegerse con los niveles correctos de autenticación
y autorización. Siempre es una buena práctica requerir autenticación
incluso para servidores internos como un mecanismo de seguridad en
profundidad. Tenga en cuenta que incluso en el caso de que la aplicación
se implemente internamente, detrás de un cortafuegos, un atacante aún
puede llegar a ella utilizando una vulnerabilidad de falsificación de
solicitudes del lado del servidor que se encuentra en una aplicación
diferente.

3. Manipulación de encabezado: SMTP

La inclusión de datos no validados en un encabezado SMTP puede permitir

a los atacantes agregar encabezados arbitrarios, como CCor BCC que
pueden usar para filtrar el contenido del correo o usar el servidor de
correo como un bot de spam.

= Explicación del código =

El siguiente segmento de código lee el asunto y el cuerpo del formulario

"Contáctenos":

$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject,
$body);

Suponiendo que en la solicitud se envíe una cadena que consta de

caracteres alfanuméricos estándar, como "Página que no funciona", los
encabezados SMTP pueden adoptar la siguiente forma:}

...
subject: [Contact us query] Page not working
...
 Sin embargo, debido a que el valor del encabezado se construye a partir
de la entrada no validada del usuario, la respuesta solo mantendrá este
formulario si el valor enviado para el asunto no contiene ningún carácter
CR y LF. Si un atacante envía una cadena maliciosa, como "¡Felicidades!
¡Ganaste la lotería! \ R \ ncc: victim1 @ mail.com, victim2 @ mail.com ...",
entonces los encabezados SMTP serían siguiente forma:

...
subject: [Contact us query] Congratulations!! You won the
lottery cc: victim1@mail.com,victim2@mail.com
...

Esto permitirá que un atacante cree mensajes de spam o envíe correos

electrónicos anónimos, entre otros.

= Grafica =

= Posible solución =

La solución para la manipulación de encabezado SMTP es garantizar que la

validación de entrada se realice en los lugares correctos y verifique las
propiedades correctas.
Dado que las vulnerabilidades de manipulación de encabezado SMTP se
producen cuando una aplicación incluye datos maliciosos en su salida, un
enfoque lógico es validar los datos inmediatamente antes de que se usen en
el contexto del encabezado y asegurarse de que no haya caracteres CRLF
ilegales que puedan romper la estructura del encabezado.

4. Evaluación dinámica de código: deserialización insegura

La deserialización de flujos de objetos controlados por el usuario en tiempo

de ejecución puede permitir a los atacantes ejecutar código arbitrario en el
servidor, abusar de la lógica de la aplicación y / o conducir a la denegación
de servicio.

= Explicación del código =

La serialización de Java convierte los gráficos de objetos en flujos de bytes

que contienen los objetos mismos y los metadatos necesarios para
reconstruirlos a partir del flujo de bytes. Los desarrolladores pueden crear
código personalizado para ayudar en el proceso de deserialización de
objetos Java, donde incluso pueden reemplazar los objetos deserializados
con diferentes objetos o proxies. El proceso de deserialización
personalizado se lleva a cabo durante la reconstrucción de objetos antes de
que los objetos se devuelvan a la aplicación y se conviertan en los tipos
esperados. Para cuando los desarrolladores intenten imponer un tipo
esperado, es posible que el código ya se haya ejecutado.

Las rutinas de deserialización personalizadas se definen en las clases

serializables que deben estar presentes en el classpath en tiempo de
ejecución y no pueden ser inyectadas por el atacante, por lo que la
explotabilidad de estos ataques depende de las clases disponibles en el
entorno de la aplicación. Desafortunadamente, clases comunes de terceros
o incluso

Ejemplos

RMIServiceExporter exposing TestService

JMSInvokerServiceExporter exposing TestService
HTTPInvokerServiceExporter exposing TestService

= Grafica =

= Posible solución =

El flujo de objetos primero contendrá los metadatos de la descripción de la

clase y luego los bytes serializados de sus campos miembros. El proceso de
serialización de Java permite a los desarrolladores leer la descripción de la
clase y decidir si proceder con la deserialización del objeto o abortarlo.
Para hacerlo, es necesario subclasificar java.io.ObjectInputStream y
proporcionar una implementación personalizada del método resolveClass
(ObjectStreamClass desc) donde debe llevarse a cabo la validación y
verificación de la clase.

Para evitar ataques de denegación de servicio, se recomienda anular el

método resolveObject (Object obj) para contar cuántos objetos se
deserializan y abortar la deserialización cuando se supera un umbral.

Cuando la deserialización se lleva a cabo en una biblioteca o marco (por

ejemplo, cuando se usan JMX, RMI, JMS, HTTP Invokers) la recomendación
anterior no es útil ya que está fuera del control del desarrollador. En esos
casos, es posible que desee asegurarse de que estos protocolos cumplan
con los siguientes requisitos:
- No expuesto públicamente.

- Usar autenticación.

- Utilice verificaciones de integridad.

- Utiliza encriptación.

5. Gestión de claves: clave de cifrado codificada

Las claves de cifrado codificadas pueden comprometer la seguridad de una

manera que no se puede remediar fácilmente.

= Explicación del código =

Nunca es una buena idea codificar una clave de cifrado porque permite a
todos los desarrolladores del proyecto ver la clave de cifrado y hace que la
solución del problema sea extremadamente difícil. Una vez que el código
está en producción, se requiere un parche de software para cambiar la
clave de cifrado. Si la cuenta que está protegida por la clave de cifrado se
ve comprometida, los propietarios del sistema deben elegir entre
seguridad y disponibilidad.

El siguiente código utiliza una clave de cifrado codificada:

...
private static final String encryptionKey =
"lakdsljkalkjlksdfkl";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...

Cualquier persona con acceso al código tiene acceso a la clave de cifrado.

Una vez que se ha enviado la aplicación, no hay forma de cambiar la clave
de cifrado a menos que se repare el programa. Un empleado con acceso a
esta información puede usarla para ingresar al sistema. Si los atacantes
tuvieran acceso al ejecutable de la aplicación, podrían extraer el valor de la
clave de cifrado.
 = Grafica =

= Posible solución =

Las claves de cifrado nunca deben estar codificadas y deben ofuscarse y

administrarse en una fuente externa.

El almacenamiento de claves de cifrado en texto sin formato en cualquier

parte del sistema permite que cualquier persona con permisos suficientes
lea y potencialmente use incorrectamente la clave de cifrado.

6. Gestión de contraseñas: contraseña vacía

Las contraseñas vacías pueden comprometer la seguridad del sistema
de una manera que no se puede remediar fácilmente

= Explicación del código =

Nunca es una buena idea asignar una cadena vacía a una variable de
contraseña. Si la contraseña vacía se usa para autenticarse con éxito en
otro sistema, entonces la seguridad de la cuenta correspondiente se ve
comprometida porque acepta una contraseña vacía. Si la contraseña
vacía es simplemente un marcador de posición hasta que se pueda
asignar un valor legítimo a la variable, puede confundir a cualquier
persona que no esté familiarizada con el código y potencialmente
causar problemas en rutas de flujo de control inesperadas.

El siguiente código inicializa una variable de contraseña en una cadena

vacía, intenta leer un valor almacenado para la contraseña y la compara
con un valor proporcionado por el usuario.

...
String storedPassword = "";
String temp;
if ((temp = readPassword()) != null) {
storedPassword = temp;
}
if(storedPassword.equals(userPassword))
// Access protected resources
...
}
...

Si readPassword () no puede recuperar la contraseña almacenada

debido a un error de la base de datos u otro problema, entonces un
atacante podría omitir trivialmente la verificación de contraseña al
proporcionar una cadena vacía para userPassword. En el entorno móvil,
la administración de contraseñas es especialmente importante dado que
existe una alta probabilidad de pérdida del dispositivo.

= Grafica =
= Posible solución =

Lea siempre los valores de contraseña almacenados de recursos externos

encriptados y asigne valores significativos a las variables de contraseña.
Asegúrese de que los recursos confidenciales nunca estén protegidos con
contraseñas vacías o nulas.

7. Credenciales de una tienda Android WebView

En el entorno móvil, la administración de contraseñas es especialmente
importante dado que existe una alta probabilidad de pérdida del
dispositivo.

= Explicación del código =

El siguiente código inicializa las variables de nombre de usuario y

contraseña en cadenas vacías, lee las credenciales de una tienda WebView
de Android si el servidor no las ha rechazado previamente para la solicitud
actual, y las usa para configurar la autenticación para ver páginas
protegidas

webview.setWebViewClient(new WebViewClient() {
public void onReceivedHttpAuthRequest(WebView view,
HttpAuthHandler handler, String host, String realm) {
String username = "";
String password = "";
if (handler.useHttpAuthUsernamePassword()) {
String[] credentials = view.getHttpAuthUsernamePassword(host,
realm);
username = credentials[0];
password = credentials[1];
}
handler.proceed(username, password);
 }
});
...

= Grafica =

= Posible solución =

Lea siempre los valores de contraseña almacenados de recursos externos

encriptados y asigne valores significativos a las variables de contraseña.
Asegúrese de que los recursos confidenciales nunca estén protegidos con
contraseñas vacías o nulas.

Para Android, así como cualquier otra plataforma que use la base de datos
SQLite, SQLCipher es una buena alternativa. SQLCipher es una extensión
de la base de datos SQLite que proporciona un cifrado AES transparente de
256 bits de los archivos de la base de datos. Por lo tanto, las credenciales se
pueden almacenar en una base de datos cifrada.
 8. Conectarse a una base de datos con una contraseña vacía.
Las claves de cifrado codificadas pueden comprometer la seguridad de una
manera que no se puede remediar fácilmente.

= Explicación del código =

Nunca es una buena idea asignar una cadena vacía a una variable de
contraseña. Si la contraseña vacía se usa para autenticarse con éxito en
otro sistema, entonces la seguridad de la cuenta correspondiente se ve
comprometida porque acepta una contraseña vacía. Si la contraseña vacía
es simplemente un marcador de posición hasta que se pueda asignar un
valor legítimo a la variable, puede confundir a cualquier persona que no
esté familiarizada con el código y potencialmente causar problemas en
rutas de flujo de control inesperadas....
El siguiente código intenta conectarse a una base de datos con una
contraseña vacía.

DriverManager.getConnection(url, "scott", "");

= Grafica =

= Posible solución =
Lea siempre los valores de contraseña almacenados de recursos externos
encriptados y asigne valores significativos a las variables de contraseña.
Asegúrese de que los recursos confidenciales nunca estén protegidos con
contraseñas vacías o nulas.

9. Usuario y contraseña codificados para configurar la

autenticación
Las contraseñas y usuario pueden comprometer la seguridad del
sistema de una manera que no se puede remediar fácilmente

= Explicación del código =

El siguiente código utiliza un nombre de usuario y contraseña

codificados para configurar la autenticación para ver páginas
protegidas con WebView de Android.

...
webview.setWebViewClient(new WebViewClient() {
public void onReceivedHttpAuthRequest(WebView view,
HttpAuthHandler handler, String host, String realm) {
handler.proceed("guest", "allow");
}
});
...

= Grafica =
= Posible solución =

Lea siempre los valores de contraseña almacenados de recursos externos

encriptados y asigne valores significativos a las variables de contraseña.
Asegúrese de que los recursos confidenciales nunca estén protegidos con
contraseñas vacías o nulas.

10. Almacenamiento de cache

En el entorno móvil, la administración de la chache es un recurso
importante ya ‘que en esta se almacenan los datos de configuración de la
aplicación.

= Explicación del código =

El siguiente código inicializa las variables las cuales se almacenan en json

solicitado por la aplicación

type: 'POST',
8 url: 'JWT/refresh/login',
9 contentType: "application/json",
10 data: JSON.stringify({user: user, password: "bm5nhSkxCXZkKRy4"})
11 }).success(
12 function (response) {
13 localStorage.setItem('access_token', response['access_token']);

= Grafica =
= Posible solución =

Lea siempre los valores de contraseña almacenados de recursos externos

encriptados y asigne valores significativos a las variables de contraseña.
Asegúrese de que los recursos confidenciales nunca estén protegidos con
contraseñas vacías o nulas.