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

Una de las nuevas características de HTML5 son los mensajes entre documentos. Esta función permite que las secuencias devuelvan mensajes en otras ventanas. La API correspondiente permite al usuario especificar el origen de la ventana de destino. No obstante, se debe prestar especial atención a la hora de especificar el origen de destino, dado que un origen de destino demasiado permisivo hará posible que un script malicioso pueda comunicarse con la ventana en cuestión de forma inapropiada, lo que permitiría la suplantación de identidad, el robo de datos, la retransmisión y otras formas de ataque.

Ejemplo 1: el siguiente ejemplo utiliza un carácter comodín para especificar mediante programación el origen de destino del mensaje que se va a enviar.

    WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
    webview.postWebMessage(message, Uri.parse("*"));

Utilizando el * como el valor del origen de destino, se indica que la secuencia envía un mensaje a una ventana independientemente de su origen.

De forma predeterminada, los exploradores no envían el encabezado de referencia con las solicitudes originadas desde HTTPS a vínculos HTTP sin cifrar. Sin embargo, cuando el destino de una solicitud también es HTTPS, se envía el encabezado independientemente del origen. Un desarrollador puede dejar información confidencial en las URL, las cuales se exponen a sitios de terceros mediante el encabezado de referencia. El encabezado Referrer-Policy se introduce para controlar el comportamiento del explorador en relación con el encabezado de referencia. La opción Unsafe-URL elimina todas las restricciones y envía el encabezado de referencia con cada solicitud.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar la directiva de referencia segura predeterminada:

	<http auto-config="true">
        ...
        <headers>
            ...
            <referrer-policy policy="unsafe-url"/>
        </headers>
	</http>

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.

El encabezado Content-Security-Policy-Report-Only brinda la capacidad para que los administradores y los autores de aplicaciones web supervisen las directivas de seguridad, en lugar de aplicarlas. Generalmente, este encabezado se utiliza mientras se desarrollan o se prueban directivas de seguridad para un sitio. Cuando se considera que una directiva es efectiva, es posible utilizar el encabezado Content-Security-Policy para aplicarla.

Ejemplo 1: El siguiente código establece una directiva de seguridad de contenido en el modo Report-Only:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
        </headers>
    </http>

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.

Los mecanismos de autenticación y autorización de una aplicación se pueden omitir con la manipulación del verbo HTTP cuando:
1) Se usa un control de seguridad que enumera los verbos HTTP.
2) El control de seguridad no bloquea los verbos que no figuran en la lista.
3) La aplicación actualiza su estado en función de las solicitudes GET u otros verbos HTTP arbitrarios.



La mayoría de las implementaciones de Java EE permiten métodos HTTP que no se enumeran explícitamente en la configuración. Por ejemplo, la siguiente restricción de seguridad se aplica al método HTTP GET pero no a otros verbos HTTP:

    <security-constraint>
        <display-name>Admin Constraint</display-name>
        <web-resource-collection>
            <web-resource-name>Admin Area</web-resource-name>
            <url-pattern>/pages/index.jsp</url-pattern>
            <url-pattern>/admin/*.do</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>only admin</description>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

Dado que los verbos como HEAD no se definen explícitamente en una etiqueta <http-method> en esta configuración, es posible ejercer la funcionalidad administrativa sustituyendo las solicitudes GET o POST por solicitudes HEAD. Para que las solicitudes HEAD ejerzan funcionalidad administrativa, se debe cumplir la condición 3: la aplicación debe ejecutar comandos basados en verbos distintos de POST. Algunos servidores web/de aplicaciones aceptarán verbos HTTP no estándar arbitrarios y responderán como si se les hubiera dado una solicitud GET. Si ese es el caso, un atacante podría ver páginas administrativas usando un verbo arbitrario en una solicitud.

Por ejemplo, las solicitudes GET de cliente normalmente son así:

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com

En un ataque de manipulación de verbos HTTP, un atacante sustituiría GET por algo como FOO.

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com

En esencia, esta vulnerabilidad es el resultado de un intento de crear una lista de denegación, una directiva que especifica lo que los usuarios no pueden hacer. Las listas denegación rara vez logran el efecto deseado.

Las funciones que buscan caracteres dentro de un búfer pueden devolver un puntero fuera de los límites del búfer proporcionado en cualquiera de las siguientes circunstancias:

- Un usuario controla el contenido del búfer que se va a buscar.

- Un usuario controla el valor que se va a buscar.

Ejemplo 1: El siguiente programa breve utiliza un argumento de línea de comandos que no es de confianza como búfer de búsqueda en una llamada a rawmemchr().

int main(int argc, char** argv) {
  char* ret = rawmemchr(argv[0], 'x');
  printf("%s\n", ret);
}

El programa está diseñado para imprimir una subcadena de argv[0], aunque es posible que acabe imprimiendo una parte de la memoria anterior a argv[0].

Este problema es similar a un error de finalización de cadena, en el que el programador utiliza una matriz de caracteres para incluir un terminador null.

A esta clase se le ha dado la anotación de Inmutable, desde el paquete de anotaciones de JCIP. Sin embargo, uno de los campos mutables de la clase presenta un método de mutación al que se llama desde fuera del constructor y el destructor.

Ejemplo 1: el siguiente código para una clase final inmutable declara un Set como private y final y, a continuación, crea erróneamente un método que modifica el Set.

@Immutable
public final class ThreeStooges {
  private final Set stooges = new HashSet>();
  ...

  public void addStooge(String name) {
    stooges.add(name);
  }
  ...
}

A esta clase se le ha dado la anotación de Immutable, desde el paquete de anotaciones de JCIP. Un campo no final infringe la inmutabilidad de la clase al permitir la modificación del valor.

Ejemplo 1: el siguiente código de una clase inmutable declara de forma incorrecta un campo public y no final.

@Immutable
public class ImmutableInteger {
public int value;

}

A esta clase se le ha dado la anotación de Inmutable, desde el paquete de anotaciones de JCIP. Un campo público de tipo mutable permite que el código externo a la clase modifique el contenido e infrinja la inmutabilidad de la clase.

Ejemplo 1: el código siguiente para una clase final inmutable declara erróneamente un Set como public y final.

@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}

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.

Los errores de optimización del compilador se producen cuando:

1. Los datos secretos se almacenan en la memoria.

2. Los datos secretos se limpian de la memoria sobrescribiendo su contenido.



3. El código de origen se compila mediante un compilador de optimización, que identifica y elimina la función que sobrescribe el contenido como un almacén no alcanzado porque la memoria no se utiliza posteriormente.
Ejemplo 1: El siguiente código lee una contraseña del usuario, utiliza esta para conectarse a un gran sistema (mainframe) back-end y, a continuación, intenta limpiar la contraseña de la memoria mediante memset().

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

El código del ejemplo se comporta correctamente si se ejecuta de forma literal, pero si este se compila mediante un compilador de optimización como, por ejemplo, Microsoft Visual C++(R) .NET o GCC 3.x, se eliminará la llamada a memset() como almacén no alcanzado porque no se ha utilizado el búfer pwd una vez sobrescrito su valor [2]. Como el búfer pwd contiene un valor confidencial, es posible que la aplicación sea vulnerable a un ataque si se dejan datos en la memoria. Si los usuarios malintencionados pueden acceder a la región correcta de la memoria, es posible que usen la contraseña recuperada para obtener acceso al sistema.

Es práctica habitual sobrescribir datos confidenciales manipulados en la memoria como, por ejemplo, contraseñas o claves criptográficas, para impedir que los usuarios malintencionados averigüen secretos del sistema. Sin embargo, con la introducción de los compiladores de optimización, los programas no siempre se comportan como podría sugerir solo su código fuente. En el ejemplo, el compilador interpreta la llamada a memset() como código no alcanzado porque la memoria en la que se está escribiendo no se utiliza posteriormente, a pesar del hecho de que hay claramente una motivación de seguridad para que se realice la operación. El problema aquí es que muchos compiladores y, de hecho, muchos lenguajes de programación, no tienen en cuenta esta u otras inquietudes acerca de la seguridad en su esfuerzo por mejorar la eficacia.

Por lo general, los usuarios malintencionados explotan este tipo de vulnerabilidad mediante un mecanismo de volcado del núcleo o de tiempo de ejecución para acceder a la memoria utilizada por una aplicación específica y recuperar la información secreta. Una vez que el usuario malintencionado tiene acceso a la información secreta, es relativamente sencillo explotar aún más el sistema y poner en peligro posiblemente otros recursos con los que interactúa la aplicación.

Si la comprobación de un límite de matriz implica computar un puntero no válido y luego determinar que el puntero está fuera de los límites, algunos compiladores optimizarán la salida, suponiendo que el programador nunca haya creado de forma intencionada un puntero no válido.

Ejemplo 1:

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

La operación buf + len es mayor que 2^32, de modo que el valor resultante es menor que buf. Como el desbordamiento aritmético en un puntero no es un comportamiento definido, algunos compiladores asumirán buf + len >= buf y optimizarán la comprobación de encapsulación. El resultado de esta optimización es que el código que sigue a este bloque podría ser vulnerable al buffer overflow.

La aplicación de Django expone la vista de serve de la aplicación static files que no está diseñada para implementarse en un entorno de producción. Según la documentación de Django:

"Las herramientas static files están diseñadas en su mayoría para ayudar a obtener archivos estáticos correctamente implementados en la producción. En general, esto significa un servidor de archivo estático, dedicado e independiente que significa mucha sobrecarga al implementarlo de forma local. Por lo tanto, la aplicación de archivos estáticos se envía con una vista auxiliar rápida y modificada que puede utilizar para facilitar archivos de forma local en el desarrollo.

Esta vista funcionará únicamente si DEBUG está definido como True.

Eso se debe a que esta vista es sumamente ineficiente y probablemente insegura. Esto solo está destinado al desarrollo local y nunca se debe utilizar el producción".

Los recursos de aplicaciones que contienen información confidencial o que proporcionan funcionalidad con privilegios generalmente tienen mayor riesgo de vulnerabilidad. Durante la fase de reconocimiento, un usuario malintencionado intentará descubrir esos archivos y directorios. El uso de esquemas de nombres predecibles para esos recursos facilita que el usuario malintencionado los localice. Todos los recursos de aplicaciones que tratan funciones confidenciales como autenticación, tareas administrativas o administración de información privada se deben proteger lo suficiente contra la detección.

Ejemplo 1: En el siguiente ejemplo, la aplicación admin se implementa en una dirección URL predecible:

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

Los recursos responsables de almacenar datos se deben separar de aquellos que implementan funcionalidad de las aplicaciones. Los programadores deben tener precaución al crear recursos temporales o de respaldo.