Frontend Segurança

Desmistificando CORS, SOP e CSP

Essas sopinhas de letras costumam trazer muitas dúvidas, até mesmo para os desenvolvedores experientes. Aprenda de uma vez a lidar com CORS, SOP e CSP.

CORS: O que é e como funciona o Cross-Origin Resource Sharing

Ao abrirmos uma página da web, os dados carregados de servidores de terceiros é, em teoria, estritamente proibido. No entanto pode haver exceções: se os administradores de ambos os sites concordaram em trabalhar juntos, então não há razão para evitar essa troca. Nestes casos, o chamado compartilhamento de recursos de origem cruzada ou simplesmente CORS, regula a colaboração.

Ok, mas como funciona o CORS?

Dúvida | Cidadão Italiano

Para explicar o cabeçalho CORS, primeiro precisamos entender o SameOriginPolicy (SOP). Neste cenário, vamos considerar dois domínios:

1 – domain-a.com
2 – domain-b.com

Se o domínio 1 deseja acessar o estado dos serviços do domínio 2 (domain-b.com/healthcheck), SOP (SameOriginPolicy) proíbe que o domínio 1 acesse o domínio 2. Em outras palavras, é o mesmo que, todos os dados devem ser providos da mesma fonte, do mesmo servidor, do mesmo domínio.

Portanto se trata de uma medida de segurança, já que um JavaScript e um CSS, poderiam carregar, sem que um usuário soubesse (que dados estão sendo carregados de outras origens), podendo então, carregar conteúdos maliciosos.

SameOriginPolicy (SOP) é a política padrão seguidos em todos os navegadores que impede o compartilhamento de dados entre dois domínios diferentes.

Já o CORS, fornece a possibilidade de compartilhamento de dados de origem diferente (domínio, protocolo e porta) de uma forma segura, se e somente se, estiver configurado de forma correta. Eu gosto de chamar o CORS de “mecanismo anti-segurança“.

Abaixo um exemplo:

https://developer.mozilla.org/pt-BR/docs/Web/HTTP/CORS

Na estrutura do cabeçalho CORS, podemos dizer que uma solicitação de origem cruzada é, em teoria uma solicitação HTTP. Métodos específicos geralmente não são um problema. Exemplo do GET e HEAD, esses em específicos não podem alterar dados e, portanto, geralmente não são vistos como um risco de segurança. O mesmo não pode ser dito de PATCH, POST, PUT ou DELETE, eles podem ser usados para realizar ações maliciosas, portanto, nestes casos, o compartilhamento de recursos entre origens também deve ser ativado, já que o CORS pode conter não apenas informações sobre a origem permitida, mas também sobre quais solicitações HTTP são permitidas pela fonte.

No caso de métodos de segurança HTTP, o cliente primeiro envia uma solicitação de comprovação na qual apenas indica qual método HTTP pretende transmitir para o servidor em seguida, e pergunta se a solicitação é considerada segura. Para fazer isso, o método OPTIONS é usado. Assim que uma resposta positiva for recebida, a própria solicitação pode ser feita.

Existem diferentes cabeçalhos CORS e cada um aborda um aspecto diferente. Acima mencionamos dois cabeçalhos importantes para identificar origens seguras e métodos permitidos, mas existem os seguintes:

Access-Control-Allow-Origin: qual origem é permitida?
Access-Control-Allow-Credentials: as solicitações também são aceitas quando o modo credencial é incluído?
Access-Control-Allow-Headers: quais cabeçalhos podem ser usados?
Access-Control-Allow-Methods: quais métodos de solicitação HTTP são permitidos?
Access-Control-Expose-Headers: quais cabeçalhos podem ser exibidos?
Access-Control-Max-Age: Quando a solicitação de comprovação se torna inválida?
Access-Control-Request-Headers: qual cabeçalho HTTP é indicado na solicitação de comprovação?
Access-Control-Request-Method: qual método de solicitação HTTP é indicado na solicitação de comprovação?
Origin: de que origem vem o pedido?

O primeiro cabeçalho “Access-Control-Allow-Origin” é especialmente importante, pois especifica de qual outro host o servidor solicitado pode ser acessado. Além de um endereço específico, esse cabeçalho também pode incluir um curinga na forma de um asterisco. Desta forma, o servidor permitirá solicitações de cross-origin de qualquer lugar.

No exemplo a seguir, presumimos que o host 1 (domain-a.com) deseja enviar uma solicitação DELETE para o host 2 (domain-b.com). Para fazer isso, o servidor 1 primeiro envia uma solicitação prévia:

OPTIONS /
Origin: http://domain-a.com
Access-Control-Request-Method: DELETE

Se o host 2, não se opor a esta solicitação de cross-origin, ele responderá com os cabeçalhos CORS correspondentes:

Access-Control-Allow-Origin: http://domain-a.com
Access-Control-Allow-Methods: PATH, PUT, POST, DELETE

Se os cabeçalhos de resposta não corresponderem às especificações da solicitação ou se o servidor solicitado não responder, a solicitação de cross-origin não poderá ser executada.

Vantagens do CORS:

O objetivo do CORS é contornar a medida de segurança definida como configurado padrão. Essa política é, na verdade , um meio muito eficaz de bloquear conexões potencialmente perigosas. Entretanto, a internet frequentemente depende exatamente deste tipo de solicitação de cross-origin, uma vez que muitas das conexões entre hosts são desejadas.

Por este motivo, o CORS, oferece uma solução intermediária, permitindo exceções à proibição nas situações em que as aplicações de cross-origin sejam expressamente exigidas. No entanto, existe o risco de que desenvolvedores aproveitem os “curingas”:


Access-Control-Allow-Origin: *

por conveniência, tornando a proteção SOP em vão. Portanto é importante usar o CORS apenas em casos especiais e configurá-lo da forma mais restritiva possível.

Seguindo o nosso raciocínio, agora que temos um bom entendimento de SOP e como o CORS de fato é usado, vamos falar sobre onde a CSP (Content Security Policy) se encaixa.

CSP é uma política definida no cabeçalho HTTP Content-Security-Policy. O objetivo principal do CSP é adicionar uma camada de segurança para prevenir alguns ataques, incluindo ataques XSS (Cross-Site Scripting), De forma geral, o XSS funciona enganando um navegador para que execute um script na origem do seu site, dando ao código malicioso acesso para ler ou modificar o conteúdo do site. “Não podemos confiar no que não podemos verificar”.

O CSP nos permite definir uma lista de fontes confiáveis, com isso o navegador não executará ou renderizará nenhum recurso fora dessa lista. Se por ventura, um invasor conseguir injetar script em um site, o script não será executado, pois não corresponderá à lista de permissões. O cabeçalho CSP pode ser composto de várias diretivas diferentes.

Abaixo um exemplo de CSP:


Content-Security-Policy: script-src 'self' http://www.domain-a.com

Script-src é uma diretiva CSP, ele permite que você defina a lista de permissões de fontes aceitáveis para o JavaScript. Então, neste exemplo, estamos permitindo o JavaScript próprio,  e quaisquer recurso solicitados em domain-a.com . Qualquer script que tente executar e que não venha dessas duas fontes será bloqueado pelo navegador.

Existem diversas diretivas CSP que podem ser vistas aqui.

REFERÊNCIAS

MOZILLA. Cross-Origin Resource Sharing. Acessado 25/03/2021. Site: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/CORS
MOZILLA. Content-Security-Policy. Acessado 25/03/2021. Site: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#directives
ARTS3NAL. Demystifying SOP and CSP, featuring CORS. Acessado 25/03/2021. Site: https://blog.artis3nal.com/2018-11-05-demystifying_sop_and_csp/

%d blogueiros gostam disto: