En Spring Webflow, se utiliza un solucionador de vistas para traducir el nombre de una vista en una tecnología de representación real. Normalmente, un solucionador de vistas limitará el tipo y la ubicación de los archivos utilizando prefijos y sufijos. Sin embargo, el uso de parámetros de solicitud para especificar el nombre de la vista permite eludir este mecanismo.
Ejemplo 1: Las siguientes configuraciones de Spring Webflow usan parámetros de solicitud para especificar el nombre de la vista.

<webflow:end-state id="finalStep" view="${requestParameters.url}"/>
<webflow:view-state id="showView" view="${requestParameters.test}">

El solucionador de vistas predeterminado de Spring Webflow está diseñado para permitir que solo se resuelvan los archivos jsp en "/WEB-INF/views/".

<bean class="org.springframework.web.servlet.view.
               InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/views/" />
    <property name="suffix" value=".jsp" />
</bean>

Un atacante podría usar la siguiente URL para ver el archivo applicationContext.xml: "http://www.yourcorp.com/webApp/logic?url=../applicationContext.xml;x="
El InternalResourceViewResolver tomará el prefijo con el que está configurado, luego concatenará el valor pasado en el atributo de vista y finalmente agregará el sufijo.
La URL relativa resultante, "/WEB-INF/views/../applicationContext.xml;x=.jsp" se pasa al distribuidor de solicitudes del lado del servidor. El punto y coma permite al atacante convertir el sufijo ".jsp" en un parámetro de ruta. Este ataque se puede utilizar para revelar cualquier archivo en la raíz de la aplicación web.

Un archivo queda al descubierto cuando:
1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se utilizan para crear de forma dinámica una ruta.

Ejemplo 1: el siguiente código obtiene datos que no son de confianza y los utiliza para crear una ruta que se utiliza en un reenvío del servidor.

...
	String returnURL = request.getParameter("returnURL");
	return new ActionForward(returnURL);
	...

Si un usuario malintencionado ha proporcionado una URL con un parámetro de solicitud que coincide con una ubicación de archivo confidencial, este podrá ver ese archivo. Por ejemplo, "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" le permitiría ver el archivo applicationContext.xml de la aplicación.
Una vez que el usuario malintencionado dispone de applicationContext.xml, podría localizar y descargar otros archivos de configuración a los que se hace referencia en este archivo, o incluso archivos class o jar. Esto permitiría a un usuario malintencionado obtener información confidencial acerca de una aplicación y usarla para otros tipos de ataques.

Se producen errores de File Permission Manipulation cuando se cumplen algunas de las siguientes condiciones:

1. Un atacante puede especificar una ruta de acceso utilizada en una operación que modifica los permisos del sistema de archivos.

2. Un atacante puede especificar los permisos asignados por una operación en el sistema de archivos.

Ejemplo 1: el siguiente código utiliza la entrada desde las propiedades del sistema para establecer la máscara de permisos predeterminada. Si los atacantes pueden modificar las propiedades del sistema, pueden utilizar el programa para obtener acceso a los archivos que el programa ha manipulado. Si el programa también es vulnerable a la manipulación de rutas de acceso, un usuario malintencionado puede utilizar esta vulnerabilidad para obtener acceso a archivos arbitrarios del sistema.

  String permissionMask = System.getProperty("defaultFileMask");
  Path filePath = userFile.toPath();
  ...
  Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
  Files.setPosixFilePermissions(filePath, perms);
...

De forma predeterminada, las aplicaciones Flash están sujetas a la misma directiva de origen, lo que garantiza que dos aplicaciones SWF pueden tener acceso a los datos respectivos solo si proceden del mismo dominio. Adobe Flash permite a los desarrolladores modificar la directiva mediante programación o a través de la configuración adecuada en el archivo de configuración crossdomain.xml. Sin embargo, es necesario tener cuidado al cambiar la configuración porque una directiva entre dominios demasiado permisiva permitirá que una aplicación malintencionada se comunique con la aplicación víctima de manera inadecuada, lo que provocará suplantación de identidad, robo de datos, retransmisión y otros ataques.

Ejemplo 1: El código siguiente es un ejemplo del uso de un carácter comodín para especificar mediante programación los dominios con los que la aplicación se puede comunicar.

   flash.system.Security.allowDomain("*");

El uso de * como el argumento de allowDomain() indica que otras aplicaciones SWF pueden tener acceso a los datos desde cualquier dominio.

De forma predeterminada, las aplicaciones Flash están sujetas a la misma directiva de origen, lo que garantiza que dos aplicaciones SWF pueden tener acceso a los datos respectivos solo si proceden del mismo dominio. Adobe Flash permite a los desarrolladores modificar la directiva mediante programación o a través de la configuración adecuada en el archivo de configuración crossdomain.xml. A partir de Flash Player 9,0,124,0, Adobe también introdujo la capacidad de definir qué encabezados personalizados Flash Player puede enviar a través de dominios. Sin embargo, se debe tener precaución al definir esta configuración porque una directiva de encabezados personalizados demasiado permisiva, cuando se aplica junto con la directiva entre dominios demasiado permisiva, permitirá que una aplicación malintencionada envíe encabezados de su elección a la aplicación de destino, lo que podría conducir a diversos ataques o provocar errores en la ejecución de la aplicación que no sabe cómo manejar los encabezados recibidos.

Ejemplo 1: La configuración siguiente muestra el uso de un carácter comodín para especificar los encabezados que puede enviar Flash Player entre dominios.

  <cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="*"/>
  </cross-domain-policy>

Utilizar el* como el valor del atributo headers indica que cualquier encabezado se enviará a través de dominios.

De forma predeterminada, las aplicaciones Flash están sujetas a la misma directiva de origen, lo que garantiza que dos aplicaciones SWF pueden tener acceso a los datos respectivos solo si proceden del mismo dominio. Adobe Flash permite a los desarrolladores modificar la directiva mediante programación o a través de la configuración adecuada en el archivo de configuración crossdomain.xml. Sin embargo, es necesario tener cuidado al decidir quién puede influir en la configuración porque una directiva entre dominios demasiado permisiva permitirá que una aplicación malintencionada se comunique con la aplicación víctima de manera inadecuada, lo que provocará suplantación de identidad, robo de datos, retransmisión y otros ataques. Las vulnerabilidades de omisión de las restricciones de directivas se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se utilizan para cargar o modificar la configuración de directivas entre dominios.
Ejemplo 1: El siguiente código utiliza el valor de uno de los parámetros para el archivo SWF cargado como la dirección URL desde donde cargar el archivo de directivas entre dominios.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

Ejemplo 2: El siguiente código utiliza el valor de uno de los parámetros para el archivo SWF cargado con el fin de definir la lista de dominios de confianza.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

A partir de Flash Player 7, no se permite que las aplicaciones SWF cargadas a través de HTTP tengan acceso a los datos de las aplicaciones SWF cargadas a través de HTTPS de forma predeterminada. Adobe Flash permite a los desarrolladores modificar esta restricción mediante programación o a través de la configuración adecuada en el archivo de configuración crossdomain.xml. Sin embargo, se deben tomar precauciones al definir esta configuración porque las aplicaciones SWF cargadas a través de HTTP son objeto de ataques Man-In-The-Middle (MITM) y, por tanto, no son de confianza.

Ejemplo 1: El siguiente código llama a allowInsecureDomain(), que desactiva la restricción que impide que las aplicaciones SWF cargadas a través de HTTP tengan acceso a los datos de las aplicaciones SWF cargadas a través de HTTPS.

   flash.system.Security.allowInsecureDomain("*");

Si está utilizando Blaze DS para llevar a cabo el registro de eventos inesperados, el archivo del descriptor services-config.xml especifica un elemento XML "Logging" (Registro) para describir los diferentes aspectos del registro. Tiene un formato similar al siguiente:

Ejemplo 1:

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

Esta etiqueta target toma un atributo opcional que se llama level, el cual indica el nivel de registro. Si el nivel de depuración se establece en un nivel demasiado detallado, su aplicación puede escribir datos confidenciales en el archivo de registro.

Las vulnerabilidades de cadena de formato se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.



2. Los datos se transfieren como argumento de cadena de formato a una función, como sprintf(), FormatMessageW() o syslog().
Ejemplo 1: el siguiente código copia un argumento de línea de comandos en un búfer mediante snprintf().

int main(int argc, char **argv){
	char buf[128];
	...
	snprintf(buf,128,argv[1]);
}

Este código permite a un usuario malintencionado ver el contenido de la pila y escribir en esta mediante el argumento de línea de comandos que contiene una secuencia de directivas de formato. El atacante puede leer desde la pila proporcionando más directivas de formato como, por ejemplo, %x, que la función utiliza como argumentos a los que aplicar un formato. (En este ejemplo, la función no utiliza ningún argumento al que se le vaya aplicar un formato.) Mediante la directiva de formato %n, el usuario malintencionado puede escribir en la pila lo que provoca que snprintf() escriba la salida de un número de bytes hasta el momento en el argumento especificado (en lugar de leer un valor del argumento, que es el comportamiento previsto). Una versión sofisticada de este ataque utilizará cuatro operaciones de escritura escalonadas para controlar por completo el valor de un puntero en la pila.

Ejemplo 2: determinadas implementaciones realizan ataques más avanzados de forma más fácil al proporcionar directivas de formato que controlan la ubicación en la memoria para leer esta o escribir en ella. A continuación se muestra un ejemplo de estas directivas con el siguiente código, escrito para glibc:

	printf("%d %d %1$d %1$d\n", 5, 9);

Este código genera la siguiente salida:

5 9 5 5

También se pueden utilizan medias operaciones de escritura (%hn) para controlar elementos DWORDS arbitrarios en la memoria, lo que reduce considerablemente la complejidad necesaria para ejecutar un ataque que, de otro modo, requeriría cuatro operaciones de escritura escalonadas como la que se menciona en el Example 1.

Ejemplo 3: las vulnerabilidades de cadena de formato sencillo a menudo proceden de atajos aparentemente inofensivos. El uso de estos atajos está tan arraigado que es posible que los programadores ni siquiera se den cuenta de que la función que están utilizando espera un argumento de cadena de formato.

Por ejemplo, la función syslog() se usa a menudo de la siguiente forma:

	...
	syslog(LOG_ERR, cmdBuf);
	...

Como el segundo parámetro en syslog() es una cadena de formato, todas las directivas de formato incluidas en cmdBuf se interpretan como se describe en el Example 1.

El siguiente código muestra un uso correcto de syslog():

	...
	syslog(LOG_ERR, "%s", cmdBuf);
	...

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa pueda acceder a valores fuera de los límites de la memoria asignada.

Ejemplo 1: El siguiente lee valores arbitrarios desde la pila porque el número de especificadores de formato no se corresponde con el número de argumentos transferidos a la función.

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa convierta incorrectamente valores de datos o que tenga acceso a valores fuera de los límites de la memoria asignada.

Ejemplo 1: El código siguiente convierte incorrectamente f desde un flotador usando un especificador de formato %d.

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

Los procesadores de hojas de cálculo más populares, como Apache OpenOffice Calc y Microsoft Office Excel, soportan potentes operaciones de fórmulas que pueden permitir a los atacantes de la hoja de cálculo ejecutar comandos arbitrarios en el sistema subyacente o filtrar información confidencial en la hoja de cálculo.

Como ejemplo, el atacante puede inyectar la siguiente carga como parte de un campo CSV: =cmd|'/C calc.exe'!Z0. Si el usuario que abre la hoja de cálculo confía en el origen del documento, puede aceptar todas las indicaciones de seguridad presentadas por el procesador de la hoja de cálculo y dejar que la carga (en este ejemplo, abrir la calculadora de Windows) se ejecute en el sistema.

Ejemplo 1: el ejemplo siguiente muestra un controlador de Spring que genera una respuesta CSV con datos no comprobados controlados por el usuario:

    @RequestMapping(value = "/api/service.csv")
    public ResponseEntity<String> service(@RequestParam("name") String name) {

        HttpHeaders responseHeaders = new HttpHeaders();
        responseHeaders.add("Content-Type", "application/csv; charset=utf-8");
        responseHeaders.add("Content-Disposition", "attachment;filename=file.csv");

        String data = generateCSVFor(name);

        return new ResponseEntity<>(data, responseHeaders, HttpStatus.OK);
    }

Un aplicación maliciosa puede invocar una PreferenceActivity no segura y proporcionarle una intención :android:show_fragment extra para que cargue una clase arbitraria. La aplicación maliciosa puede hacer que PreferenceActivity cargue un Fragment arbitrario de la aplicación vulnerable, el cual que se suele cargar en una actividad no exportada, para exponerlo al atacante.

Ejemplo 1: El código siguiente no implementa una comprobación para verificar que solo se cargan los fragmentos esperados.

@Override
public static boolean isFragmentValid(Fragment paramFragment)
{
    return true;
}

Las vulnerabilidades de la suplantación de marcos se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable.

2. Los datos se utilizan como una URL de iframe sin que se validen.

De esta forma, un atacante podrá controlar lo que se representa en el marco de la línea. Al modificar la dirección URL del marco para apuntar a un sitio malicioso, se pueden realizar ataques de suplantación de identidad para intentar robar información del usuario, incluidas las credenciales u otros datos confidenciales. Dado que el dominio básico es de confianza, Salesforce.com, la víctima confiará en la página y proporcionará toda la información solicitada.

Ejemplo 1: en el siguiente ejemplo de código, el parámetro URL de iframesrc se utiliza directamente como la dirección URL de apex:iframe de destino.

<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>

De esta forma, si un atacante proporciona a una víctima el parámetro iframesrc establecido en un sitio web malintencionado, el marco se representará con el contenido del sitio web malintencionado.

<iframe src="http://evildomain.com/">

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

Otorgar acceso o funciones de BigQuery al tipo principal especial, como allUsers y allAuthenticatedUsers, otorga a cualquier persona acceso a datos confidenciales.

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

DNSSEC evita la falsificación de DNS al proporcionar la capacidad de usar firmas digitales para la validación de respuestas de DNS. La DNSSEC de un dominio DNS en la nube no está habilitada.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita la DNSSEC en un dominio DNS en la nube configurando state en off en el bloque dnssec_config.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    state = "off"
    ...
  }
...
}

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones