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 "../../localuser/public_html/.htpasswd
", o aplicativo tornará o arquivo especificado como legível para o invasor.
...
$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 "../../localuser/public_html/.htpasswd
", o aplicativo tornará o arquivo especificado como legível para o invasor.
...
mask = config_params['perms']
File.chmod(filename, mask)
...
crossdomain.xml
. No entanto, é necessário tomar precauções ao alterar as configurações, pois uma política entre domínios excessivamente permissiva permitirá que um aplicativo mal-intencionado se comunique com o aplicativo vítima de modo impróprio, resultando em falsificação, roubo de dados, retransmissão e outros ataques.
flash.system.Security.allowDomain("*");
*
como argumento para allowDomain()
indica que os dados do aplicativo estão acessíveis a outros aplicativos SWF de qualquer domínio.crossdomain.xml
. A partir do Flash Player 9.0.124.0, a Adobe também introduziu a capacidade de definir quais cabeçalhos personalizados o Flash Player pode enviar entre domínios. No entanto, é preciso ter cuidado ao definir essas configurações porque uma política de cabeçalhos personalizados excessivamente permissiva, quando aplicada junto com a política de vários domínios excessivamente permissiva, permitirá que um aplicativo mal-intencionado envie cabeçalhos de sua escolha para o aplicativo de destino, levando, possivelmente, a um variedade de ataques ou causando erros na execução do aplicativo que não saberá como tratar os cabeçalhos recebidos.
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
*
como o valor do atributo de headers
indica que qualquer cabeçalho será enviado entre domínios.crossdomain.xml
. No entanto, é necessário tomar precauções ao decidir quem pode influenciar as configurações, pois uma política entre domínios excessivamente permissiva permitirá que um aplicativo mal-intencionado se comunique com o aplicativo vítima de modo impróprio, resultando em falsificação, roubo de dados, retransmissão e outros ataques. Vulnerabilidades de desvio de restrições de política ocorrem quando:Exemplo 2: O código a seguir usa o valor de um dos parâmetros para o arquivo SWF carregado com o objetivo de definir a lista de domínios confiáveis.
...
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
. No entanto, é necessário tomar precauções ao definir essas configurações, pois aplicativos SWF carregados via HTTP estão sujeitos a ataques do tipo MITM (man-in-the-middle) e, portanto, não devem ser confiáveis.allowInsecureDomain()
, que desativa a restrição que impede aplicativos SWF carregados via HTTP de acessar os dados de aplicativos SWF carregados via HTTPS.
flash.system.Security.allowInsecureDomain("*");
NameNode
, DataNode
e JobTraker
, para alterar o estado do cluster.Job
em um aplicativo de cliente típico que usa entradas da linha de comando na máquina mestre do cluster 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
, esse site dependerá de www.example.com
para apresentar o código correto e não mal-intencionado. Se os invasores puderem comprometer www.example.com
, eles poderão alterar o conteúdo de fancyWidget.js
para corromper a segurança do site. Por exemplo, eles poderiam adicionar código a fancyWidget.js
para roubar dados confidenciais de um usuário.realloc()
para redimensionar buffers que armazenam informações confidenciais. A função pode deixar uma cópia dessas informações confidenciais retida na memória, onde elas não podem ser sobrescritas.realloc()
costuma ser usada para aumentar o tamanho de um bloco de memória alocada. Muitas vezes, essa operação requer a cópia do conteúdo do bloco de memória antigo em um bloco novo e maior. Essa operação deixa o conteúdo do bloco original intacto, mas inacessível ao programa, impedindo que ele consiga limpar dados confidenciais da memória. Se mais tarde um invasor puder examinar o conteúdo de um despejo de memória, os dados confidenciais poderão ficar expostos.realloc()
em um buffer que contém dados confidenciais:
plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);
realloc()
é usado, uma cópia dos dados ainda pode ser exposta na memória originalmente alocada para plaintext_buffer
.VirtualLock
para bloquear páginas que contêm dados confidenciais. A função nem sempre é implementada.VirtualLock
destina-se a bloquear páginas na memória para impedir que elas sejam paginadas no disco. No entanto, no Windows 95/98/ME, a função é implementada apenas como rascunho e não tem nenhum efeito.
HtmlInputHidden hidden = new HtmlInputHidden();
Hidden hidden = new Hidden(element);
<input>
do tipo hidden
indica o uso de um campo oculto.
<input type="hidden">
X-XSS-Protection
normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.X-XSS-Protection
é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.X-XSS-Protection
normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.
<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
X-XSS-Protection
é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.X-XSS-Protection
normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.X-XSS-Protection
é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.X-XSS-Protection
normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.
...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...
'mydb'
pode acessá-lo.required
. Especificar o tipo de campo garante que a entrada seja verificada com relação ao seu tipo. É possível até mesmo fornecer um atributo pattern
personalizável que verifica a entrada em relação a uma expressão regular. No entanto, essa validação é desabilitada com a adição de um atributo novalidate
a uma tag de formulário e de um atributo formnovalidate
a uma tag de entrada de envio.novalidate
.Exemplo 2: O exemplo a seguir desabilita a validação de formulário por meio de um 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á vazio ou não inclui uma chamada de função para definir X-Content-Type-Options
como nosniff
, ou tenta remover esse cabeçalho.X-Content-Type-Options: nosniff
.X-Content-Type-Options
como nosniff
..X-Content-Type-Options: nosniff
para cada página que possa ter conteúdo controlável pelo usuário.net.http.DetectContentType()
para determinar a resposta Content-Type:
...
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
como nosniff
ou desabilita esse cabeçalho de segurança explicitamente.X-Content-Type-Options: nosniff
.
<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
X-Content-Type-Options
como nosniff
ou desabilita esse cabeçalho de segurança explicitamente.X-Content-Type-Options: nosniff
em cada página que poderia conter conteúdo controlado pelo usuário.X-Content-Type-Options
como nosniff
ou desabilita esse cabeçalho de segurança explicitamente.X-Content-Type-Options: nosniff
em cada página que poderia conter conteúdo controlado pelo usuário.script-src
, img-src
, object-src
, style_src
, font-src
, media-src
, frame-src
, connect-src
.*
para indicar a totalidade ou parte da fonte. Nenhuma das diretrizes é obrigatória. Os navegadores autorizarão todas as fontes de uma diretiva não listada ou derivarão o valor delas a partir da diretiva default-src
opcional. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy
no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP
no Chrome até a versão 25. Os dois nomes foram substituídos pelo atual nome padrão Content Security Policy
. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.unsafe-inline
ou unsafe-eval
torna o objetivo da CSP inútil.script-src
é definida mas nenhum script nonce
é configurado.frame-src
é definida mas nenhum script sandbox
é configurado.django-csp
utiliza unsafe-inline
e unsafe-eval
diretivas inseguras para permitir scripts embutidos e avaliação de código:
...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...
X-Frame-Options
para indicar ao navegador se o aplicativo deve ser enquadrado. Se você desabilitar ou não definir esse cabeçalho, isso poderá levar a vulnerabilidades entre quadros.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
. Essas oito diretivas usam uma lista de fontes como um valor que especifica domínios que o site pode acessar para um recurso abrangido por essa diretiva. Os desenvolvedores podem usar um curinga *
para indicar a totalidade da fonte ou parte dela. Palavras-chave adicionais da lista de fontes, como 'unsafe-inline'
e 'unsafe-eval'
, fornecem um controle mais granular sobre a execução do script, mas são potencialmente prejudiciais. Nenhuma das diretrizes é obrigatória. Os navegadores permitem todas as fontes para uma diretiva não listada ou derivam seu valor da diretiva opcional default-src
. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy
no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP
no Chrome até a versão 25. Esses dois nomes foram substituídos pelo atual nome padrão Content Security Policy
. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.default-src
excessivamente flexível e insegura:
<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
. Essas oito diretivas usam uma lista de fontes como um valor que especifica domínios que o site pode acessar para um recurso abrangido por essa diretiva. Os desenvolvedores podem usar um curinga *
para indicar a totalidade da fonte ou parte dela. Palavras-chave adicionais da lista de fontes, como 'unsafe-inline'
e 'unsafe-eval'
, fornecem um controle mais granular sobre a execução do script, mas são potencialmente prejudiciais. Nenhuma das diretrizes é obrigatória. Os navegadores permitem todas as fontes para uma diretiva não listada ou derivam seu valor da diretiva opcional default-src
. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy
no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP
no Chrome até a versão 25. Esses dois nomes foram substituídos pelo atual nome padrão Content Security Policy
. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.*-src
foi configurada com uma política excessivamente permissiva, como *
Exemplo 1: Esta configuração django-csp
define uma diretiva default-src
excessivamente permissiva e insegura:
...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...
Access-Control-Allow-Origin
é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.
Response.AppendHeader("Access-Control-Allow-Origin", "*");
*
como valor do cabeçalho Access-Control-Allow-Origin
indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.Access-Control-Allow-Origin
está definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.
<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>
*
como o valor do cabeçalho Access-Control-Allow-Origin
indica que os dados do aplicativo podem ser acessados pelo JavaScript em execução em qualquer domínio.Access-Control-Allow-Origin
é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.
<?php
header('Access-Control-Allow-Origin: *');
?>
*
como valor do cabeçalho Access-Control-Allow-Origin
indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.Access-Control-Allow-Origin
é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.
response.addHeader("Access-Control-Allow-Origin", "*")
*
como valor do cabeçalho Access-Control-Allow-Origin
indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.Access-Control-Allow-Origin
é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.
play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}
*
como valor do cabeçalho Access-Control-Allow-Origin
indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.Access-Control-Allow-Origin
é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.
Response.AddHeader "Access-Control-Allow-Origin", "*"
*
como valor do cabeçalho Access-Control-Allow-Origin
indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.