DEV Community: Bruno Bertolini

Como REALMENTE o CORS funciona: Entendendo de uma vez por todas

Bruno Bertolini — Mon, 18 May 2020 14:47:18 +0000

Se você já desenvolveu alguma aplicação web, você provavelmente já deu de cara com esse erro no console do navegador:

Esse erro deriva de um mecanismo de segurança implementado pelos navegadores, chamado Same-Origin Policy, (política de mesma origem). A política de mesma origem restringe a forma de como um documento ou script carregado de uma origem pode interagir com um recurso de outra origem. É um mecanismo crítico de segurança para isolar documentos potencialmente maliciosos, e evitar falsificação de solicitações entre sites, mais conhecido como ataque CSRF (cross-site request forgery).

Esse é um tipo de ataque comum, onde um site mal-intencionado tenta tirar proveito do sistema de armazenamento de cookies do navegador. Para cada solicitação de HTTP em um domínio, o navegador anexa todos os cookies HTTP associados a esse domínio. Isso é especialmente útil para autenticação e configuração de sessões. Por exemplo, é possível que você faça login em um aplicativo da web como o instagram.com. Nesse caso, seu navegador armazenaria um cookie de sessão relevante para o domínio instagram.com.

Após armazenado, sempre que um usuário acessar novamente o instagram.com, não será necessário fazer login novamente, já que API reconhecerá o cookie da sessão armazenada, nas requisições futuras (isso se a API usar apenas o cookie como mecanismo de autenticação).

O único problema é que o navegador inclui automaticamente quaisquer cookies relevantes armazenados para um domínio quando outra solicitação é feita para esse domínio exato. Portanto, se o usuário clicar em um pop-up, por exemplo, abrindo site-do-mal.com, esse site também tem a capacidade de enviar uma solicitação para instagram.com. Como a solicitação está indo para o domínio instagram.com, o navegador inclui os cookies relevantes. O site do mal envia o cookie da sessão e obtém acesso autenticado ao Instagram. Sua conta foi invadida com sucesso com um ataque de falsificação de solicitação entre sites.

Felizmente, nessa situação, o navegador intervém e impede que o código malicioso faça uma solicitação de API como esta, e dispara o famoso erro de CORS, que você viu na primeira imagem.

E que raios então é CORS?

CORS significa Cross-Origin Resource Sharing (Compartilhamento de recursos com origens diferentes), e é o padrão que flexibiliza a política de mesma origem, fazendo com que aplicações possam acessar recursos de outras origens.

Para que o navegador consiga fazer ou não o bloqueio da política de mesma origem, ele precisA verificar se a origem da aplicação web e do recurso externo (url da requisição) são as mesmas. E quando falamos de origem, estamos falando da combinação entre protocolo (http://), domínio (instagram.com) e porta (80 é a porta padrão quando não especificado).

Então, o navegador adiciona automaticamente, para toda requisição, um cabeçalho informando a origem da aplicação front-end: Origin: http://site-do-mal.com. O servidor então, baseado nessa requisição, envia uma resposta contendo o cabeçalho Access-Control-Allow-Origin, que indica se os recursos da resposta podem ser compartilhados com a origem informada.

Este cabeçalho pode ter como valor:

Uma origem permitida: Access-Control-Allow-Origin: http://instagram.com; ou
Um *, que indica que qualquer origem pode acessar determinado recurso: Access-Control-Allow-Origin: *

Nota: É recomendado cuidar com o uso desses cabeçalhos, já que o uso incorreto pode inutilizar a política de mesma origem, facilitando ataques CSRF

Com esse cabeçalho "em mãos", o navegador pode comparar com o valor de origem do front-end, e bloquear a solicitação caso os valores não sejam compatíveis.

Além disso, para métodos de requisição HTTP que podem causar efeitos colaterais nos dados do servidor (em particular, para métodos HTTP diferentes de GET com determinados cabeçalhos, ou para uso de POST com certos Content-types), a especificação exige que navegadores "pré-enviem" a requisição, solicitando os métodos suportados pelo servidor (e pra informar isso, o servidor utiliza o cabeçalho Access-Control-Allow-Methods) com um método de requisição HTTP OPTIONS e, após a "aprovação", o servidor envia a requisição verdadeira com o método de requisição HTTP correto.

Então, resumindo, CORS nada mais é do que a configuração de cabeçalhos de resposta Access-Control-* (do lado do servidor), que informam se uma requisição (baseado em origem e métodos HTTP), pode ou não acessar determinado recurso, flexibilizando assim, a política de mesma origem (Same-Origin Policy), que tem a intenção principal de evitar ataques CSRF.

Tudo o que você precisa saber sobre JSON Web Tokens

Bruno Bertolini — Wed, 08 Jan 2020 16:34:01 +0000

O JSON Web Token (JWT) é um padrão aberto, que define uma maneira compacta e independente de transmitir informações com segurança entre as partes, utilizando um objeto JSON.

Os tokens assinados podem verificar a integridade das reivindicações (claims) contidas nele, enquanto os tokens criptografados ocultam essas reivindicações de outras partes. Quando os tokens são assinados usando pares de chaves pública / privada, a assinatura também certifica que apenas a parte que detém a chave privada é a que o assinou.

E onde deveria usá-los?

Dois cenários principais, onde JWTs são úteis:

Autorização: este é o cenário mais comum para o uso do JWT. Após o login do usuário, cada solicitação subsequente incluirá o JWT, permitindo que o usuário acesse rotas, serviços e recursos permitidos com esse token. O SSO (Single sign-on) é um recurso que usa amplamente o JWT atualmente, devido à sua pequena sobrecarga e à capacidade de ser facilmente usado em diferentes domínios.

Troca de informações: os JSON Web Tokens são uma boa maneira de transmitir informações com segurança entre as partes. Como as JWTs podem ser assinadas (por exemplo, usando pares de chaves públicas / privadas), você pode ter certeza de que os remetentes são quem eles dizem que são. Além disso, como a assinatura é calculada usando o cabeçalho e o payload, você também pode verificar se o conteúdo não foi violado.

Certo, e como é a estrutura de um JWT?

JSON Web Tokens são compostos por 3 partes, separadas por um ponto: Cabeçalho (header), dados (payload) e assinatura (signature).

Cabeçalho (header)

O cabeçalho geralmente consiste em duas partes: o tipo do token, que é JWT, e o algoritmo de assinatura que está sendo usado, como HMAC SHA256 ou RSA.

Em seguida, esse JSON é codificado em Base64Url para formar a primeira parte do JWT.

Dados (payload)

O payload é exatamente os dados que você deseja enviar para a outra parte. Geralmente segue um padrão (registered claims), mas não é obrigatório, portanto aceita qualquer JSON

O payload é então codificado em Base64Url para formar a segunda parte do JWT.

Assinatura (signature)

Para criar a parte da assinatura, é necessário pegar o cabeçalho codificado, a payload codificado, um segredo, o algoritmo especificado no cabeçalho e assinar isso.

A assinatura é usada para verificar se a mensagem não foi alterada ao longo do caminho e, no caso de tokens assinados com uma chave privada, também pode verificar se o remetente da JWT é quem diz ser.

Esse conteúdo também está lá no insta da codar.me, segue lá, que tenho postado conteúdo com frequência! Ah, e se inscreve no canal do youtube pra conteúdos mais aprofundados! :)

Gerenciamento de autenticação no front-end

Bruno Bertolini — Mon, 18 Nov 2019 11:41:34 +0000

Existem várias formas de fazer o gerenciamento de autenticação no front. A forma que eu vou mostrar aqui é simples, porém robusta, e pode ser utilizada tanto no React Native quanto no React web.

Faremos isso com React Native, utilizando o Context API pra criar um estado global na nossa aplicação, e AsyncStorage pra persistência de dados.

A tela de login

Precisamos pensar como esse gerenciamento vai funcionar. Eu gosto de começar de cima pra baixo o desenvolvimento, da camada mais alta até a mais baixa, isso me dá uma clareza maior do que precisa ser feito.

Nesse caso, a camada mais alta é a nossa tela de login. Então o que eu preciso fazer quando o usuário apertar o botão Entrar? Basicamente, duas coisas:

Pegar os dados do form e enviar pra uma api, que vai me retornar o usuário logado e um token para as próximas requisições
Pegar os dados retornados da api, e jogar eles em um estado global, pra que seja acessado de qualquer parte da aplicação.

Então, teríamos um componente de login, semelhante a isto:

const Login = () => {
  const formik = useFormik({
    onSubmit = async values => {
      try {
        const { data } = await api.login(values)
        setStore(data)
      } catch (error) { }
    }
  })

  ...
}

Show, agora eu sei que eu preciso criar um setStore, que vai gerenciar meu estado global, que é a próxima etapa.

Global Store

Podemos fazer a global store de várias formas diferentes, seja utilizando redux, mobx, ou qualquer outra ferramenta de gerenciamento de estado. Aqui, vamos utilizar o Context API, que resolve muito bem o problema e serve tanto para aplicações pequenas quanto maiores.

Vamos criar um simples context provider que utilizará como valor, um useState, assim conseguiremos capturar o estado atual da nossa store em qualquer componente, bem como alterá-lo.

Crie um arquivo chamado store.js, faça o seguinte:

import * as React from 'react'
import { createContext, useState } from 'react'

// Aqui criamos o contexto, já com um valor semelhante 
// ao que precisaremos posteriormente
const StoreContext = createContext([{}, () => {}])

// E aqui encapsulamos o provider pra conseguir passar o retorno 
// do `useState` como valor
export const StoreProvider = ({ children }) => {
  // criando um state com um objeto vazio como valor inicial
  const [state, setState] = useState({})

  return (
    <StoreContext.Provider value={[state, setState]}>
      {children}
    </StoreContext.Provider>
  )
}

Nota: se quiser estudar mais sobre context api, dá uma olhada na doc oficial

Certo, criado nosso global store provider, precisamos usar ele no componente principal da aplicação (geralmente index.js, ou melhor ainda src/index.js), para que todos os componentes abaixo dele tenham acesso ao StoreContext e possam recuperar e manipular nossa store.

import { AppRegistry } from 'react-native'
import { name as appName } from './app.json'
import { App } from './src'

const Root = () => (
  <StoreProvider>
    <App />
  </StoreProvider>
)

AppRegistry.registerComponent(appName, () => Root)

Agora, qualquer componente pode acessar o contexto da store, mas, como fazer isso?

Bom, poderíamos fazer exportando nosso StoreContext e utilizando useContext assim:

import { StoreContext } from './store.js'

const Component = () => {
  const [store, setStore] = useContext(StoreContext)
  return '...'
}

Mas eu aconselho criarmos um hook especifico pra acessar a store, assim temos mais flexibilidade de criação e manutenção, podendo estender as funcionalidades do nosso novo hook facilmente. Então no store.js, criamos o hook:

export const useStore = () => {
  const [store, setStore] = useContext(StoreContext)
  return [store, setStore]
}

Agora que temos login jogando na nossa store os dados do usuário, ao iniciar a aplicação precisamos verificar se um usuário está logado, e redirecionar ele para a tela correspondente (home se estiver logado, login se não estiver). Vamos fazer isso no componente que define as rotas principais, porém nesse momento ele vai ser criado dentro do arquivo src/index.js e vamos chamá-lo de Router.

const Router = () => {
  const [store] = useStore()
  return store.token ? <Home /> : <Login />
}

Lembra que criamos nossa store com um objeto vazio como valor inicial? Pois bem, nesse momento, ao verificar se nossa store possui uma prop token, teremos como resultado false, portanto, nossa tela de login será mostrada. Posteriormente, quando o usuário fizer login e nosso componente de login fizer setStore com o token, automaticamente o nosso router vai ser re-renderizado, dessa vez contento store.token, mostrando assim a tela inicial (Home) no lugar de login.

Pronto, já temos nosso gerenciamento de autenticação, certo? Errado! Ainda falta uma etapa importante. Toda vez que o usuário fechar o app e abrir novamente, nós perdemos os dados em memória, portanto, mesmo que ele tenha feito login recentemente, ele será redirecionado para Login. Então, como podemos resolver isso?

Persistência e reidratação de memória

Quando um app é fechado, de um modo geral, ele apaga todas as variáveis da memória, portanto na próxima execução do app não saberemos quem estava logado. Por isso precisamos persistir essas informações em outro local (como um arquivo, banco de dados local ou remoto), e fazer a reidratação para que o app volta ao estado em que estava logo antes de ser fechado.

Para isso, vamos utilizar o async storage pra react native (pra web você pode utilizar o local storage, com a mesma abordagem).

Vamos iniciar importando o useAsyncStorage e persistindo toda alteração da nossa store nele. Dentro do <StoreProvider> vamos fazer o seguinte:

import { useAsyncStorage } from '@react-native-community/async-storage'

export const StoreProvider = ({ children }) => {
  const [state, setState] = useState({})

  // Aqui definimos que a "key" usada no async storage será "store"
  const { setItem } = useAsyncStorage('store')

  // então usamos o useEffect pra escutar as alterações do state,
  // e executar setItem, que vai persistir  nosso estado
  useEffect(() => {
   setItem(JSON.stringify(state))
  }, [state])

  return ...
}

Agora quando executarmos o setStore lá na tela de login, o StoreProvider vai persistir isso no async storage. Porém ainda precisamos reidratar a memoria quando o app for aberto, então pra isso, faremos outro useEffect:

export const StoreProvider = ({ children }) => {
  // ...
  const { setItem, getItem } = useAsyncStorage('store')

  const rehydrate = async () => {
    const data = await getItem()
    data && setState(JSON.parse(data))
  }

  useEffect(() => {
    rehydrate()
  }, [])

  return ...
}

Ou seja, toda vez que o app foi aberto, e o react fizer mount do nosso StoreProvider, a função de rehydrate será executada, pegando todos os dados do async storage e jogando na memoria do nosso state.

Acontece que não sabemos quanto tempo esse processo de rehydrate pode levar, ocasionando um lag na checagem do nosso router, que vai mostrar a tela de login antes de fazer o redirecionamento pra tela Home, pois inicialmente não temos o token na store. Então pra resolver esse problema, precisamos adicionar na nossa store uma prop informando que o processo de rehydrate ainda está em execução, para que um loading seja mostrado na tela antes de fazermos a verificação de usuário logado. Nesse caso nossa store final fica assim:

import * as React from 'react'
import { createContext, useContext, useState, useEffect } from 'react'
import { useAsyncStorage } from '@react-native-community/async-storage'

const StoreContext = createContext([{}, () => {}])

export const useStore = () => {
  const [state, setState] = useContext(StoreContext)
  return [state, setState]
}

export const StoreProvider = ({ children }) => {
  const { getItem, setItem } = useAsyncStorage('store')
  const [state, setState] = useState({
    rehydrated: false,
  })

  const rehydrate = async () => {
    const data = await getItem()
    setState(prev => ({
      ...prev,
      ...(data && JSON.parse(data)),
      rehydrated: true,
    }))
  }

  useEffect(() => {
    rehydrate()
  }, [])

  useEffect(() => {
    setItem(JSON.stringify(state))
  }, [state])

  return (
    <StoreContext.Provider value={[state, setState]}>
      {children}
    </StoreContext.Provider>
  )
}

Verifique que adicionamos um estado inicial com rehydrated: false, e no método de rehydrate, colocamos rehydrated: true pra informar que o processo de reidratação foi concluído.

Ainda temos que alterar nosso login, pra mesclar as informações na store, em vez de substituí-las.

const Login = () => {
  const formik = useFormik({
    onSubmit = async values => {
      try {
        const { data } = await api.login(values)
-        setStore(data)
+        setStore(prevState => ({...prevState, auth: data })
      } catch (error) { }
    }
  })

  ...
}

Perceba que agora nossa store passa a ter os dados de autenticação nomeados pra auth, então nosso componente Router precisa se adaptar a isso, além de verificar se o processo de rehydrate já terminou ou não:

const Router = () => {
  const [{ auth, rehydrated }] = useStore()

  if (!rehydrated) {
    return <Loading />
  }

  return auth && auth.token ? <Home /> : <Login />
}

E pronto, temos um gerenciamento de autenticação utilizando um estado global com context api e persistência!

Você pode ver o vídeo onde eu explico essa implementação mais detalhadamente, e pode acessar o repo com o projeto desenvolvido durante a gravação do vídeo.