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.

X-XSS-Protection es un encabezado HTTP que Microsoft ha incluido, y que han adoptado otros exploradores. De este modo se pretendía evitar que los ataques Cross-Site Scripting tuvieran éxito, pero, de forma involuntaria, expuso una vulnerabilidad que hacía que sitios web seguros dejaran de serlo[1]. Por este motivo, no se debe usar en versiones anteriores de Internet Explorer y se debe deshabilitar configurando el encabezado como 0.

Ejemplo 1: Esta opción configura el software intermedio Helmet de forma incorrecta en una aplicación Express para habilitar el ajuste en todas las versiones de Internet Explorer:

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

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

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