Entenda melhor o HTTP CORS
O que é CORS
ou Cross-Origin-Resource Sharing?
Primeiramente, vamos entender o significado de uma origem (origin), que provém do Same Origin Policy.
Dois sites são considerados 'same origin' se eles têm em comum:
- hostname;
- protocolo http, https;
- se trabalham na mesma porta (80, 8080, 7001...).
Por exemplo, http://www.siteblindado.com e http://www.siteblindado.com/labs possuem a mesma origem.
Primeiramente, vamos entender o significado de uma origem (origin), que provém do Same Origin Policy.
Dois sites são considerados 'same origin' se eles têm em comum:
- hostname;
- protocolo http, https;
- se trabalham na mesma porta (80, 8080, 7001...).
Por exemplo, http://www.siteblindado.com e http://www.siteblindado.com/labs possuem a mesma origem.
Entretanto, http://www.siteblindado.com:7001 e http://www.siteblindado.com:8080 possuem origens distintas.
O Same Origin Policy restringe como um script de uma origem pode interagir com o conteúdo de uma outra origem. É um mecanismo de segurança para que os browsers diminuam as ações de scripts maliciosos.
Tendo em vista o cenário acima, quando uma aplicação web consegue ler os dados de uma outra aplicação, estamos falando de CORS.
O Same Origin Policy restringe como um script de uma origem pode interagir com o conteúdo de uma outra origem. É um mecanismo de segurança para que os browsers diminuam as ações de scripts maliciosos.
Tendo em vista o cenário acima, quando uma aplicação web consegue ler os dados de uma outra aplicação, estamos falando de CORS.
Sendo assim, essa especificação permite uma comunicação
cross-domain, através do browser. Essa feature é possível ao adicionar no HTTP Headers
as origens que são permitidas para o cross-domain. Ou seja, o CORS serve para
flexibilizar o Same Origin Policy.
Ainda, vale ressaltar que CORS é muito utilizado,
especialmente em APIs.
Na configuração dos Headers, o Origin fica responsável por validar se a request tem a origem do domínio correto.
O Access-Control-Allow-Origin fica responsável por validar se o 'response' é permitido ou não. Caso seja ‘setado’ de forma indevida, torna a aplicação vulnerável.
E o que a torna vulnerável?
Misconfiguration (Top 10 Owasp), a configuração incorreta da feature faz com que a mesma fique vulnerável. O erro mais comum é "setar" os domínios permitidos com um wildcard (*). Exemplo:
GET /api/labs.php
Host: www.siteblindado.com
Origin: www.siteblindado.com
Quando enviado a request acima, é obtido o response com o header Access-Control-Allow-Origin:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Quando o header é mal configurado, como a inserção de um wildcard, permite que qualquer domínio tenha acessos aos dados da aplicação.
Na configuração dos Headers, o Origin fica responsável por validar se a request tem a origem do domínio correto.
O Access-Control-Allow-Origin fica responsável por validar se o 'response' é permitido ou não. Caso seja ‘setado’ de forma indevida, torna a aplicação vulnerável.
E o que a torna vulnerável?
Misconfiguration (Top 10 Owasp), a configuração incorreta da feature faz com que a mesma fique vulnerável. O erro mais comum é "setar" os domínios permitidos com um wildcard (*). Exemplo:
GET /api/labs.php
Host: www.siteblindado.com
Origin: www.siteblindado.com
Quando enviado a request acima, é obtido o response com o header Access-Control-Allow-Origin:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Quando o header é mal configurado, como a inserção de um wildcard, permite que qualquer domínio tenha acessos aos dados da aplicação.
A partir do momento que qualquer aplicação pode obter dados
da aplicação mal configurada, é possível explorar e obter informações privilegiadas
ao enviar o 'response' para uma outra aplicação ou server que o invasor
desejar.
Outra possibilidade de exploração, (caso a aplicação tenha sido configurada com o CORS para aceitar apenas o domínio teste.com, quando feito o request pelo atacante) seria da seguinte forma:
GET /api/labs.php
Host: siteblindado.com
Connectrion: Close
Origin: atacanteteste.com
O response seria:
HTTP/ 1.1 200 OK
Access-Control-Allow-Origin: atacanteteste.com
Access-Control-Allow-Credentials: True
Este erro ocorre, pois possivelmente o back-end foi mal configurado, aceitando “*teste.com”, ou seja, toda origem que termina em 'teste.com' será validada e o request será aceito.
Como evitar?
O melhor método para diminuir riscos é apostar na configuração correta de acordo com suas aplicações.
Outra possibilidade de exploração, (caso a aplicação tenha sido configurada com o CORS para aceitar apenas o domínio teste.com, quando feito o request pelo atacante) seria da seguinte forma:
GET /api/labs.php
Host: siteblindado.com
Connectrion: Close
Origin: atacanteteste.com
O response seria:
HTTP/ 1.1 200 OK
Access-Control-Allow-Origin: atacanteteste.com
Access-Control-Allow-Credentials: True
Este erro ocorre, pois possivelmente o back-end foi mal configurado, aceitando “*teste.com”, ou seja, toda origem que termina em 'teste.com' será validada e o request será aceito.
Como evitar?
O melhor método para diminuir riscos é apostar na configuração correta de acordo com suas aplicações.
Caso a aplicação não seja de acesso para conteúdo público,
por exemplo, nunca configure o Access-Control-Allow-Origin
com um wildcard (*).
Utilize outros headers para uma melhor política de segurança,
como a combinação do Access-Control-Allow-Origin,
Access-Control-Allow-Credentials e Access-Control-Allow-Methods, para
validar e requerer credencias e métodos (GET, POST, DELETE, PUT) que a
aplicação no cross-domain poderá utilizar.
Conclusão
Por mais que seja 'apenas' um header, o CORS pode tornar sua aplicação vulnerável a ataques críticos. A combinação com outros headers mal configurados pode, ainda, permitir exposição de dados da aplicação da API e, inclusive, em um RCE.
Conclusão
Por mais que seja 'apenas' um header, o CORS pode tornar sua aplicação vulnerável a ataques críticos. A combinação com outros headers mal configurados pode, ainda, permitir exposição de dados da aplicação da API e, inclusive, em um RCE.
Mas a aprofundação destes tópicos a gente deixa para os próximos
posts. Neste artigo, fica o alerta para que os desenvolvedores realizem a
configuração correta da aplicação como um todo.
Referencias:
https://www.pivotpointsecurity.com/blog/cross-origin-resource-sharing-security/
https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Controle_Acesso_CORS
Referencias:
https://www.pivotpointsecurity.com/blog/cross-origin-resource-sharing-security/
https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Controle_Acesso_CORS
0 comentários: