La encapsulación consiste en crear límites fuertes. En un explorador web esto puede suponer la seguridad de que tu codificación móvil no se vea comprometido por otro código móvil. En el servidor puede significar la diferenciación entre los datos validados y los que no lo están, entre los datos de un usuario y los de otro, o entre los diferentes usuarios, los datos que pueden ver y los que no.
HtmlInputHidden hidden = new HtmlInputHidden();
Hidden hidden = new Hidden(element);
<input>
del tipo hidden
indica el uso de un campo oculto.
<input type="hidden">
...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...
'mydb'
puede acceder a él.script-src
, img-src
, object-src
, style_src
, font-src
, media-src
, frame-src
, connect-src
.*
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.unsafe-inline
o unsafe-eval
anulan la finalidad de la CSP.script-src
se define pero no se configura ningún script nonce
.frame-src
se define pero no se configura ningún sandbox
.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_CLASSES = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...
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.X-Frame-Options
:
<http auto-config="true">
...
<headers>
...
<frame-options disabled="true"/>
</headers>
</http>
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.default-src
demasiado insegura y permisiva:
<http auto-config="true">
...
<headers>
...
<content-security-policy policy-directives="default-src '*'" />
</headers>
</http>
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.*-src
con una directiva demasiado permisiva como *
Ejemplo 1: La siguiente configuración django-csp
define una directiva demasiado permisiva e insegura default-src
:
...
MIDDLEWARE_CLASSES = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...
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.
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
*
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.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.
<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>
*
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.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.
<?php
header('Access-Control-Allow-Origin: *');
?>
*
como el valor del encabezado de Access-Control-Allow-Origin
indica que el JavaScript que se está ejecutando en cualquier dominio puede acceder a los datos de la aplicación.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.
response.addHeader("Access-Control-Allow-Origin", "*")
*
como el valor del encabezado de Access-Control-Allow-Origin
indica que el JavaScript que se ejecuta en cualquier dominio puede acceder a los datos de la aplicación.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.
play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}
*
como valor del encabezado de Access-Control-Allow-Origin
indica que el JavaScript que se ejecute en cualquier dominio podrá acceder a los datos de la aplicación.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.
Response.AddHeader "Access-Control-Allow-Origin", "*"
*
como el valor del encabezado de Access-Control-Allow-Origin
indica que el JavaScript que se está ejecutando en cualquier dominio puede acceder a los datos de la aplicación.