permissions := strconv.Atoi(os.Getenv("filePermissions"));
fMode := os.FileMode(permissions)
os.chmod(filePath, fMode);
...
String permissionMask = System.getProperty("defaultFileMask");
Path filePath = userFile.toPath();
...
Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
Files.setPosixFilePermissions(filePath, perms);
...
$rName = $_GET['publicReport'];
chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...
publicReport
como, por ejemplo, "../../localuser/public_html/.htpasswd
", la aplicación hará que el archivo especificado sea legible para el usuario malintencionado.
...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...
permissions = os.getenv("filePermissions");
os.chmod(filePath, permissions);
...
...
rName = req['publicReport']
File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...
publicReport
como, por ejemplo, "../../localuser/public_html/.htpasswd
", la aplicación hará que el archivo especificado sea legible para el usuario malintencionado.
...
mask = config_params['perms']
File.chmod(filename, mask)
...
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.
flash.system.Security.allowDomain("*");
*
como el argumento de allowDomain()
indica que otras aplicaciones SWF pueden tener acceso a los datos desde cualquier dominio.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.
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
*
como el valor del atributo headers
indica que cualquier encabezado se enviará a través de dominios.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: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 url:String = String(params["url"]);
flash.system.Security.loadPolicyFile(url);
...
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var domain:String = String(params["domain"]);
flash.system.Security.allowDomain(domain);
...
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.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("*");
NameNode
, DataNode
o JobTraker
consumen los datos para cambiar el estado del clúster.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]);
...
}
script
.
<script src="http://www.example.com/js/fancyWidget.js"></script>
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.realloc()
para cambiar el tamaño de los búferes que almacenan información confidencial. Es posible que la función deje una copia de la información confidencial en la memoria, donde no se puede sobrescribir.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.realloc()
en un búfer que contiene datos confidenciales:
plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);
realloc()
, por lo que una copia de los mismos aún puede estar visible en la memoria asignada originalmente para plaintext_buffer
.VirtualLock
para bloquear páginas que contengan datos confidenciales. No siempre se implementa 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.
HtmlInputHidden hidden = new HtmlInputHidden();
Hidden hidden = new Hidden(element);
<input>
del tipo hidden
indica el uso de un campo oculto.
<input type="hidden">
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.X-XSS-Protection
se encuentra deshabilitado de forma explícita, lo que puede aumentar el riesgo de ataques Cross-Site Scripting.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.
<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
X-XSS-Protection
está explícitamente deshabilitado, lo que puede aumentar el riesgo de ataques de scripts entre sitios.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.X-XSS-Protection
está explícitamente deshabilitado, lo que puede aumentar el riesgo de ataques de scripts entre sitios.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.
...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...
'mydb'
puede acceder a él.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.novalidate
.Ejemplo 2: En el siguiente ejemplo, se desactiva la validación de formularios mediante el atributo
<form action="demo_form.asp" novalidate="novalidate">
E-mail: <input type="email" name="user_email" />
<input type="submit" />
</form>
formnovalidate
.
<form action="demo_form.asp" >
E-mail: <input type="email" name="user_email" />
<input type="submit" formnovalidate="formnovalidate"/>
</form>
SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'
Application_BeginRequest
está vacío o no incluye una llamada a una función para establecer X-Content-Type-Options
en nosniff
o intenta quitar el encabezadoX-Content-Type-Options: nosniff
.X-Content-Type-Options
en nosniff
.X-Content-Type-Options: nosniff
en cada página que podría incluir contenido controlable por el usuario.net.http.DetectContentType()
para determinar el tipo de contenido de la respuesta:
...
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
content_type := DetectContentType(body)
...
X-Content-Type-Options
en nosniff
ni deshabilita explícitamente este encabezado de seguridad.X-Content-Type-Options: nosniff
.
<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
X-Content-Type-Options
como nosniff
ni deshabilita explícitamente este encabezado de seguridad.X-Content-Type-Options: nosniff
.X-Content-Type-Options
como nosniff
ni deshabilita explícitamente este encabezado de seguridad.X-Content-Type-Options: nosniff
.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 = (
...
'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 = (
...
'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.
Response.AppendHeader("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.
<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.