Segurança de software não é o mesmo que software de segurança. Aqui, estamos interessados em tópicos como autenticação, controle de acesso, confidencialidade, criptografia e gestão de privilégios.
@secure()
param sqlLogin string
@secure()
param sqlLoginPass string
param location string = resourceGroup().location
resource sqlServer 'Microsoft.Sql/servers@2021-11-01-preview' = {
name: 'server name'
location: location
tags: {
displayName: 'server name'
}
properties: {
administratorLogin: sqlLogin
administratorLoginPassword: sqlLoginPass
version: '12.0'
publicNetworkAccess: 'Disabled'
}
}
{
"name": "ProdSQLServer",
"type": "Microsoft.Sql/servers",
"apiVersion": "2021-02-01-preview",
...
"properties": {
"collation": "SQL_Latin1_General_CP1_CI_AS",
...
"resources": []
}
...
}
LocalAuthentication
para autenticar o usuário, que pode não ser suficiente para os aplicativos que exigem controles de segurança elevados.LocalAuthentication
ou usando os controles de acesso baseados em ID de toque no serviço de conjunto de chaves.LocalAuthentication
tem algumas características que as tornam menos adequadas para aplicativos de alto risco, como bancos, médicos e seguros:LocalAuthentication
é definida fora do Enclave Seguro do dispositivo, o que implica que as APIs podem ser conectadas e modificadas em dispositivos com jailbreak.LocalAuthentication
autentica o usuário avaliando a política de contexto que só pode avaliar como true
ou false
. Essa avaliação booleana implica que o aplicativo não será capaz de saber quem está realmente sendo autenticado, ele só sabe se a impressão digital que está registrada com o dispositivo foi usada. Além disso, as impressões digitais que poderiam ser registradas no futuro serão avaliadas com êxito como true
.LocalAuthentication
para realizar a autenticação do usuário:
...
LAContext *context = [[LAContext alloc] init];
NSError *error = nil;
NSString *reason = @"Please authenticate using the Touch ID sensor.";
if ([context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]) {
[context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:reason
reply:^(BOOL success, NSError *error) {
if (success) {
// Fingerprint was authenticated
} else {
// Fingerprint could not be authenticated
}
}
];
...
LocalAuthentication
para autenticar o usuário, que pode não ser suficiente para os aplicativos que exigem controles de segurança elevados.LocalAuthentication
ou usando os controles de acesso baseados em ID de toque no serviço de conjunto de chaves.LocalAuthentication
tem algumas características que as tornam menos adequadas para aplicativos de alto risco, como bancos, médicos e seguros:LocalAuthentication
é definida fora do Enclave Seguro do dispositivo, o que implica que as APIs podem ser conectadas e modificadas em dispositivos com jailbreak.LocalAuthentication
autentica o usuário avaliando a política de contexto que só pode avaliar como true
ou false
. Essa avaliação booleana implica que o aplicativo não será capaz de saber quem está realmente sendo autenticado, ele só sabe se a impressão digital que está registrada com o dispositivo foi usada. Além disso, as impressões digitais que poderiam ser registradas no futuro serão avaliadas com êxito como true
.LocalAuthentication
para realizar a autenticação do usuário:
...
let context:LAContext = LAContext();
var error:NSError?
let reason:String = "Please authenticate using the Touch ID sensor."
if (context.canEvaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, error: &error)) {
context.evaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, localizedReason: reason, reply: { (success, error) -> Void in
if (success) {
// Fingerprint was authenticated
}
else {
// Fingerprint could not be authenticated
}
})
}
...
isSecure
definido como true
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies por um canal não criptografado pode expô-los a ataques de detecção de rede. O sinalizador seguro ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.isSecure
como true
.
...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...
isSecure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego da rede por conexões sem fio não criptografadas é uma tarefa simples para os invasores. O envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.Secure
definido como true
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure
.
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
...
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.Secure
como true
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados ou identificadores de sessão privados, ou carrega um token CSRF.Secure
.
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
http.SetCookie(response, &cookie)
...
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.Secure
definido como true
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.use-secure-cookie
permite que o cookie remember-me
seja enviado por transporte não criptografado.
<http auto-config="true">
...
<remember-me use-secure-cookie="false"/>
</http>
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.Secure
definido como true
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure
como true
.
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.NSHTTPCookieSecure
definido como TRUE
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure
.
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.Secure
como true
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure
.
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.Secure
como True
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados ou identificadores de sessão privados, ou carrega um token CSRF.Secure
.
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email)
return res
...
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.Secure
definido como true
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure
.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.NSHTTPCookieSecure
definido como TRUE
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure
.
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.CSRF_COOKIE_SECURE
como True
ou a define como False
.Secure
para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados privados, identificadores de sessão, ou carrega um token CSRF.Secure
para os cookies CSRF.
...
MIDDLEWARE_CLASSES = (
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'csp.middleware.CSPMiddleware',
'django.middleware.security.SecurityMiddleware',
...
)
...
Secure
, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.HttpOnly
como true
.HttpOnly
, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly
habilitado, os invasores podem acessar cookies de usuário com mais facilidade.HttpOnly
.
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
HttpOnly
como true
.HttpOnly
, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de criação de script entre sites muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Com HttpOnly
desativado, os invasores têm acesso mais fácil aos cookies do usuário.HttpOnly
.
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
...
HttpOnly
como true
.HttpOnly
, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly
habilitado, os invasores podem acessar cookies de usuário com mais facilidade.HttpOnly
.
javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie("emailCookie", email);
// Missing a call to: cookie.setHttpOnly(true);
HttpOnly
como true
.HttpOnly
, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly
habilitado, os invasores podem acessar cookies de usuário com mais facilidade.httpOnly
.
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});
HttpOnly
como true
.HttpOnly
, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly
habilitado, os invasores podem acessar cookies de usuário com mais facilidade.HttpOnly
.
setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE); //Missing 7th parameter to set HttpOnly
HttpOnly
como True
.HttpOnly
, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly
habilitado, os invasores podem acessar cookies de usuário com mais facilidade.HttpOnly
.
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email)
return res
...
HttpOnly
como true
.HttpOnly
, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly
habilitado, os invasores podem acessar cookies de usuário com mais facilidade.HttpOnly
.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, httpOnly = false))
HttpCookie.HttpOnly
como true
.httpOnlyCookies
é falso, o que significa que o cookie pode ser acessado por meio de um script do lado do cliente. Esta é uma ameaça desnecessária de cross-site scripting, resultando em cookies roubados. Os cookies roubados podem conter informações confidenciais que identificam o usuário no site, como a ID de sessão ASP.NET ou tíquete de autenticação de formulários, e podem ser reproduzidos pelo invasor para ser fazer passar pelo usuário ou obter informações confidenciais.
<configuration>
<system.web>
<httpCookies httpOnlyCookies="false">