Vamos começar uma série de artigos sobre segurança de aplicativos da web com uma explicação sobre o que os navegadores fazem e como eles fazem. Como a maioria de seus clientes interage com seu aplicativo Web por meio de navegadores, é necessário entender o básico de como esses excelentes programas funcionam.
Chrome e lynxUm navegador é um
mecanismo de renderização . Seu trabalho é fazer o download de uma página da web e apresentá-la de maneira legível por humanos.
Embora isso seja quase uma simplificação criminal, mas por enquanto é tudo o que precisamos saber no momento.
- O usuário digita o endereço na linha de entrada do navegador.
- O navegador baixa o "documento" neste URL e o exibe.
Você pode estar acostumado a trabalhar com um dos navegadores mais populares, como Chrome, Firefox, Edge ou Safari, mas isso não significa que não haja outros navegadores no mundo.
Por exemplo, o
lynx é um navegador de texto de linha de comando leve. No coração do lynx estão os mesmos princípios que você encontrará em outros navegadores convencionais. O usuário digita um endereço da Web (URL), o navegador baixa o documento e o exibe - a única diferença é que o lynx não usa o mecanismo de renderização gráfica, mas a interface de texto, graças a sites como o Google:
Em geral, temos uma idéia do que o navegador faz, mas vamos dar uma olhada nas ações que esses aplicativos engenhosos executam para nós.
O que o navegador faz?
Em resumo, o navegador consiste basicamente em
- Resolução DNS
- Troca HTTP
- Renderização
- Redefinir e repetir
Resolução DNS
Esse processo ajuda o navegador a saber a qual servidor ele deve se conectar quando um usuário digitar um URL. O navegador entra em contato com o servidor DNS e detecta que o
google.com corresponde ao conjunto de dígitos
216.58.207.110 - o endereço IP ao qual o navegador pode se conectar.
Troca HTTP
Assim que o navegador determinar qual servidor atenderá a nossa solicitação, ele estabelecerá uma conexão TCP com ele e iniciará a
troca HTTP . Isso não é senão uma maneira de se comunicar entre o navegador e o servidor de que precisa e, para o servidor, é a maneira de responder às solicitações do navegador.
HTTP é simplesmente o nome do protocolo mais popular de comunicação na rede, e os navegadores escolhem o HTTP principalmente ao se comunicar com os servidores. A troca HTTP implica que o cliente (nosso navegador) envie uma
solicitação e o servidor envie uma
resposta .
Por exemplo, depois que o navegador se conectar com êxito ao servidor que atende
google.com , ele enviará uma solicitação semelhante a esta
GET / HTTP/1.1
Host: google.com
AcceptVamos analisar a consulta linha por linha:
- GET / HTTP / 1.1 : com essa primeira linha, o navegador solicita ao servidor que recupere o documento a partir da localização de / , acrescentando que o restante da solicitação ocorrerá via HTTP / 1.1 (ou você também pode usar a versão 1.0 ou 2)
- Anfitrião: google.com : este é o único cabeçalho HTTP necessário para o protocolo HTTP / 1.1 . Como o servidor pode atender a vários domínios (google.com.br, google.com.br etc.), o Cliente aqui menciona que a solicitação foi para esse host específico.
- Aceitar: * / * : um cabeçalho opcional no qual o navegador informa ao servidor que ele aceitará qualquer resposta. O servidor pode ter um recurso disponível em JSON, XML ou HTML, para escolher qualquer formato que preferir
Depois que o navegador que atua como
cliente concluir sua solicitação, o servidor enviará uma resposta. Aqui está a resposta:
HTTP/1.1 200 OK Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 Server: gws X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Set-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly <!doctype html><html"> ... ... </html>
Uau, desta vez várias informações que precisam ser digeridas. O servidor informa que a solicitação foi bem-sucedida (
200 OK ) e adiciona vários cabeçalhos à
resposta , por exemplo, você pode descobrir qual servidor processou nossa solicitação (
Server: gws ), qual é a política de
proteção X-XSS para esta resposta e assim por diante mais e assim por diante.
No momento, você não precisa entender todas as linhas da resposta. Mais adiante nesta série de publicações, falaremos mais sobre o protocolo HTTP, seus cabeçalhos, etc.
No momento, tudo que você precisa saber é que o cliente e o servidor trocam informações e o fazem através do protocolo HTTP.
Renderização
Por último, mas não menos importante, o processo de renderização está em andamento. Quão bom é o navegador se a única coisa que mostra ao usuário é uma lista de personagens engraçados?
<!doctype html><html"> ... ... </html>
No corpo da
resposta, o servidor inclui a apresentação do documento solicitado, de acordo com o cabeçalho
Tipo de Conteúdo . No nosso caso, o tipo de conteúdo foi definido como
text / html ; portanto, esperamos uma marcação HTML na resposta - e é isso que encontramos no corpo do documento.
Este é exatamente o momento em que o navegador realmente mostra suas habilidades. Ele lê e analisa o código HTML, carrega recursos adicionais incluídos na marcação (por exemplo, arquivos JavaScript ou documentos CSS podem ser especificados lá para carregamento) e os apresenta ao usuário o mais rápido possível.
Mais uma vez, o resultado final deve ser o que é acessível ao Vasya médio.
Se você precisar de uma explicação mais detalhada do que realmente acontece quando pressionamos a tecla Enter na barra de endereços do navegador, sugiro ler o artigo
“O que acontece quando ...” , uma tentativa muito meticulosa de explicar os mecanismos subjacentes a esse processo.
Como esta série é sobre segurança, vou dar uma dica sobre o que acabamos de descobrir: os invasores vivem facilmente das
vulnerabilidades em termos de troca e renderização de HTTP . Vulnerabilidades, usuários mal-intencionados e outras criaturas fantásticas são encontradas em outros lugares, mas uma abordagem mais eficaz para fornecer proteção nos níveis mencionados já permite que você consiga melhorar o seu estado de segurança.
Fornecedores
Os 4 navegadores mais populares pertencem a diferentes fornecedores:
- Google Chrome
- Firefox por Mozilla
- Apple Safari
- Microsoft Edge
Além de lutarem para aumentar sua penetração no mercado, os fornecedores também interagem entre si para melhorar os padrões da web, que são uma espécie de "requisitos mínimos" para os navegadores.
O W3C é a pedra angular do desenvolvimento de padrões, mas os navegadores geralmente desenvolvem suas próprias funções, que acabam se transformando em padrões da Web, e a segurança não é exceção.
Por exemplo, os
cookies SameSite foram introduzidos no Chrome 51, um recurso que permitia que os aplicativos da Web se livrassem de um certo tipo de vulnerabilidade conhecido como CSRF (mais sobre isso mais adiante). Outros fabricantes decidiram que essa era uma boa idéia e seguiram o exemplo, o que levou a abordagem SameSite a se tornar o padrão da Web: o Safari é atualmente o único navegador principal que não
suporta cookies SameSite .
Isso nos diz duas coisas:
- O Safari parece não se importar o suficiente com a segurança de seus usuários (apenas brincando: os cookies SameSite estarão disponíveis no Safari 12, que já podem ter sido lançados no momento da leitura deste artigo)
- corrigir vulnerabilidades em um navegador não significa que todos os usuários estejam seguros
O primeiro ponto é uma chance no Safari (como eu disse, estou brincando!), E o segundo ponto é realmente importante. Ao desenvolver aplicativos da Web, precisamos não apenas garantir que eles tenham a mesma aparência em navegadores diferentes, mas também fornecer a mesma proteção para nossos usuários em plataformas diferentes.
Sua estratégia de segurança de rede deve variar dependendo dos recursos que o fornecedor do navegador nos fornece. Atualmente, a maioria dos navegadores suporta o mesmo conjunto de recursos e raramente se desvia de seu roteiro geral, mas casos como o descrito acima ainda acontecem, e é isso que devemos considerar ao definir nossa estratégia de segurança.
No nosso caso, se decidirmos que apenas neutralizaremos ataques CSRF com cookies SameSite, devemos saber que estamos colocando em risco nossos usuários do Safari. E nossos usuários também devem saber disso.
E, por último, mas não menos importante, lembre-se de que você pode decidir se suporta ou não a versão do navegador: o suporte a cada versão do navegador será impraticável (lembre-se do Internet Explorer 6). Apesar disso, o suporte confiável a várias versões recentes dos principais navegadores geralmente é uma boa solução. No entanto, se você não planeja fornecer proteção em nenhuma plataforma específica, é altamente recomendável que seus usuários saibam disso.
Dica para os profissionais : você nunca deve incentivar seus usuários a usar navegadores desatualizados ou apoiá-los ativamente. Mesmo se você tomou todas as precauções necessárias, outros desenvolvedores da web não. Incentive os usuários a usar a versão mais recente suportada de um de seus principais navegadores.
Fornecedor ou bug padrão?
O fato de um usuário comum acessar nosso aplicativo com a ajuda de software cliente de terceiros (navegador) adiciona outro nível que complica o caminho para uma navegação na Web conveniente e segura: o próprio navegador pode ser uma fonte de vulnerabilidade de segurança.
Os fornecedores geralmente fornecem recompensas (também conhecidas como recompensas de bugs) para pesquisadores de segurança que possam estar procurando vulnerabilidades no próprio navegador. Esses erros não estão relacionados ao seu aplicativo Web, mas à maneira como o navegador gerencia independentemente a segurança.
Por exemplo,
o programa de recompensas do Chrome permite que os pesquisadores de segurança entrem em contato com a equipe de segurança do Chrome para relatar vulnerabilidades que descobriram. Se o fato da vulnerabilidade for confirmado, uma correção será emitida e, como regra geral, um aviso de segurança será publicado, e o pesquisador receberá uma recompensa (geralmente financeira) do programa.
Empresas como o Google investiram uma quantidade considerável de capital em seus programas Bug Bounty, pois isso permite que as empresas atraiam muitos pesquisadores, prometendo-lhes benefícios financeiros se encontrarem algum problema com o software testado.
Todos ganham o programa Bug Bounty: o provedor consegue aumentar a segurança de seu software e os pesquisadores são pagos por suas descobertas. Discutiremos esses programas mais tarde, pois acredito que as iniciativas de Bug Bounty merecem uma seção separada no cenário de segurança.
Jake Archibald é um advogado do Google que descobriu uma vulnerabilidade que afeta vários navegadores. Ele documentou seus esforços para detectá-lo, o processo de contato com vários fornecedores afetados pela vulnerabilidade e a reação dos representantes dos fornecedores em um post interessante no blog , que eu recomendo que você leia.
Navegador do desenvolvedor
Até agora, deveríamos ter entendido um conceito muito simples, mas bastante importante: os navegadores são apenas clientes HTTP criados para um usuário da Internet "médio".
Os navegadores são definitivamente mais poderosos que um cliente HTTP simples para qualquer plataforma (por exemplo, lembre-se de que o NodeJS
depende de 'http'), mas, no final, eles são "apenas" o produto da evolução natural de clientes HTTP mais simples.
Quanto aos desenvolvedores, nosso cliente HTTP provavelmente é
cURL de Daniel Stenberg, um dos programas mais populares que os desenvolvedores da Web usam diariamente. Ele nos permite realizar uma troca HTTP em tempo real, enviando uma solicitação HTTP de nossa linha de comando:
$ curl -I localhost:8080 HTTP/1.1 200 OK server: ecstatic-2.2.1 Content-Type: text/html etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" last-modified: Fri, 20 Jul 2018 11:20:35 GMT cache-control: max-age=3600 Date: Fri, 20 Jul 2018 11:21:02 GMT Connection: keep-alive
No exemplo acima, solicitamos um documento no
localhost: 8080 / , e o servidor local o respondeu com êxito.
Em vez de descarregar o corpo da resposta na linha de comando, usamos o sinalizador
-I , que informa ao cURL que estamos interessados apenas nos cabeçalhos de resposta. Indo um passo adiante, podemos fornecer ao comando cURL um pouco mais de informações, incluindo a solicitação real que ele executa, para que possamos examinar melhor toda essa troca HTTP. A opção que devemos usar:
-v (
detalhado , mais):
$ curl -I -v localhost:8080 * Rebuilt URL to: localhost:8080/ * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8080 (#0) > HEAD / HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < server: ecstatic-2.2.1 server: ecstatic-2.2.1 < Content-Type: text/html Content-Type: text/html < etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" < last-modified: Fri, 20 Jul 2018 11:20:35 GMT last-modified: Fri, 20 Jul 2018 11:20:35 GMT < cache-control: max-age=3600 cache-control: max-age=3600 < Date: Fri, 20 Jul 2018 11:25:55 GMT Date: Fri, 20 Jul 2018 11:25:55 GMT < Connection: keep-alive Connection: keep-alive < * Connection #0 to host localhost left intact
Sobre a mesma informação está disponível em navegadores populares por meio de seus DevTools.
Como vimos, os navegadores nada mais são do que clientes HTTP sofisticados. Obviamente, eles adicionam um grande número de funções (por exemplo, gerenciamento de credenciais, favoritos, histórico etc.), mas a verdade é que eles nasceram como clientes HTTP para as pessoas. Isso é importante porque, na maioria dos casos, você não precisa de um navegador para verificar a segurança do seu aplicativo da Web, quando pode simplesmente "fumar" e procurar a resposta.
E a última coisa que gostaria de observar: o
navegador pode ser qualquer coisa. Se você possui um aplicativo móvel que usa APIs via HTTP, esse aplicativo é seu navegador - ele é simplesmente configurado por você em um pedido individual, que reconhece apenas um certo tipo de respostas HTTP (da sua própria API).
Mergulho HTTP
Como já mencionamos, abordaremos as fases da
troca e
renderização de
HTTP com mais detalhes, pois elas fornecem o maior número
de vetores de ataque para os invasores.
No
próximo artigo, examinaremos mais de perto o protocolo HTTP e tentaremos entender quais medidas devemos tomar para garantir a segurança da troca HTTP.
A tradução foi apoiada pela EDISON Software , uma empresa profissional de desenvolvimento de sites para grandes clientes, além de desenvolvimento web C # e .NET .