Encapsulamento consiste em traçar limites fortes. Em um navegador web, isso pode significar que seu código para dispositivos móveis não pode ser abusado por outros códigos para dispositivos móveis. No servidor, pode significar a diferenciação entre dados validados e não validados, entre os dados de dois usuários ou entre os dados que os usuários podem ou não acessar.
X-Frame-Options.X-Frame-Options.localStorage e sessionStorage pode expor informações confidenciais involuntariamente.localStorage e sessionStorage para permitir aos desenvolvedores manterem os valores do programa. O mapa sessionStorage fornece armazenamento à página de chamada e permanece apenas pela duração da instância de página e da sessão imediata do navegador. O mapa localStorage, no entanto, fornece um armazenamento acessível por meio de várias instâncias de página e várias instâncias de navegador. Essa funcionalidade permite a um aplicativo persistir e utilizar a mesma informação em várias guias ou janelas do navegador.sessionStorage para o localStorage ou vice-versa.sessionStorage. No entanto, o desenvolvedor também armazena as informações no objeto localStorage.
...
try {
sessionStorage.setItem("userCCV", currentCCV);
} catch (e) {
if (e == QUOTA_EXCEEDED_ERR) {
alert('Quota exceeded.');
}
}
...
...
var retrieveObject = sessionStorage.getItem("userCCV");
try {
localStorage.setItem("userCCV",retrieveObject);
} catch (e) {
if (e == QUOTA_EXCEEDED_ERR) {
alert('Quota exceeded.');
}
...
var userCCV = localStorage.getItem("userCCV");
...
}
...
localStorage, as informações CCV estarão agora disponível em outras guias do navegador e também em novas invocações do browser. Isso ignorará a lógica do aplicativo para o fluxo de trabalho pretendido.MyAccountActions e um método de ação de página pageAction(). O método pageAction() é executado quando o URL da página é visitado e o servidor não verifica se há 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;
}
}
...
}
<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
rb.sendRequest(body, new NewAccountCallback(callback));
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
body = addToPost(body, "attacker";
body = addToPost(body, "haha");
rb.sendRequest(body, new NewAccountCallback(callback));
example.com acessar a página mal-intencionada enquanto tiver uma sessão ativa no site, criará involuntariamente uma conta para o invasor. Isso é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.
<http auto-config="true">
...
<csrf disabled="true"/>
</http>
var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);
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);
example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.
<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>
<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>
example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.buyItem.
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com, ela comprará itens involuntariamente para o invasor. Isso é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.
<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>
<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>
example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.X-Download-Options que está sendo definido como noopen permite que páginas HTML sejam executadas no contexto de segurança do site que as serve.
var express = require('express');
var app = express();
var helmet = require('helmet');
app.use(helmet({
ieNoOpen: false
}));
...
Origin, ele permitirá que qualquer site mal-intencionado represente o usuário e estabeleça uma conexão WebSocket bidirecional sem o usuário sequer perceber.Origin, ele permitirá que qualquer site mal-intencionado represente o usuário e estabeleça uma conexão WebSocket bidirecional sem o usuário sequer perceber.exclude. Isso é difícil de manter e está sujeito a erros. Caso os desenvolvedores adicionem novos campos ao formulário ou um Model que faça backup do formulário e esqueçam de atualizar o filtro exclude, eles poderão expor campos confidenciais aos atacantes. Os atacantes serão capazes de enviar e vincular dados maliciosos a qualquer campo não excluído.User, porém verifica uma lista de bloqueios para o id do usuário:
from myapp.models import User
...
class UserForm(ModelForm):
class Meta:
model = User
exclude = ['id']
...
User foi atualizado com um novo atributo role e o UserForm associado não foi atualizado, o atributo role será exposto no formulário.
...
myWebView.loadUrl("file:///android_asset/www/index.html");
...
Example 1, o renderizador WebView do Android trata todo o conteúdo carregado com loadUrl(), com uma URL começando com "file://" como estando na mesma origem.
<script src="http://www.example.com/js/fancyWidget.js"></script>
Example 2, está sendo usado um protocolo não seguro que poderia permitir que o script resultante seja modificado por um agente mal-intencionado. Como alternativa, outros ataques podem ser realizados para reencaminhar a máquina ao site de um invasor.file://).UIWebView.loadRequest(_:) para carregar um arquivo local:
...
NSURL *url = [[NSBundle mainBundle] URLForResource: filename withExtension:extension];
[webView loadRequest:[[NSURLRequest alloc] initWithURL:url]];
...
Example 1, o mecanismo WebView trata todo o conteúdo carregado com UIWebView.loadRequest(_:), com uma URL que começa com file://, como estando na origem de arquivo local privilegiada.file://, a Política de mesma origem permitirá que os scripts nesse arquivo acessem qualquer outro arquivo da mesma origem, o que pode permitir que um invasor acesse qualquer arquivo local que contenha informações confidenciais.file://).UIWebView.loadRequest(_:) para carregar um arquivo local:
...
let url = Bundle.main.url(forResource: filename, withExtension: extension)
self.webView!.load(URLRequest(url:url!))
...
Example 1, o mecanismo WebView trata todo o conteúdo carregado com UIWebView.loadRequest(_:), com uma URL que começa com file://, como estando na origem de arquivo local privilegiada.file://, a Política de mesma origem permitirá que os scripts nesse arquivo acessem qualquer outro arquivo da mesma origem, o que pode permitir que um invasor acesse qualquer arquivo local que contenha informações confidenciais.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("*");
app.use('/graphql', graphqlHTTP({
schema
}));
app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
'graphql',
schema = schema,
graphiql = True
))
services
.AddGraphQLServer()
.AddQueryType<Query>()
.AddMutationType<Mutation>();
app.use('/graphql', graphqlHTTP({
schema
}));
app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
'graphql',
schema = schema
))
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.
HtmlInputHidden hidden = new HtmlInputHidden();
Hidden hidden = new Hidden(element);
<input> do tipo hidden indica o uso de um campo oculto.
<input type="hidden">
...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...
'mydb' pode acessá-lo.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>