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: 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:

<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: 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: 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 ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un atacante suplante a otro usuario.
http://www.example.com/login.php?name=alice&name=hacker

Ejemplo 2: el siguiente código utiliza la entrada de una solicitud HTTP para representar dos hipervínculos.

    ...
    String lang = request.getParameter("lang");
    GetMethod get = new GetMethod("http://www.example.com");
    get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
    get.execute();
    ...

URL: http://www.example.com?poll_id=4567
Link1: <a href="001">English<a>
Link2: <a href="002">Español<a>

El programador no ha tenido en cuenta la posibilidad de que un atacante proporcione un lang como en&poll_id=1 y después modifique poll_id a su antojo.

Se permite que las extensiones de teclado lean cada tecla que pulsa el usuario. Por lo general, los teclados de terceros se usan para facilitar la introducción de texto o para agregar emojis adicionales y pueden registrar lo que el usuario pulsa o incluso enviarlo a un servidor remoto para su procesamiento. Los teclados malintencionados también pueden distribuirse para actuar como un registrador de pulsaciones de teclas y leer todas las teclas pulsadas por el usuario para robar datos confidenciales como credenciales o números de tarjetas de crédito.

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: En el siguiente ejemplo, se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).

   URL url = new URL("http://www.android.com/");
   HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
   try {
     InputStream in = new BufferedInputStream(urlConnection.getInputStream());
     readStream(in);
     ...
   }

Es posible que la secuencia de entrada, instream, se haya visto comprometida, ya que se proporciona a través de un canal no cifrado ni autenticado.

Los conjuntos de cifrado son grupos de algoritmos que se usan para establecer comunicaciones seguras. Mientras establece una conexión entre un servidor y un cliente, el servidor determina cuál de los conjuntos de cifrado compatibles mutuamente usar. El servidor y los clientes tienen diferentes grupos de conjuntos de cifrado compatibles. Los conjuntos de cifrado no están normalmente recomendados y pueden introducir vulnerabilidades de seguridad en la aplicación. Se recomienda usar normalmente conjuntos de cifrado fuertes, sin vulnerabilidades de seguridad conocidas.

El campo de Config.PreferServerCipherSuites controla si el servidor sigue las preferencias de los conjuntos de cifrado del cliente o del servidor. Usar el conjunto de cifrado preferido por el cliente puede introducir vulnerabilidades de seguridad si se sabe que el conjunto de cifrado tiene deficiencias.

Ejemplo 1: El código siguiente establece el campo de PreferServerCipherSuites como false.

conf := &tls.Config{
    PreferServerCipherSuites: false,
}

La aplicación se comunica con su servidor de base de datos a través de canales no cifrados y podrá suponer un riesgo de seguridad significativo para la empresa y los usuarios de dicha aplicación. En este caso, un atacante puede modificar los datos de usuario introducidos o incluso ejecutar comandos SQL arbitrarios contra el servidor de base de datos.

Ejemplo 1: el código siguiente provoca que la aplicación se comunique con su servidor de base de datos a través de canales no cifrados:

  ...
  Using(SqlConnection DBconn = new SqlConnection("Data Source=210.10.20.10,1433; Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;"))
  {
    ...
  }
  ...

App Transport Security (ATS) aplica los procedimientos recomendados para conexiones de red seguras, como TLS 1.2 y el secreto de reenvío, y se actualizará en el futuro para reflejar los de la red de Apple.

App Transport Security (ATS) está habilitado de forma predeterminada cuando se usa NSURLSession ,NSURLConnection , oCFURL en iOS 9 o OS X El Capitan, lo que obliga a la aplicación a usar HTTPS con TLS 1.2 en todas las comunicaciones de red con el servidor back-end.

La aplicación está configurada para excluirse parcial o totalmente de App Transport Security (ATS), lo que la deja en riesgo de sufrir ataques "man-in-the-middle" y otros ataques basados en la red.

Ejemplo 1: Las siguientes entradas de la aplicación Info.plist deshabilitarán por completo App Transport Security:

<key>NSAppTransportSecurity</key>
<dict>
  <!--Include to allow all connections (DANGER)-->
  <key>NSAllowsArbitraryLoads</key>
  <true/>
</dict>

Ejemplo 2: Las siguientes entradas de la aplicación Info.plist deshabilitarán App Transport Security para yourserver.com:

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSExceptionDomains</key>
  <dict>
    <key>yourserver.com</key>
    <dict>
      <!--Include to allow subdomains-->
      <key>NSIncludesSubdomains</key>
      <true/>
      <!--Allow plain HTTP requests-->
      <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
      <true/>
      <!--Downgrades TLS version-->
      <key>NSTemporaryExceptionMinimumTLSVersion</key>
      <string>TLSv1.1</string>
    </dict>
  </dict>
</dict>

Asegúrese de que los hipervínculos en sus páginas web solo enlacen a ubicaciones seguras para evitar riesgos para el usuario al navegar por su sitio web. Incluso si el enlace redirige a partir de un protocolo inseguro (como HTTP) a un protocolo seguro (como HTTPS), la conexión inicial a través de un canal sin cifrar permite que a un atacante lanzar un ataque "man-in-the-middle" (MiTM). Así, este podrá controlar la página de aterrizaje que se abra.

Ejemplo: Considere el siguiente hipervínculo:

<a href="http://www.example.com/index.html"/>

Si un atacante está escuchando el tráfico de red entre el usuario y el servidor, puede imitar o manipular www.example.com para cargar su propia página web.

Es posible que los enlaces a sitios web de terceros inicialmente no se consideren importantes para la seguridad, pero a un usuario puede parecerle que un enlace en su página web supone un riesgo, lo que podría reducir la confianza del usuario en el uso de su plataforma.

El uso de configuraciones de seguridad del canal Google Remote Procedure Call (gRPC) que se especifican como no cifradas o que no son compatibles con la autenticación o no tienen la capacidad de identidad de conexión deja al canal expuesto a muchas formas de ataque. No se puede confiar en los datos enviados con este canal inseguro.

Ejemplo 1: El siguiente código muestra una configuración de canal gRPC con credenciales de canal no seguras

...
ManagedChannel channel = Grpc.newChannelBuilder("hostname", InsecureChannelCredentials.create()).build();
...

El uso de configuraciones de seguridad del servidor Google Remote Procedure Call (gRPC) que se especifican como no cifradas o que no tienen la capacidad de identidad de conexión deja al servidor expuesto a muchas formas de ataque. No se puede confiar en los datos enviados hacia y desde este servidor inseguro.

Ejemplo 1: El siguiente código muestra una configuración de servidor gRPC con credenciales de servidor no seguras

...
Server server = Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
...

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el atacante observa todo el tráfico HTTP en busca de los encabezados de ubicación y los vínculos que hacen referencia a HTTPS, y los reemplaza por HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP extraídas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el atacante se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otros datos privados, pero el servidor sigue recibiendo el tráfico HTTPS esperado del atacante para que nada parezca incorrecto.

La seguridad de transporte estricta de HTTP (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio que devuelve los encabezados HSTS a través de SSL/TLS durante un período especificado dentro del encabezado. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente por una HTTPS, incluso si el usuario escribe una URL con http:// en la barra de dirección URL del explorador.

Ejemplo: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar HSTS en los subdominios:

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts include-sub-domains="false" />
        </headers>
	</http>

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el atacante observa todo el tráfico HTTP en busca de los encabezados de ubicación y los vínculos que hacen referencia a HTTPS, y los reemplaza por versiones HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP extraídas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el atacante se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otros datos privados, pero el servidor sigue recibiendo el tráfico HTTPS esperado del atacante para que nada parezca incorrecto.


La seguridad de transporte estricta de HTTP (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio que devuelve los encabezados HSTS a través de SSL/TLS durante un período especificado dentro del encabezado. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente por una HTTPS, incluso si el usuario escribe una URL con http:// en la barra de dirección URL del explorador.

Ejemplo: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar los encabezados HSTS:

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts disabled="true" />
        </headers>
	</http>