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("*");

Los errores de control del clúster de Hadoop se producen cuando:

- Los datos entran en un programa desde un origen que no es de confianza.

- Los componentes centrales del clúster de Hadoop como, por ejemplo, NameNode, DataNode o JobTraker consumen los datos para cambiar el estado del clúster.

Los clústeres de Hadoop son un entorno hostil. Si no se establecen correctamente las configuraciones de seguridad que protegen frente al acceso no autorizado a los nodos del clúster, es posible que se produzca un ataque. Esto conlleva la posibilidad de que se manipule cualquier dato proporcionado por el clúster de Hadoop.

Ejemplo 1: el siguiente código muestra un envío de Job en una aplicación de cliente típica que obtiene entradas de la línea de comandos en un equipo maestro de clúster de Hadoop:

  public static void run(String args[]) throws IOException {

    String path = "/path/to/a/file";
    DFSclient client = new DFSClient(arg[1], new Configuration());
    ClientProtocol nNode = client.getNameNode();

    /* This sets the ownership of a file pointed by the path to a user identified
     * by command line arguments.
     */
    nNode.setOwner(path, args[2], args[3]);
    ...
  }

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.

Las vulnerabilidades de inspección de montón se producen cuando los datos confidenciales como, por ejemplo, una contraseña o una clave de cifrado, se pueden mostrar a un usuario malintencionado porque no se han eliminado de la memoria.

La función realloc() se utiliza normalmente para aumentar el tamaño de un bloque de memoria asignada. Esta operación requiere a menudo la copia de contenido del bloque de memoria antiguo a uno nuevo más grande. Esta operación deja intacto el contenido del bloque original, pero inaccesible para el programa, lo que impide que este pueda limpiar datos confidenciales de la memoria. Si un usuario malintencionado consigue examinar posteriormente el contenido del volcado de la memoria, los datos confidenciales podrían mostrarse.

Ejemplo: el siguiente código llama a realloc() en un búfer que contiene datos confidenciales:

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

Se intentan limpiar los datos confidenciales de la memoria, pero se utiliza realloc(), por lo que una copia de los mismos aún puede estar visible en la memoria asignada originalmente para plaintext_buffer.

Las vulnerabilidades de inspección de montón se producen cuando los datos confidenciales como, por ejemplo, una contraseña o una clave de cifrado, se pueden mostrar a un usuario malintencionado porque no se han eliminado de la memoria.

La función VirtualLock está diseñada para bloquear páginas en la memoria a fin de impedir que se transmitan a un disco. Sin embargo, en Windows 95/98/ME, la función solo se implementa como código stub y no tiene ningún efecto.

A menudo, los programadores confían en el contenido de los campos ocultos, suponiendo que los usuarios no podrán verlos ni manipular su contenido. Los atacantes pueden burlar estas suposiciones. Examinan los valores escritos en los campos ocultos y los alteran o reemplazan si contenido por datos de ataque.

Ejemplo:

  Hidden hidden = new Hidden(element);

Si los campos ocultos contienen información confidencial, esta se incluirá en la caché al igual que el resto de la página. Esto provoca que la información confidencial se almacene en la caché del explorador sin que el usuario lo sepa.

El encabezado X-XSS-Protection normalmente está habilitado de forma predeterminada en los navegadores modernos. Cuando el valor del encabezado se establece en false (0), se deshabilita la protección frente a ataques Cross-Site Scripting.

El encabezado se puede establecer en varios lugares y se debe comprobar que no presente errores de configuración ni manipulaciones malintencionadas.

Ejemplo: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar la protección XSS:

	<http auto-config="true">
        ...
        <headers>
            ...
            <xss-protection xss-protection-enabled="false" />
        </headers>
	</http>

Una de las características de HTML5 es la capacidad para almacenar datos en una base de datos SQL de cliente. La parte más importante de la información necesaria para iniciar la escritura y lectura de la base de datos es su nombre. Por tanto, es fundamental que el nombre de la base de datos sea una cadena única diferente para cada usuario. Si el nombre de la base de datos resulta fácil de deducir, terceros no autorizados, como otros usuarios, podrían robar datos confidenciales o corromper las entradas de la base de datos.
Ejemplo: El código siguiente utiliza un nombre de base de datos fácil de deducir:

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

Este código se ejecutará con éxito, pero cualquiera que pueda adivinar que el nombre de la base de datos es 'mydb' puede acceder a él.

HTML5 proporciona una nueva función para realizar validaciones sencillas de los campos de formulario de entrada. Se puede especificar si un campo de formulario de entrada es obligatorio mediante el atributo required. Al especificar el tipo de campo, nos aseguramos de que la entrada se comprueba según su tipo. Se puede incluso suministrar un atributo pattern personalizable que compruebe la entrada con una expresión regular. Sin embargo, esta validación se desactiva cuando se añade un atributo novalidate en una etiqueta de formulario y un atributo formnovalidate en una etiqueta de entrada de envío.

Ejemplo 1: En el siguiente ejemplo, se desactiva la validación de formularios mediante el atributo novalidate.

      <form action="demo_form.asp" novalidate="novalidate">
        E-mail: <input type="email" name="user_email" />
        <input type="submit" />
      </form>

Ejemplo 2: En el siguiente ejemplo, se desactiva la validación de formularios mediante el atributo formnovalidate.

      <form action="demo_form.asp" >
        E-mail: <input type="email" name="user_email" />
        <input type="submit" formnovalidate="formnovalidate"/>
      </form>

Los formularios HTML sin validación activada resultan más difíciles de utilizar y pueden exponer al servidor a muchos tipos de ataque. Las entradas no comprobadas son la causa principal de vulnerabilidades en secuencias entre sitios, control de procesos e inserción de SQL.

Se ha vuelto importante defender la privacidad de los datos de un documento web determinado debido a la existencia de explotaciones de canal lateral que resultan de vulnerabilidades como Spectre y Meltdown. La Política de apertura de orígenes cruzados (COOP) se creó para ayudar a prevenir la exposición de información confidencial debido a ataques de canal lateral. Específicamente, la COOP puede forzar el aislamiento del grupo del contexto de navegación de un documento con respecto a otros documentos externos, como ventanas emergentes.

Ejemplo 1: El siguiente código muestra una configuración COOP no segura de 'unsafe-none' en el marco Django. Esto podría permitir que un documento externo acceda a los datos privados del grupo del contexto de navegación de un documento fuente debido a un ataque de canal lateral.

SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'

El ataque de reconocimiento MIME es la práctica de inspeccionar el contenido de una secuencia de bytes con el fin de deducir el formato de archivo de los datos que contiene.

Si el ataque de reconocimiento MIME no se deshabilita de forma explícita, los atacantes pueden manipular algunos exploradores para que interpreten los datos de una manera no deseada y se permitan así ataques Cross-Site Scripting. Para cada página que contenga contenido controlable por el usuario, debe utilizar el encabezado HTTP X-Content-Type-Options: nosniff.

Ejemplo: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar la protección contra reconocimiento MIME:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

La directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite que los desarrolladores establezcan desde qué dominios el sitio puede cargar contenido o inicializar conexiones cuando se procesa en el explorador web. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques de Cross-Site Scripting, el secuestro de clics (clickjacking), el acceso de origen cruzado y ataques similares, por encima de la validación de entradas y la comprobación de listas de permitidos en el código. Sin embargo, un encabezado configurado de manera incorrecta no puede proporcionar esta capa de seguridad adicional. La directiva se define con la ayuda de 15 directivas, incluidas 8 que controlan el acceso a recursos, a saber: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

Cada una de estas toma una lista de orígenes como un valor que especifica dominios a los que el sitio puede acceder para una función abarcada por esa directiva. Los desarrolladores pueden utilizar el carácter comodín * para indicar todo o parte del origen. Ninguna de las directivas es obligatoria. Los exploradores permitirán todos los orígenes para una directiva no incluida en la lista o derivarán su valor de una directiva default-src opcional. Además, la especificación de este encabezado ha evolucionado con el tiempo. Se implementó como X-Content-Security-Policy en Firefox hasta la versión 23 y en IE hasta la versión 10, y se implementó como X-Webkit-CSP en Chrome hasta la versión 25. Ambos nombres han quedado en desuso en favor del nombre Content Security Policy que ahora es estándar. Dada la cantidad de directivas, dos nombres alternativos reemplazados y la forma en la que se tratan varias repeticiones del mismo encabezado y las directivas repetidas en un solo encabezado, hay una alta probabilidad de que los desarrolladores configuren incorrectamente este encabezado.

Tenga en cuenta los siguientes escenarios de configuración incorrecta:

- Las directivas con unsafe-inline o unsafe-eval anulan la finalidad de la CSP.
- La directiva script-src se define pero no se configura ningún script nonce.
- frame-src se define pero no se configura ningún sandbox.
- Se permiten varias instancias de este encabezado en la misma respuesta. Un equipo de desarrollo y un equipo de seguridad pueden definir juntos un encabezado, pero uno podría usar uno de los nombres reemplazados. Aunque los encabezados reemplazados se respetan si un encabezado con el nombre más reciente (es decir, la directiva de seguridad de contenido) no está presente, se ignoran si hay una directiva con nombre de encabezado de seguridad de contenido presente. Las versiones anteriores solo comprenden los nombres reemplazados y, por lo tanto, para lograr el soporte deseado, es fundamental que la respuesta incluya una directiva idéntica con los tres nombres.
- Si una directiva está repetida dentro de la misma instancia del encabezado, se ignoran todas las repeticiones posteriores.

Ejemplo 1: La siguiente configuración django-csp utiliza las directivas inseguras unsafe-inline y unsafe-eval para permitir evaluación de código y scripts en la línea:

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

La directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite a los desarrolladores establecer los dominios en los que el sitio puede cargar contenido o con los que puede inicializar conexiones cuando se procesa en el explorador web. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques Cross-Site Scripting, el secuestro de clics (clickjacking), el acceso de origen cruzado y similares, por encima de la validación de entrada y la comprobación de listas de permitidos en el código.

Spring Security y otros marcos de trabajo no agregan encabezados de directiva de seguridad de contenido de forma predeterminada. El autor de la aplicación web debe declarar las directivas de seguridad que se deben aplicar o supervisar los recursos protegidos para poder aprovechar esta capa adicional de seguridad.

Permitir que un sitio web se agregue a un marco puede ser un problema de seguridad. Por ejemplo, esto puede conducir a vulnerabilidades de secuestro de clics (clickjacking) o permitir las comunicaciones no deseadas entre marcos.

De forma predeterminada, los marcos de trabajo como Spring Security incluyen el encabezado X-Frame-Options para indicar al explorador si la aplicación debe enmarcarse o no. Si se deshabilita o no se establece este encabezado, se pueden presentar vulnerabilidades entre marcos.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar el encabezado X-Frame-Options:

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

La directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite a los desarrolladores especificar en el explorador comportamientos permitidos relacionados con la seguridad, como una lista de ubicaciones permitidas desde las que se puede recuperar contenido. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques Cross-Site Scripting, el secuestro de clics (clickjacking), el acceso de origen cruzado y similares, por encima de la validación de entrada y la comprobación de listas de permitidos en el código. Sin embargo, un encabezado configurado de manera incorrecta no puede proporcionar esta capa de seguridad adicional. La directiva se define con la ayuda de 15 directivas que incluyen ocho que controlan el acceso a recursos: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. Estas ocho directivas toman una lista de orígenes como un valor que especifica dominios a los que el sitio puede acceder en relación con una función contemplada en esa directiva. Los desarrolladores pueden utilizar el carácter comodín * para indicar la totalidad o una parte del origen. Otras palabras clave de lista de orígenes, como 'unsafe-inline' y 'unsafe-eval', permiten tener un control más granular de la ejecución de scripts, pero son potencialmente dañinas. Ninguna de las directivas es obligatoria. Los exploradores bien permiten todos los orígenes de una directiva no incluida en la lista, o bien obtienen su valor de una directiva default-src opcional. Además, la especificación de este encabezado ha evolucionado con el tiempo. Se implementó como X-Content-Security-Policy en Firefox hasta la versión 23 y en IE hasta la versión 10, y se implementó como X-Webkit-CSP en Chrome hasta la versión 25. Estos dos nombres han quedado en desuso en favor del nombre Content Security Policy, que ahora es estándar. Dada la cantidad de directivas, dos nombres alternativos reemplazados y la forma en la que se tratan varias repeticiones del mismo encabezado y las directivas repetidas en un solo encabezado, hay una alta probabilidad de que los desarrolladores configuren este encabezado incorrectamente.

Ejemplo 1: El siguiente código define una directiva default-src demasiado insegura y permisiva:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

Antes de HTML5, los exploradores web aplicaban la directiva de mismo origen, la cual garantiza que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. HTML5 permite que JavaScript acceda a datos de diferentes dominios si se define un nuevo encabezado de HTTP llamado Access-Control-Allow-Origin. Con este encabezado, un servidor web define los dominios que pueden acceder a su dominio mediante solicitudes de origen cruzado. Sin embargo, tenga cuidado al definir el encabezado, ya que una directiva CORS demasiado laxa puede permitir que una aplicación malintencionada se comunique con la aplicación víctima de forma inapropiada y se produzcan ataques de suplantación, robo de datos y retransmisión, entre otros.

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.

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

Utilizar * como el valor del encabezado Access-Control-Allow-Origin indica que los datos de la aplicación son accesibles para JavaScript que se ejecuta en cualquier dominio.