Pular para o conteúdo principal

· Leitura de 5 minutos
Alan Christian

Banner

Terminologias básicas usadas no desenvolvimento de APIs

  • API Key - Vamos chamá-los de um conjunto de instruções codificadas passadas para solicitações de API recebidas. O objetivo deles é identificar a origem e a natureza da solicitação recebida. Eles são uma parte inseparável da arquitetura da API, necessária para bloquear fontes duvidosas que acessam informações do serviço da web.

  • Endpoint - São referenciados para passar um valor em uma determinada URL.

  • JSON - A sigla significa JavaScript Object Notion. Este é um formato predefinido que o desenvolvimento de API depende para passar solicitações e enviar respostas entre dois aplicativos.

  • GET - APIs RESTful usam o mesmo que um método HTTP para reunir recursos.

  • PUT - Novamente, um método HTTP de edição de dados existentes. As Agências de Desenvolvimento o envolvem principalmente quando atualizam uma coleção de informações. Por exemplo, uma mesa.

  • PATCH - Usado ao atualizar um único valor. Como uma única entrada em uma tabela (sobre o exemplo acima).

  • POST - A interoperabilidade é um processo de duas vias. Se uma API precisar coletar informações de um endpoint, ela deverá estar aberta ao compartilhamento de dados de sua extremidade. POST é um método HTTP para APIs RESTful para construir (ou adicionar) tais recursos.

  • DELETE - Autoexplicativo.

  • JSON Web Token - É um padrão usado para criar tokens de acesso para um aplicativo.

  • API Throttling - Esse recurso é uma parte fundamental do desenvolvimento de uma API. Ele regula a frequência de usuários que acessam a API em um determinado momento. Quando o tráfego do site aumenta além de um limite definido pelos desenvolvedores, o erro 429 é exibido, que diz "Muitos leitores".

  • Rate Limiting - Todos nós já enfrentamos situações ao alternar entre as guias de aplicativos/sites quando exibimos uma nota que diz algo como “Nosso site detectou tráfego incomum do seu computador”. Não é nada além da API limitando a taxa de acesso de usuário único.

coloaqui imagem 🔴

Tipos de propriedade de APIs da Web

  • APIs Abertas essas APIs estão disponíveis publicamente para uso como APIs Oauth do Google e não há restrição para usá-las. Por isso, eles também são conhecidos como APIs públicas.

  • APIs Internas As APIs que são desenvolvidas pelas empresas para usar em seus sistemas internos para que possam aumentar a produtividade das equipes de desenvolvimento onde uma equipe pode usar serviços de outro projeto da empresa são chamadas de APIs internas. Essas APIs também são conhecidas como APIs privadas.

  • APIs Parceiras direitos ou licenças específicas para acessar esse tipo de API porque não estão disponíveis ao público. Normalmente, esses tipos de APIs estão associados a serviços pagos.

  • APIs Composite tanto os processos quanto as APIs compostas são uma sequência de tarefas, mas as APIs compostas combinam diferentes APIs de dados e serviços. É uma sequência de tarefas que são executadas de forma síncrona como resultado da execução onde o resultado do acionamento de uma Composite API é o resultado da execução e não a requisição que conterá o resultado da execução a pedido de uma tarefa. Seu principal uso é acelerar o processo de execução e melhorar o desempenho dos ouvintes nas interfaces web.

Tipos de formatos de APIs da Web

Em APIs de web service a classificação é feita de acordo com o tipo de comunicação e abordagem comportamental utilizada na construção de APIs:

  • SOAP - Deve haver um conjunto de protocolos de mensagens para que os serviços da Web interajam entre si. Simple Object Access Protocol é um conjunto predefinido de regras que permite a transmissão de tais mensagens. Ele usa a linguagem de definição de serviço da Web (WSDL) para publicar detalhes de sua interface. Ele usa a transferência de mensagens em formato XML proprietário.

  • REST - Representational State Transfer é um estilo de arquitetura de software usado para definir serviços web. Eles oferecem imenso valor de desenvolvimento de API, pois os códigos de solicitação podem limitar o escopo de sua solicitação a dados específicos e apontar para um bloco inteiro de informações. Quando as consultas recebidas apontam para conjuntos específicos de informações, isso reduz o tempo de processamento. As APIs RESTful são projetadas em conjunto com o protocolo REST.

  • GraphQL - O GraphQL foi criado a partir da necessidade de desenvolver recursos mais rápidos, uma carga de dados mais eficiente e maior adaptabilidade móvel. Essa linguagem de consulta da API permite que os clientes forneçam detalhes sobre os dados de que precisam e simplifica a adição de informações por meio de várias fontes.

  • XML-RPC - RPC significa chamadas de procedimento remoto e permite que os programas façam chamadas de procedimento ou função pela rede. Ele emprega protocolos HTTPS para transferir informações de um computador cliente para o servidor. Ao contrário do SOAP, aqui usamos um formato XML específico para transferência de dados. Seu consumo de largura de banda é relativamente menor do que outras APIs de serviços da Web, além de ser fácil de executar.

  • JSON-RPC - RPC é um protocolo de chamada de procedimento remoto desenvolvido em JSON. Ele define apenas alguns tipos de dados e comandos, permite notificações e permite várias chamadas para o servidor que podem ser atendidas em nenhuma ordem específica. Ele tem vários recursos sobrepostos com XML-RPC, no entanto, ele usa JSON para transferir dados do que XML.

· Leitura de 2 minutos
Alan Christian
SQLNoSQL
DatabaseDatabase
TablesCollections
RowsDocuments (BSON)
ColumnsFields
ID_Id

Response

MétodoDescrição
res.download()Solicita que seja efetudao o download de um arquivo
res.end()Termina o processo de resposta
res.json()Enviar uma resposta JSON
res.jsonp()Envia uma resposta JSON com suporte ao JSONP
res.redirect()Redireciona uma solicitação
res.render()Redenriza um modelo de visualização.
res.send()Envia uma resposta de vários tipos.
res.sendFile()Envia um arquivo como um fluxo de octeto
res.sendStatus()Configura o código do status de resposta e envia a sua representação em sequência de caracteres como o corpo de respost

Rest na prática

TaksMethodPath
Create a new tasksPOST/taks
Delete an existing taskDELETE/task/{id}
Get a specific taskGET/task/{id}
Search for tasksGET/tasks
Update an existing taskPUT/task/{id}

· Leitura de 4 minutos
Alan Christian

Banner

🎨 Não importa quão bom seja nosso design, os erros são inevitáveis.

A maioria de nós, enquanto desenvolvemos sites, juramos que as mensagens de erro mostradas ao usuário final são o mais específicas possível, o que ajuda bastante na criação de um UX amigável. Mas a mesma regra, se usada no fluxo de login, pode ter implicações significativas de privacidade e segurança. Ao inserir credenciais de login incorretas, a maioria dos sites mostra variações de Invalid username/passworderro na tela de login.

Login

Pode-se presumir com segurança que não existe nenhum usuário para esses e-mails, mas as mensagens de erro exibidas por esses sites proeminentes não indicam isso. Você vê por quê?

🔏 Protegendo as informações da base de usuários

Ao alimentar e-mails aleatórios, um simples login/redefinição de senha pode mostrar que o usuário não existe e, portanto, nenhum login/redefinição de senha é possível. Um cliente hostil pode criar uma lista de usuários válidos a partir dessas informações. Nem todo site se preocupa com isso. O Facebook não.

Facebook Login

Não faz mal para um site como o Facebook vazar a base de usuários porque todo mundo está nele, mas quando o site é algo como Ashley Maddison, pode ter implicações.

Fechando o ciclo

As pessoas costumam argumentar que a base de usuários é vazada durante o processo de registro, o que não pode continuar se o usuário já existir. Esse vazamento também é evitável, continuando o registro por e-mail. Caso o usuário já exista, o e-mail pode informar, caso contrário, pode direcionar o destinatário para continuar o processo de registro.

👨🏽‍💻 Dissuasão à força bruta

Em um ataque de força bruta, um grande número de combinações de nomes de usuário e senhas são tentados a entrar na conta de um usuário. Um ataque de dicionário é mais rápido e melhor, pois aproveita as tendências humanas de usar senhas comuns e reutilizar senhas antigas. Mensagens específicas como Invalid username tornam esses ataques mais rápidos, eliminando um grande número de combinações em poucas tentativas.

Demonstração

Para quantificar a diferença que mensagens de erro detalhadas podem fazer para ataques de força bruta ou de dicionário, confira esse script, login-attack-demo, que incluía:

Dicionário

Uma coleção de 1575 senhas mais usadas com base em danielmiessler/SecLists.

🔴 Servidor ingênuo

Um servidor que emite mensagens de erro específicas com base no estágio de falha do processo de login. Se o nome de usuário for inválido, ele dirá Invalid username.

🟢 Servidor inteligente

Um servidor que emite mensagens de erro vagas em caso de falha no processo de login. Se a senha for inválida e não o nome de usuário, ainda será exibido Invalid username/password.

Atacante

Um cliente hostil que usa o dicionário para gerar um par de nome de usuário e senha e os usa para invadir o sistema. Também analisa as mensagens de erro nas seguintes regras:

  • Uma mensagem de erro dizendo que a senha era inválida indica que o nome de usuário era válido.
  • Uma mensagem de erro informando que o nome de usuário era inválido indica que nenhuma combinação de senha resultará em um login bem-sucedido.
  • Uma mensagem de erro inconclusiva é ignorada e a próxima combinação é tentada.

Métricas analises

Os pontos azuis indicam o número de tentativas que o invasor levou para invadir a conta do usuário com mensagens de erro vagas, enquanto os pontos vermelhos indicam quando as mensagens de erro eram específicas. A linha amarela é o número máximo de combinações para tentar.

É evidente que, em teoria, mensagens de erro vagas tornam bastante difícil para o invasor, às vezes até 1.000 vezes mais difícil. No entanto, tapar todos os buracos pode tornar o UX longe do ideal. No final, tudo se resume a uma troca entre UX e segurança. Dependendo do espaço que você está operando, esses métodos podem ser usados ​​para proteger os usuários.

Dicas

Vou dar alguns conselhos do ponto de vista de Segurança + UX. Eu não sacrificaria um pelo outro. Ter ambos.

Sugestões