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);
...

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);
   ...
}

Incluir contenido ejecutable de otro sitio web es una proposición arriesgada. Vincula la seguridad de nuestro sitio con la seguridad del otro sitio.

Ejemplo: Observe la siguiente etiqueta script.

  <script src="http://www.example.com/js/fancyWidget.js"></script>

Si esta etiqueta aparece en otro sitio web distinto de www.example.com, este sitio dependerá de www.example.com para suministrar código válido y malintencionado. Si los atacantes consiguen comprometer www.example.com, podrán alterar el contenido de fancyWidget.js para trastornar la seguridad del sitio. Podrían, por ejemplo, añadir código a fancyWidget.js para robar los datos confidenciales de un usuario.

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>

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 utilizar un tiempo de vencimiento breve:

    @Override 
    protected void configure(HttpSecurity http) throws Exception {
        http.httpStrictTransportSecurity().maxAgeInSeconds(300);
    }

Los datos confidenciales enviados a través de una conexión de cable sin cifrar pueden ser leídos o modificados por cualquier atacante que pueda interceptar el tráfico de la red.

Ejemplo 1: La siguiente instancia de Spring Mailer está configurada incorrectamente, no usa SSL/TLS para comunicarse con un servidor SMTP:

<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
    <property name="host" value="smtp.acme.com" />
    <property name="port" value="25" />
    <property name="javaMailProperties">
        <props>
            <prop key="mail.smtp.auth">true</prop>
        </props>
    </property>
</bean>

Los sockets RFCOMM no seguros establecen un canal de comunicación sin clave de enlace autenticada, por lo que estarán expuestos a ataques "man-in-the-middle". Para dispositivos Bluetooth 2.1, la clave de enlace se cifrará de forma obligatoria. Para dispositivos heredados (anteriores a Bluetooth 2.1), la clave de enlace no se cifrará.

Ejemplo 1: El código siguiente utiliza sockets RFCOMM que no son seguros:

    device.createInsecureRfcommSocketToServiceRecord(MY_UUID);

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.