De forma predeterminada, los temas de SNS no están cifrados en reposo. Esto potencialmente expone los datos a espectadores no autorizados.

Ejemplo 1: El siguiente ejemplo muestra una plantilla que no puede cifrar el tema de SNS al no definir un identificador de clave de AWS KMS.

AWSTemplateFormatVersion: 2010-09-09
Description: My SNS Topic
Resources:
  MySNSTopic:
    Type: AWS::SNS::Topic
    Properties:
      Subscription:
        - Endpoint: "MySNSEndpoint"
      Protocol: "sqs"
      TopicName: "SampleTopic"

La autenticación basada en Touch ID puede implementarse con los servicios de llaves mediante el almacenamiento de un elemento en las llaves y la configuración de un control de accesos que requiera que el usuario utilice su huella digital para recuperar el elemento más tarde. Las siguientes directivas pueden usarse para definir cómo se autenticará al usuario con su huella digital:

- kSecAccessControlUserPresence: restricción de acceso con Touch ID o un código de acceso. No es necesario que Touch ID esté disponible o registrado. Touch ID puede tener acceso al elemento aunque se agreguen o eliminen huellas digitales.
- kSecAccessControlTouchIDAny: restricción de acceso con Touch ID para las huellas digitales registradas. No se invalida el elemento si se agregan o eliminan huellas digitales.
- kSecAccessControlTouchIDCurrentSet: restricción de acceso con Touch ID para las huellas digitales registradas actualmente. Se invalida el elemento si se agregan o eliminan huellas digitales.

Cuando usa Touch ID, debe utilizar el atributo kSecAccessControlTouchIDCurrentSet para impedir que se agreguen o eliminen huellas digitales en el futuro.

Ejemplo 1: el siguiente código usa la restricción kSecAccessControlTouchIDAny que permite que el elemento de las llaves se desbloquee con cualquier huella digital que se registre en el futuro:

    ...
    let flags = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
        kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
        .TouchIDAny, 
        nil)

    var query = [String : AnyObject]()
    query[kSecClass as String] = kSecClassGenericPassword
    query[kSecAttrService as String] = service as AnyObject?
    query[kSecAttrAccount as String] = account as AnyObject?
    query[kSecValueData as String] = secret as AnyObject?
    ...
    query[kSecAttrAccessControl as String] = sacRef
    query[kSecUseOperationPrompt as String] = "Please authenticate using the Touch ID sensor."

    SecItemAdd(query as CFDictionary, nil)
    ...

Las vulnerabilidades de Cross-Site Scripting ocurren cuando una aplicación:

1. Permite que se incluya en un iframe.
2. No puede especificar la directiva de marcos a través del encabezado X-Frame-Options.
3. Utiliza protección deficiente, como lógica de reducción de marcos de JavaScript.

Las vulnerabilidades de Cross-Site Scripting con frecuencia forman la base de ataques de clickjacking que los atacantes pueden utilizar para realizar falsificación de solicitud entre sitios o ataques de suplantación de identidad.

Se genera una vulnerabilidad de Cross-site Request Forgery (CSRF) cuando:
1. Una aplicación web utiliza cookies de sesión.

2. La aplicación actúa en una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

De forma predeterminada, las páginas de Visualforce se representan con campos de formulario ocultos que sirven como tokens anti-CSRF. Estos tokens se incluyen en las solicitudes que se envían desde dentro de la página y el servidor verifica la validez de los tokens antes de ejecutar los métodos o comandos de acción correspondientes. Sin embargo, esta defensa integrada no se aplica a los métodos de acción de página ni a los constructores de controladores de página personalizados porque se ejecutan antes de que se generen los tokens anti-CSRF durante la carga de la página.

Ejemplo 1: La siguiente página de Visualforce declara un controlador personalizado MyAccountActions y un método de acción de página pageAction(). El método pageAction() se ejecuta al visitar la URL de la página y el servidor no comprueba los tokens anti-CSRF.

<apex:page controller="MyAccountActions" action="{!pageAction}">
    ...
</apex:page>

public class MyAccountActions {

    ...
    public void pageAction() {
        Map<String,String> reqParams = ApexPages.currentPage().getParameters();
        if (params.containsKey('id')) {
            Id id = reqParams.get('id');
            Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
            delete acct;
        }
    }
    ...
}

Un atacante podría configurar un sitio web malintencionado que contuviese el siguiente código:

<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>

Si un administrador de la página de Visualforce visita la página malintencionada mientras tiene una sesión activa en el sitio, borrará involuntariamente cuentas para el atacante.

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.



Un nonce es un valor aleatorio criptográfico que se envía con un mensaje para evitar ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que maneja la solicitud es vulnerable a un ataque CSRF (a menos que no cambie el estado de la aplicación). Esto significa que una aplicación web que utiliza cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permita a los administradores crear nuevas cuentas de la siguiente manera:

  var req = new XMLHttpRequest();
  req.open("POST", "/new_user", true);
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  req.send(body);

Un atacante podría configurar un sitio web malicioso que contuviese el siguiente código.

  var req = new XMLHttpRequest();
  req.open("POST", "http://www.example.com/new_user", true);
  body = addToPost(body, "attacker");
  body = addToPost(body, "haha");
  req.send(body);

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

Un nonce es un valor criptográfico aleatorio que se envía con un mensaje para prevenir ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que administra la solicitud será vulnerable a un ataque de CSRF (a menos que no modifique el estado de la aplicación). Esto implica que una aplicación web que utilice cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permite a los administradores crear cuentas nuevas enviando este formulario:

<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>

Un atacante podría establecer un sitio web con lo siguiente:

<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

Una vulnerabilidad Cross-Site Request Forgery (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de sesión.

2. La aplicación actúa en una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

Un nonce es un valor criptográfico aleatorio que se envía con un mensaje para prevenir ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que administra la solicitud será vulnerable a un ataque de CSRF (a menos que no modifique el estado de la aplicación). Esto implica que una aplicación web que utilice cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imaginemos una aplicación web que permite a los administradores crear cuentas nuevas de la siguiente forma:

De forma predeterminada, Play Framework agrega protección frente a CSRF, pero se puede deshabilitar de forma global o para determinadas rutas.

Ejemplo 1: La definición de ruta siguiente deshabilita la protección CSRF para el método de controlador buyItem.

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

Si un usuario engañado visita una página malintencionada mientras tiene una sesión activa en shop.com, comprará sin quererlo artículos para el atacante. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas determinadas por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el atacante acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.



Un nonce es un valor criptográfico aleatorio que se envía con un mensaje para prevenir ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que administra la solicitud será vulnerable a un ataque de CSRF (a menos que no modifique el estado de la aplicación). Esto implica que una aplicación web que utilice cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permite a los administradores crear cuentas nuevas enviando este formulario:

<form method="POST" action="/new_user" >
  Name of new user: <input type="text" name="username">
  Password for new user: <input type="password" name="user_passwd">
    <input type="submit" name="action" value="Create User">
</form>

Un atacante podría establecer un sitio web con lo siguiente:

<form method="POST" action="http://www.example.com/new_user">
  <input type="hidden" name="username" value="hacker">
  <input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
  document.usr_form.submit();
</script>

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

El secuestro WebSocket entre dominios tiene lugar cuando se engaña a un usuario para que visite un sitio malintencionado que establecerá una conexión WebSocket con un servidor de back-end legítimo. La solicitud HTTP inicial utilizada para preguntar al servidor acerca de la actualización al protocolo WebSocket es una solicitud HTTP normal, por lo que el explorador enviará cualquier cookie enlazada al dominio objetivo, incluidas las cookies de sesión. Si el servidor no puede verificar el encabezado Origin, permitirá que cualquier sitio malintencionado suplante al usuario y establezca una conexión WebSocket bidireccional sin que el usuario se dé cuenta.

Se produce scripting de zonas basado en archivos cuando se cumplen las siguientes condiciones:

1. Se carga un archivo que permite la ejecución de scripts en su aplicación.


2. Se asume que el script cargado tiene el mismo origen que la aplicación en ejecución (file://).

Cuando se cumplen estas dos condiciones, se posibilita una serie de ataques, especialmente si otras partes determinan la confianza basándose en si la información procede de su aplicación.

Ejemplo 1: El código siguiente utiliza el método UIWebView.loadRequest(_:) para cargar un archivo local:

...
NSURL *url = [[NSBundle mainBundle] URLForResource: filename withExtension:extension]; 
[webView loadRequest:[[NSURLRequest alloc] initWithURL:url]];
...

En el Example 1, el motor WebView considera que todo aquello cargado con UIWebView.loadRequest(_:) con una dirección URL que empiece por file:// procede del mismo archivo local con privilegios.

Un usuario malintencionado dispone de varias formas típicas de aprovechar una vulnerabilidad de scripting de zonas basado en archivos al cargar desde un archivo:

- El archivo local puede estar controlado por el atacante. Por ejemplo, el atacante puede enviar el archivo a su víctima, que lo almacena en la aplicación vulnerable (por ejemplo: una aplicación de almacenamiento en la nube).
- El archivo local puede ser manipulado por un usuario malintencionado, que puede inyectar scripts en el archivo. Esto dependerá de los permisos del archivo, de dónde se encuentra el archivo o de las condiciones de carrera donde un archivo se puede guardar y luego cargar (podría haber un margen de tiempo para la modificación).
- El archivo puede llamar a un recurso externo. Esto puede ocurrir cuando el archivo cargado recupera scripts de un recurso externo.
- El archivo cargado puede contener vulnerabilidades de Cross-Site Scripting. Si el archivo que se está cargando incluye código inyectado, dicho código podría ejecutarse en el contexto de su aplicación. No es necesario que el código inyectado sea de tipo JavaScript; el HTML inyectado también podría habilitar las desfiguraciones o los ataques por denegación de servicio.

Si el archivo controlado por el atacante se carga localmente con una dirección URL file://, la política del mismo origen permitirá que los scripts de este archivo accedan a cualquier otro archivo del mismo origen, lo que puede permitir que un atacante acceda a cualquier archivo local que contenga información confidencial.

Se produce scripting de zonas basado en archivos cuando se cumplen las siguientes condiciones:

1. Se carga un archivo que permite la ejecución de scripts en su aplicación.


2. Se asume que el script cargado tiene el mismo origen que la aplicación en ejecución (file://).

Cuando se cumplen estas dos condiciones, se posibilita una serie de ataques, especialmente si otras partes determinan la confianza basándose en si la información procede de su aplicación.

Ejemplo 1: El código siguiente utiliza el método UIWebView.loadRequest(_:) para cargar un archivo local:

...
let url = Bundle.main.url(forResource: filename, withExtension: extension)
self.webView!.load(URLRequest(url:url!))
...

En el Example 1, el motor WebView considera que todo aquello cargado con UIWebView.loadRequest(_:) con una dirección URL que empiece por file:// procede del mismo archivo local con privilegios.

Un usuario malintencionado dispone de varias formas típicas de aprovechar una vulnerabilidad de scripting de zonas basado en archivos al cargar desde un archivo:

- El archivo local puede estar controlado por el atacante. Por ejemplo, el atacante puede enviar el archivo a su víctima, que lo almacena en la aplicación vulnerable (por ejemplo: una aplicación de almacenamiento en la nube).
- El archivo local puede ser manipulado por un usuario malintencionado, que puede inyectar scripts en el archivo. Esto dependerá de los permisos del archivo, de dónde se encuentra el archivo o de las condiciones de carrera donde un archivo se puede guardar y luego cargar (podría haber un margen de tiempo para la modificación).
- El archivo puede llamar a un recurso externo. Esto puede ocurrir cuando el archivo cargado recupera scripts de un recurso externo.
- El archivo cargado puede contener vulnerabilidades de Cross-Site Scripting. Si el archivo que se está cargando incluye código inyectado, dicho código podría ejecutarse en el contexto de su aplicación. No es necesario que el código inyectado sea de tipo JavaScript; el HTML inyectado también podría habilitar las desfiguraciones o los ataques por denegación de servicio.

Si el archivo controlado por el atacante se carga localmente con una dirección URL file://, la política del mismo origen permitirá que los scripts de este archivo accedan a cualquier otro archivo del mismo origen, lo que puede permitir que un atacante acceda a cualquier archivo local que contenga información confidencial.

GraphiQL es una herramienta integrada en el navegador que aprovecha el mecanismo de introspección del esquema de GraphQL para proporcionar una interfaz gráfica para el desarrollo y las pruebas de la API de GraphQL. GraphiQL ayuda a los usuarios a explorar esquemas GraphQL, así como a redactar y ejecutar consultas de GraphQL.

No se recomienda permitir el acceso a GraphiQL en producción, ya que habilitar la introspección de los esquemas de GraphQL a través de GraphiQL puede representar un riesgo para su postura de seguridad general. Un atacante puede usar GraphiQL y la introspección para obtener detalles de la implementación de un esquema de GraphQL que le permitan lanzar un ataque más específico. Los esquemas de GraphQL pueden filtrar información, como campos utilizados internamente, descripciones y notas de obsolescencia, que es posible que no esté destinada al público general.

Ejemplo 1: El siguiente código inicializa un punto final de GraphQL.js con GraphiQL habilitado por defecto:

app.use('/graphql', graphqlHTTP({
    schema
}));

GraphiQL es una herramienta integrada en el navegador que aprovecha el mecanismo de introspección del esquema de GraphQL para proporcionar una interfaz gráfica para el desarrollo y las pruebas de la API de GraphQL. GraphiQL ayuda a los usuarios a explorar esquemas GraphQL, así como a redactar y ejecutar consultas de GraphQL.

No se recomienda permitir el acceso a GraphiQL en producción, ya que habilitar la introspección de los esquemas de GraphQL a través de GraphiQL puede representar un riesgo para su postura de seguridad general. Un atacante puede usar GraphiQL y la introspección para obtener detalles de la implementación de un esquema de GraphQL que le permitan lanzar un ataque más específico. Los esquemas de GraphQL pueden filtrar información, como campos utilizados internamente, descripciones y notas de obsolescencia, que no esté destinada al público general.

Ejemplo 1: El siguiente código inicializa un punto final de GraphQL con GraphiQL habilitado:

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
  'graphql',
  schema = schema,
  graphiql = True
))

La capacidad de introspección de GraphQL permite que cualquier persona consulte un servidor de GraphQL para obtener información sobre el esquema actual. Una parte interesada puede emitir consultas de introspección de GraphQL para recuperar una vista completa de las operaciones, los tipos de datos, los campos y la documentación disponibles de un esquema.

La introspección de GraphQL ofrece una importante utilidad en el contexto del desarrollo y el intercambio de información sobre las API de GraphQL. La introspección es una potente función de GraphQL que puede facilitar la integración con varias herramientas. Por ejemplo, un IDE puede aprovechar la introspección del esquema para proporcionar funciones mejoradas que permitan desarrollar y probar las API de GraphQL.

Sin embargo, permitir que cualquiera consulte sus esquemas de GraphQL en producción puede representar un riesgo para su postura de seguridad general. Un atacante puede usar la introspección para obtener detalles de la implementación de un esquema de GraphQL que le permitan lanzar un ataque más específico. Los esquemas de GraphQL pueden filtrar información, como campos utilizados internamente, descripciones y notas de obsolescencia, que es posible que no esté destinada al público general.

Ejemplo 1: El siguiente código inicializa un punto final de Hot Chocolate GraphQL con la introspección de esquema habilitada por defecto:

    services
        .AddGraphQLServer()
        .AddQueryType<Query>()
        .AddMutationType<Mutation>();
    

La capacidad de introspección de GraphQL permite que cualquier persona consulte un servidor de GraphQL para obtener información sobre el esquema actual. Una parte interesada puede emitir consultas de introspección de GraphQL para recuperar una vista completa de las operaciones, los tipos de datos, los campos y la documentación disponibles de un esquema.

La introspección de GraphQL ofrece una importante utilidad en el contexto del desarrollo y el intercambio de información sobre las API de GraphQL. La introspección es una potente función de GraphQL que puede facilitar la integración con varias herramientas. Por ejemplo, un IDE puede aprovechar la introspección del esquema para proporcionar funciones mejoradas que permitan desarrollar y probar las API de GraphQL.

Sin embargo, permitir que cualquiera consulte sus esquemas de GraphQL en producción puede representar un riesgo para su postura de seguridad general. Un atacante puede usar la introspección para obtener detalles de la implementación de un esquema de GraphQL que le permitan lanzar un ataque más específico. Los esquemas de GraphQL pueden filtrar información, como campos utilizados internamente, descripciones y notas de obsolescencia, que es posible que no esté destinada al público general.

Ejemplo 1: El siguiente código inicializa un punto final de GraphQL con la introspección de esquema habilitada de forma predeterminada:

app.use('/graphql', graphqlHTTP({
    schema
}));

La capacidad de introspección de GraphQL permite que cualquier persona consulte un servidor de GraphQL para obtener información sobre el esquema actual. Cualquier parte interesada puede emitir consultas de introspección de GraphQL para recuperar una vista completa de las operaciones, los tipos de datos, los campos y la documentación disponibles de un esquema.

La introspección de GraphQL ofrece una importante utilidad en el contexto del desarrollo y el intercambio de información sobre las API de GraphQL. La introspección es una potente función de GraphQL que puede facilitar la integración con varias herramientas. Por ejemplo, un IDE puede aprovechar la introspección del esquema para proporcionar funciones mejoradas que permitan desarrollar y probar las API de GraphQL.

Sin embargo, permitir que cualquiera consulte sus esquemas de GraphQL en producción puede representar un riesgo para su postura de seguridad general. Un atacante puede usar la introspección para obtener detalles de la implementación de un esquema de GraphQL que le permitan lanzar un ataque más específico. Los esquemas de GraphQL pueden filtrar información, como campos utilizados internamente, descripciones y notas de obsolescencia, que no esté destinada al público general.

Ejemplo 1: El siguiente código inicializa un punto final de GraphQL con la introspección de esquema habilitada de forma predeterminada:

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
  'graphql',
  schema = schema
))

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:

  HtmlInputHidden hidden = new HtmlInputHidden();

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.

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: Una etiqueta <input> del tipo hidden indica el uso de un campo oculto.

<input type="hidden">

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.