Adoro quando você come sua própria ração de cachorro!!!.
Os navegadores modernos, sem mencionar nenhum específico (como o Chrome), estão ficando mais exigentes com as configurações de segurança de cookies.
Um exemplo é a configuração do cookie SameSite. Por exemplo, se ela não estiver presente no Chrome, ele usará seu método padrão, SameSite=Lax.
Mas o que acontece se você não quiser isso? A resposta é alterar o código do seu aplicativo para refletir a configuração que você deseja usar. Mas o que acontece se você não puder fazer isso facilmente? Pode ser um aplicativo legado.
A resposta é usar os recursos de troca de conteúdo do flightPATH do EdgeADC.
O infame problema de execução do WordPress WooCommerce em um iframe
Então, tivemos um problema com um aplicativo WordPress que usamos em execução em um iframe. (Não pergunte por quê.)
O aplicativo estava usando cookies de sessão que não tinham a configuração SameSite definida.
O aplicativo é executado em um sistema WordPress padrão fornecido em um contêiner do Docker.
Investigamos algumas maneiras de corrigir isso, mas nossas alterações não funcionaram corretamente em todos os cookies, então decidimos tentar corrigi-lo usando o flightPATH.
Então, foi isso que fizemos.
Criamos uma regra flightPATH para adicionar SameSite=none aos três cookies ofensivos, conforme mostrado abaixo.
A primeira regra flightPATH que criaremos é:
Em seguida, criaremos o segundo.
Por fim, criamos o último. Esse tem uma definição um pouco diferente, como você pode ver. Adicionamos um curinga (*), pois não sabemos qual é esse valor, já que o WordPress/WooCommerce atribui um valor aleatório.
Nesse momento, você deve estar pensando: “ei, isso não é seguro quando um curinga é usado! Entendemos que o site é um pouco menos seguro, mas… você não pode usar um curinga:
- Tudo isso está sendo executado usando HTTPS
- Executamos um firewall de aplicativo
- Ele é reforçado pelo fato de ser um sistema operacional em contêiner e os principais arquivos são imutáveis
E, caso você precise de uma atualização sobre o SameSite…
Qual é a configuração do SameSite para cookies?
A configuração SameSite Cookie ajuda a controlar quando os cookies são enviados com solicitações entre sites, o que ajuda a reduzir o risco de ataques de falsificação de solicitações entre sites (CSRF). Aqui está um detalhamento de como isso funciona:
O que são solicitações entre sites?
Solicitações entre sites são solicitações feitas de um site para outro. Por exemplo, se você estiver conectado a um aplicativo e clicar em um link para um artigo de notícias, isso é uma solicitação entre sites. Em outras palavras, uma solicitação que vincula um site a outro.
O que é a configuração SameSite?
A configuração SameSite é um atributo de cookie que pode ser usado para controlar se um cookie é enviado ou não com solicitações entre sites. Há três valores possíveis para a configuração SameSite:
- SameSite=Strict: Os cookies são enviados somente com solicitações para o mesmo site que os definiu.
- SameSite=Lax: Os cookies são enviados com solicitações para o mesmo site que os definiu, bem como com solicitações para sites de terceiros que estão incorporados na mesma página, por exemplo, em um iFrame.
- SameSite=Nenhum: Os cookies são enviados com todas as solicitações, independentemente do site que os definiu.
Por que a configuração SameSite é importante?
A configuração SameSite é importante porque ajuda a reduzir o risco de ataques CSRF (Cross-Site Request Forgery). Os ataques CSRF são um tipo de ataque cibernético que explora o fato de o navegador de um usuário já estar conectado a um site. Em um ataque CSRF, um invasor pode induzir um usuário a fazer uma solicitação a um site no qual está conectado, mesmo que o usuário não tenha a intenção de fazer isso. Isso pode permitir que o invasor roube os dados do usuário ou execute outras ações mal-intencionadas.
