Pular para o conteúdo principal

2 postagens marcadas com "node"

Ver todas os Marcadores

· 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 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